on 07-23-2010 10:04 AM
Hi All,
material created in R/3,here purchase requistion generated in R/3 & APO.
Then in APO,after Rescheduling in detailed scheduling planning board new purchase requistion delievery date is not
reflecting in R/3.
Kindly revert back ASAP.
Regards,
Venkat.
Edited by: venkat1215 on Jul 23, 2010 11:05 AM
Edited by: venkat1215 on Jul 23, 2010 11:30 AM
Hi Venkat,
Check your settings in /sapapo/cp3
Check the OLTP settings in SNP customisation
Regards
R. Senthil Mareeswaran.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi senthil,
this question regarding PPDS.
We confirmed about that t.code that you specified.
it is (A always retransfer).
Again i will tell that question,PR created at R/3 Then we rescheduled these PRs in DS planning board
in APO.After scheduling APO proposes available date either forward r backward of the PR created delivery date.
After adopting the scheduling results the proposed date of APO s'd be replace the Existing PR delievery date at R/3.
In our case replication of date is not happening at R/3.
any help on this is highly appreciated.
Regards,
venkat
Hi Venkat,
Check your delivery or transit times defined in R/3 system. Looks like APO is suggesting a date but when it goes to R/3, the system says this is no way possible and overwriting it. R/3 is always a superior system in these cases. I would check any GI, GR, transit times etc. setup in both the systems APO and R/3.
Venkat,
You didn't answer my question.
As a general rule of thumb, APO is much fussier about changing and synchronizing orders that were created in R/3. If you have a choice, you should always create purchase reqs in APO (although cross-creation is supported, and can be made to work nicely if you are diligent).
When you change an order in APO, and then publish the change to R/3, it is possible that the settings in R/3 will cause an issue with 'booking' the change. One way to test this is to manually make the same change, but directly in R/3. There should be no warnings or errors.
Another thing to look at are the Application logs on both sides (SLG1) for possible failures that may give a clue. Restrict to date and time interval where you know the proper update did not take place.
Rgds,
DB49
User | Count |
---|---|
8 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.