Ansicht
Dokumentation
00410 - Anyone with a SLICK SPAU process during application of Suppor t Pa ckage(s)? 4.6C
TXBHW - Original Tax Base Amount in Local Currency SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3upThis documentation is copyright by SAP AG.
Anyone with a SLICK SPAU process during application of Suppor t Pa ckage(s)? 4.6C
Any opportunity to be a smart aleck. Bear in mind, we don't have that manydevelopers and they/we are all company employees, but the "slick" process is
don't bother checking anything at SPAU/SPDD time, just take what SAP gives
you. If "something was undone", then use version management to compare the
sources and adjust (or addtobuffer and re-import the transport with the
developers changes). The developers are free to warn you ahead of time of
specific programs (sources) they think might be overlayed by an LCP, but yes
it is their responsibility to keep track of which LCP/HOT might change what
they are working on. On the other hand, they could come in late at night /
early on the weekend and apply the LCP's and compare mountains of source
code, take mountains of crap for "breaking things", etc...
good luck,
Rick
-----Original Message-----
From: Anderson, Doreen [mailto:DAndersoZb...]
Sent: Thursday, January 18, 2001 12:22 PM
To: 'SAP AS/400 Discussion Group'
Subject: Anyone with a SLICK SPAU process during application of Support
Pa ckage(s)? 4.6C
Hi,
We're finding that it is taking more & more time to assess all the objects
which "appear" in SPAU during the application of a Support Package
One at a time; we bring up each source in SPAU; Version Management & Compare
We've been able to get the developers to annotate on the text for their
change request the note# that they are applying.
We then typically display the OSS Note & take a look at whether it was to be
included in the Support Package being applied at the time.
At that point, we "return to SAP standard" without really scrutinizing the
code differences on the compare screen.
If the change request does not contain any documentation/text; we then
review the code differences.
We are going to ask the developers to take it one step further & also
include the Support Package # in which the code changes are scheduled for
(if that information has also been included in the OSS note)
Does anyone have a more streamlined procedure? Do you push this
responsibility back to each individual developer?
Curious
ps. Our 4.6C DIA instance issue went away after scrapping it & reinstalling;
must of done something incorrectly 1st time
Durban Tours - Südafrika Safari
TXBHW - Original Tax Base Amount in Local Currency General Material Data
This documentation is copyright by SAP AG.
Length: 2964 Date: 20240424 Time: 055007 sap01-206 ( 2 ms )
