Hi @DominikaM 

I would suggest to keep customized database logics in a separate package (Like a custom package).

It would be better to avoid changing existing standard core packages unless the code is added to the cust layer in repository. IFS has provided so many options such as Database tasks, Configurations to allow most of the changes you need to implement. 

For reports you could switch to crystal report or business reports as it allows to access those custom packages.

Or else you will have to manually deploy all these changes during a release. 

these package changes were made in CUST. however, after the update, they are not in the database.

@DominikaM From what I understand, since layered application architecture is not supported for operational reports, putting the modified files in the appropriate Cust folders and committing them to the repository, should protect the files from overwrite.  

Dear @DominikaM 

all reports or only specific ones?; can you name the specific SU levels as well, please?

We faced in 22RU2 SU11 same with ONE report.
—> CS0164845 Purchase Order RPI got changed without related delivery content

I got confirmation in the europe escalation call to raise it priority 1, critical.

Dear all, 

the root cause is not found yet, but as a workaround we created a corrective delivery with a dummy commit in the .rdf and .report file. 
This night the installation took place and its fixed; again, root cause not find yet.

We observed onpremise this behaviour only on Deliveries with SU/RU changes.

The case at IFS remains open.

below mentioned details explanation from RnD team>>>>>>>

Inside build place, code build (sanity, delivery, topic) works as follows when it includes a service update difference,

#Check the IFS Application Version of the base commit (e.g.: if it is a delivery build it checks the version from delivery baseline tag)

#Check the IFS Application Version of the target commit(e.g.: if it is a delivery build it checks the version from target sanity tag)

#If there is a difference in the versions copy the changed files between service update tags from the release management repository to the delivery

#Copy the changed files between the base commit and the target commit in the customer solution repository to the delivery. So that the changed files copied from the release management repository get overridden by the changed files between base commit and target commit in the customer solution repository. But the files that were not changed between base commit and target commit in customer solution repository but changed between service updates.

So here also core RDF file get copied to the delivery since there is a difference between service updates. But it is not overridden by the customer solution file if there is no commit for that file between base commit and target commit. So you need to have a dummy commit in this scenario. So as per the current design dummy commit is needed

I have more meetings with IFS to adjust their framework.
Let you know when we have news for you.

It will be fixed through the next release, still the next release version is not communicated to us.

Once they communicate the next release version, we will update you.

Until then, I'll keep the ticket as scheduled to avoid repetitive updates so that we could provide meaningful updates.