SRM - WFlow - PO not created in R/3 - Approval preview is OK

[Former Member]

Hello,

Please could you help me as this is a production issue and need a quick resolution.

1. SC is created and approved by the user- The approval is done through an email attachment where the user approves.

2. The approval preview shows that the SC is approved by two users and status is approved.

3. The work flow logs in SWI6 says that the worklfow is completed.

4. BPP_PD report does not show the follow on documents(PO) and the PO is not getting created in the backend.

The info from BPP_PD as below which might help to answer my query.

Stats:

Status Description Inactiv

HEADER I1015 AwaitingApproval X

HEADER I1021 Created

HEADER I1038 Complete

HEADER I1106 Shopping cart ordered

HEADER I1129 Approved

Workflow Item:

Workitem-ID 000000550373

Task WS14500015

Text Item-Based Approval 1000047865

Status COMPLETED

Statustext Completed

Date 20.02.2006

Time 10:07:09

*************************

Node ID Agent

0040000000 Mr Jon Kimber

User

WF-MAILAPROV

State Workitem

No workitem found

************

Messages:

W BBP_PD 584 Requested delivery date cannot be met; Earliest possible date: 08.03.2006

> Check Again

Please could you help me ASAP. I would appreciate your early reply.

Thanks and Regards,

Uma Rout

[Former Member · Accepted solution]

Hello Uma,

I suppose you are running on a classic scenario.

Once approved, SC is transfered to the following document in an update task (BBP_PD_SC_TRANSFER_V2), triggered by the changed status ("Approved" set by the WF) during "commit" instruction.

So first check SM13 if some update tasks are not there, blocked by any reason (ex: no more DB space to insert data).

If not, that means the process gone further.

During SC transfer, the backend doc type & ID is determined.

Check via BBP_PD, in SC item detail, table BBP_PDBEI if you have a BUS2012 and a PO ID generated (at that time R/3 PO item number is not stored, this is done by CLEAN_REQREQ_UP).

Normaly you have this information, otherwise, an error should be raised in application monitor, saying something like "Doc type could not be determined".

In classic scenario, the backend PO is create by function SPOOL_PO_CREATE.

Finally, this function is creating a R/3 PO by calling BAPI_PO_CREATE.

During this process, you have to kind of errors:

- applicative errors: they are raised in application monitor, in "backend" SC sub monitor

- communication errors (network issue, R/3 temporary unavailable...): in that case a job POJOB is scheduled (and re-scheduled according to SRM customizing) to retry the PO creation. Check SM37 if there is such a job.

Didn't you find any application errors in Application monitor ?

Check dumps (ST22) in SRM and in R/3.

Finally, if you don't find any trace (that's impossible), re-execute the transfer manually using FM BBP_PD_SC_TRANSFER_INTERNAL or directly SPOOL_PO_CREATE.

Rgds

Christophe

[Former Member · Accepted solution]

Hi Christophe,

I have checked SE13 and no updates pending.

There is no entry in the table BBP_PDBEI and we have not used BUS2012.

Other thing i found that the in the BPP_PD as below

Stats:

Status Description <b>inactive</b>

HEADER I1015 Awaiting Approval <b>X</b>

The CRM_JEST table shows the status as below

MANDT OBJNR STAT INACT CHGNR

010 43EFD101A54F66F3E10000000A08224E I1015 X 002

Is this helpful to you??

Regards,

Uma.

[Former Member · Accepted solution]

Hello Uma,

Your status is correct: "Awaiting approval" has been inactivated, and "Approved" has been activated.

That means the inbound approval mail has been correctly processed, and SC status updated.

If you have no data in SC item BBP_PDBEI, that means the transfer process has not even started (BBP_PD_SC_TRANSFER_INTERNAL has not been executed).

You said you executed BBP_PD_SC_TRANSFER_INTERNAL without success (with the correct GUID) ?

This is strange.

Only items with status deleted, in transfer, follow on doc are not transfered.

And this is not your case.

This function should:

- assign the status "In transfer" + COMMIT

- determine followon doc types and ID, and store references in BBP_PDBEI + COMMIT

- create backend doc with SPOOL_PO_CREATE

Execute it in debug mode and check each step.

Rgds

Christophe

[Former Member · Accepted solution]

Hi Christophe,

Manage to create the PO by running the FM BBP_PD_SC_TRANSFER_INTERNAL. However the root cause is still not known. The Approval preview has not been updated with PO number. BPP_PD report shows the PO number.

The status shows the same as before with 'No Worktem found'.

HEADER I1015 Awaiting Approval X

HEADER I1021 Created

HEADER I1038 Complete

HEADER I1080 In Transfer to Execution Syst.

HEADER I1106 Shopping cart ordered

HEADER I1129 Approved

0000000001 I1111 Item in Transfer Process X

<b>0000000001 I1113 Follow-on Document Created </b>

The 'Workitem not found' message is below.

Node ID Agent User State Workitem Created at

0040000000 Mr Jon Kimber WF-MAILAPROV No workitem found

0040000001 WYLIED WF-MAILAPROV No workitem found

I think there is some missing links which has not been picked up by the FM and also as suggested by Yann i would apply the OSS notes or ask business to upgrade the patch level to 009 which would resolve many issues.

Thanks for your help but i will come back to the issue again with more info what and where we have done wrong.

Regards,

Uma.

Otherthing is to mentioned

[Former Member · Accepted solution]

Uma,

Approval preview is not updated with PO number, but by approval steps.

--> History tab is updated with PO number (after CLEAN_REQREQ_UP run).

You definitively have to find the root cause, and it could be around workflow (no workitem found).

The issue should not come from offline approval, as you said it is working in majority of cases.

As your SC had the correct approval status, I would say that the workflow itself is not responsible, because it updated the SC correctly. The load is then passed to BBP_PD functions, in charge of updating statuses and trigerring next actions (SC transfer in BBP_PROCDOC_SAVE).

Have you checked transaction SM58 ?

PS: please reward points for helpfull answers

[Former Member · Accepted solution]

SM58- have checked - nothing in trfc queue. I will catch up this tomorrow more info.

Thanks,

Uma.

[Former Member]

Hello All,

We are seeing the exact same error. We are receiving the delivery date warning on every one of these and I was thinking that that was the problem. We are on stack 07.

My main question now is, is there a way to get a listing of every shopping cart that is in this state? That would be needed to track this and cleanup in the meantime.

Thanks,

Mike

[Former Member]

Hello Michael,

I am not sure if there is any. I would also need anybody's advice on this so that we can track those which are stuck.

Yann or Christ could help us.

Thanks,

Uma.

[yann_bouillut]

Hi Uma,

Delivery date message is a Warning message so it should not stop the process.

Maybe transaction BBP_MON_SC (Monitor shopping cart) is enough to track SC with this status.

Please confirm.

Kind regards,

Yann

[Former Member]

Hi Yann,

What values would you use in the transaction to select those affected carts? It is not readily apparent how to search for them. My only thought is possibly a query or a report over the tables that show shopping carts that have approved and that do not have the follow on documents. Do you know which tables those are?

Thanks,

Mike

[yann_bouillut]

Hi Michael,

Unfortunately, i do not have any access to an SRM system right now...

but i think you're correct, bbp_mon_sc won't be enough to trace approved SC with no following document.

Tables can be found in transaction BBP_PD.

Another starting point to write the report could be report BBP_ALERT_SC_STATUS_ERROR or Z_SC_STATUS_CHECK_1

Regards,

Yann

[Former Member]

Hi Yann, Mike,

The follwoing reports, i found from one of the thread. This could be usful.

BBP_BW_SC1 Ordered Shopping Carts per Cost Center

<b><b>BBP_BW_SC2</b> Shopping Cart Status </b>

BBP_BW_SC3 Shopping Carts per Product

BBP_BW_SC4 Shopping Carts per Cost Center

Regards,

Uma.

[Former Member]

Hello Uma,

The report "2" was just the right report. Also, on further inspection we noticed that the errors that we are recieveing from the beginning were due to "locked" shopping carts. We have been able to reprocess them using the FM and with this report we consider ourselves to be in a good position to address this problem going forward... We are hopeful that stack 09 will address these issues in the future.

Cheers,

Mike

[yann_bouillut]

Hi Uma,

Do you have any log in SM21 or ST22 ?

What say the application monitor ?

Did you already create a PO in the production system before this issue ?

Regards,

Yann

[Former Member]

Hi Yann,

I have checked ST22, SM21 and SE13 and no info found.

No, The PO is expected to be created in R/3 after approval.

The WF is approved and completed.

Regards,

Uma.

[yann_bouillut]

Hi Uma,

Did you already create a PO in the production system before this issue ?

Kind regards,

Yann

[Former Member]

Hi Yann,

I need to check this with the user. As far as i know they would not have created the PO already as the process should automatically create PO in the backend once approved.

Uma.

[yann_bouillut]

Hi Uma,

I wanted to say : in your production system, did you already create a PO automatically (via SC creation-WF-...)

Regards,

Yann

[Former Member]

Hi Yann,

That's Right. We create PO automatically via SC creation - WF process.

Thanks.

Uma.

[yann_bouillut]

Hi Uma,

As said before, it is strange that you do not have any log...

However, i guess you have already checked your entire SRM customizing : transaction type, PO number range....

Please confirm.

Regards,

Yann

[Former Member]

Hi Yann,

This does not happen in all the cases. Please note that the WF-MAILAPROV is user who carry the approval from the user mail box(not SAP inbox). The status of Workitem is 'No workitem found'. Is this something that when the user approves the mail server not able sent the work item???

Node ID Agent User State Workitem

0040000000 Mr Jon Kimber WF-MAILAPROV No workitem found

0040000001 WYLIED WF-MAILAPROV No workitem found

regards,

Uma.

[yann_bouillut]

Hi Uma,

What is your SRM release AND SP level ?

Regards,

Yann

[Former Member]

Hi Yann,

SRM_SERVER 500 0006 SAPKIBKS06 SRM_SERVER

EBP4.0

Regards,

Uma.

[yann_bouillut]

Hi Uma,

What workflow do you use ?

WS.... ?

regards,

Yann

[Former Member]

WS14500015

regards,

Uma.

[yann_bouillut]

Hi Uma,

Please check OSS note 904848 as the step is marked as having been executed and approved but this maybe does not correspond to the actual process.

Kind regards

Yann

[yann_bouillut]

Hi Uma,

You are using WF-MAILAPROV.

Please check :

- OSS note 921531

- authorizations of your user WF-MAILAPROV

Kind regards,

Yann

[Former Member]

Hi Yann,

Our system is in SAPKIBKS06 and the note is in SAPKIBKS09.

This defintely need to be updated but at the moment is there any quick win.

I will ask business to look at the OSS note and Apply ASAP.

Regards,

Uma.

[Former Member]

Hi Yann,

You have been very helpfull during this query and this query is not finished yet but managed to wind up today due to production issue. The root cause is still known to me for which i need to dig in futher and find the actual problem and we might come back for this discussion again.

I will make sure to apply the oss notes suggeted by you.

Thanks for you help and support.

Regards,

Uma.

[Former Member]

Hi,

did you run the reports BBP_GET_STATUS and CLEAN_REQREQ_UP?

[Former Member]

Hi,

Thanks for your quick reply.

Please could you let me know if this is OK to run in production system as bit scared. I hope this should not harm anyway?

You mean running in R/3 or SRM.

Regards,

Uma

[Former Member]

Uma,

first check all steps provided, and tell me the result.

Only once everything is checked, then you can re-execute FM in SRM manually. Otherwise, there is a risk of creating double PO.

Rgds

Christophe

PS: please reward points for helpfull answers

[Former Member]

Hi Cordula Speh,

I ran CLEAN_REQREQ_UP and BBP_PD_SC_TRANSFER_INTERNAL. this didn't do anything.

Regards,

Uma.