Been asked this a couple of times recently, so thought it worth saving here for posterity!
During the normal day to day operation
of an SAP system, OSS notes and other client-approved modifications to the standard
code may be made to accommodate business process and requirements in ways that
SAP didn’t provide for when they wrote their computer programs. This obviously
changes the state of the code (by which I mean, there are lines of code that
SAP don’t expect to be there).
As such, when we come to do an
upgrade, whereby SAP might be updating the “official” version of the code,
there may conflicts between what SAP expect to be there, and what actually is
there.
When an upgrade is done, any objects
that have been affected by the upgrade are offered to the developer in the SPAU
list. The developer will review the code and compare the before upgrade and
after upgrade code, with the option to merge existing bespoke and OSSNoted code
with the newly minted SAP Upgraded code.
The process of reviewing and updating
is known as “SPAU” after the transaction where the comparison is done. It
generates a transport, because after the patch/upgrade is done, there are
further “changes” (i.e. re-merging the bespoke/OSSNote code into the standard).
Usually the upgrade is done, then the SPAU list is
processed, which generates a transport, in the DEV box. Once this has been
completed, the same occurs in the QAS box, with the transport from DEV going
through to QAS and taking care of most, if not all, of the SPAU entries in the
QAS box.
The assumption here is that the boxes
are all roughly consistent, so any SPAU entries taken care of in DEV and QAS
should take care of any in PRD….
