on 10-20-2010 7:22 AM
Hi Experts,
At our end some confirmations FOR GOODS ITEMS are showing in "Currently being transferred" status. When I checked the IDoc for the goods confirmation everything look okay and IDoc has posted to backend. Good receipt document has been generated.
But the confirmation in SRM still shows Currently being transferred. This is an extended classis scenario (SRM5.0).
This is also impacting the payment due date on the Invoice document generated (currently not being calculated from the delivery date).
Firstly what causes the confirmation to remain in "Currently being transferred" status ?
If you have any suggestions to get these into "posted in backend' status or any SAP notes to prevent this from happening would be highly appreciated.
Thanks
RB
Hi,
This might happen due to system failure during the updates. The reason may vary from Commuincation failure to table lock etc during the checking for backend docuemtns and updating the same in SRM.
Use FM CRM_STATUS_UPDATE to update the statuses by Passing the Client, GUID, Status, Inactiva Flag,
Tables ,
JEST_INS - To insert new status
JEST_UPD - To update the old staus (say making it Inactive)
The final view in BBP_PD for the confirmation should be something as below
Status Description Inactiv
HEADER I1015 Awaiting Approval X
HEADER I1017 Currently Being Transferred X
HEADER I1018 Posted in the Backend
HEADER I1021 Created
HEADER I1022 Approved
HEADER I1038 Complete
HEADER I1044 Confirmed
regards
MRao
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
In case of not baing a matter of temporal connection failure:
Check following OSS notes:
Note 1143245 fix this issue. The note consist on adding GR number on BBP_DOCUMENT_TAB key entry. This allows registry not to be overlaped, allowing the job CLEAN_REQREQ_UP to set correctly the status to pending GR's.
Note 644963 consist of a Z program that generates entries to BBP_DOCUMENT_TAB, for all GR's with erroneous status, in order to be processed by the job CLEAN_REQREQ_UP.
Thanks and Regards,
Ab.
Thanks Mahesh and Abraham for your replies. Much appreciated.
I have checked the two notes suggested in the last post and we have already applied them. But, the main issue here is 60% of the confirmations created daily are successfully getting into 'Posted in Backend' status but remaining confirmations are remaining in 'Approved' status and majority of them are goods. There are 100's of them remaining in approved status daily which is my concern.
Another thing to notice is that the Confirmations in Approved status have Idoc posted successfully, GR document created in backend. But somehow the system has failed to modify the status from Approved to Posted in backend. This is the main cause.
Any more pointers or suggestions on this would really help. Thanks again.
Thanks
RB
Edited by: Rajeshree Bhatiya on Oct 27, 2010 6:18 AM
Hi Rajeshree,
Please check ur BBP_GET_STATUS_2 job. Try to run the job BBP_GET_STATUS_2 for any one of the SC and see if the status is updated after that ... if that is the case then you need to look at your varaint for the job and try to run the job with variant such that it updated all SC with time frame toay ,last 7 days, last 30 days
i.e BBP_GET_STATUS_2 job should be run with above three variant with three different frequency.
Thanks
Iftekhar Alam
Just noticed that the CLEAN_REQREQ_UP jobs have a buffer table error while checking the job log.
Below are the details.
Buffer table not up to date
Message no. BBP_PD001
Diagnosis
In FORM BW_READ_CHANGED_DATA (function group SAPLBBP_BI_GEX_DELTA) an inconsistent status was discovered.
Procedure
Start the transaction again. If the error occurs again, create an OSS message.
To analyze the error, you can set a breakpoint in the function module 'BBP_PD_ABORT' and look at the call-up hierarchy in debugging mode
Message text Message class Message no. Message type
Job started 00 516 S
Step 001 started (program CLEAN_REQREQ_UP) 00 550 S
Buffer table not up to date BBP_PD 001 I
Job finished 00 517 S
Any clues on this ?
Thanks
RB
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.