Issue while using N step BADI WS14000133

[Former Member]

Hi all,

We are using SRM5.0 and ECC5, ECS scenario

We have activated the N step BADI for WS14000133 for the shopping cart approval. The coding has been done for the determination of approvers in the BADI.

When the shopping cart is created, it goes for approval to the 1st approver and after he approves it, the status of the shopping cart is set to approved. When I check under the section - follow on documents , it gives the status "Error in process".

Does this have something to do with the non-determination of 2nd approver because when I check the approval preview before the 1st approver approves, I see only one approver that is the 1st approver.

Another question is does the approver determination happen in steps or are they determined in beforehand.

Thanks in advance

Regards

Kishan

[Former Member · Accepted solution]

Hi

This may due to an application error (functional error).For each transfer error, there should be the corresponding error raised in Application monitors (RZ20 or web admin). Therefore, please look in RZ20 and BBP_PD transactions for this articular shopping cart.

Check the error, correct it, and resubmit the SC via transaction "Monitor SC". Please check the shopping cart monitor web transaction (BBP_MON_SC ) to see if there are any details there.

Related useful pointers ->

Do let me know.

Regards

- Atul

[Former Member · Accepted solution]

Hi Atul,

You are right. There is an error in the application monitor.

It says that "Shopping cart 300000000268 (Preq. 300000000270) : Me 013 Document type ECP3 is not allowed with doc. category B (Please check input)".

But does this have anything to do with the determination of approvers in the BADI?

Regards

Kishan

[Former Member · Accepted solution]

Hi Kishan,

Pls check the doc types config. I think it is not getting affacted due to BADI or WF.

Pls check entries in the ECC spro.

Brgds/Gopesh

[Former Member · Accepted solution]

Hi

This is related to configuration error.Please maintain the correct Document types in R/3 as well as SRM.

Here is the path in SRM system.

spro-> SRM Server -> Cross Application Basic settings->Define Transaction Types

Here is the path in R/3 system.

SPRO ->Materials Management->Purchasing->Purchase Requisition->Define Document Types

Hope this will help.

Did you already check OSS note 790304 ?

Best practice to create ECPO in the backend is to copy standard EC document type which should include category B...

spro->Materials Management->Purchasing->Purchase Requisition->Define Document Types

I guess ECP3 is a PO doc type in your R/3 system.

In that case, that means your SC tries to create a PR, but with the PO doc type ECP3.

But you said that you defined BSA = ECPO. So where comes RD33 from ?

Can you tell me what is ECP3 in your R/3: PR or PO doc type ?

And if you have any reference to RD33 in SRM ?

Could you either confirm it is already done or test it if not ?

Related pointers ->

Do let me know.

Regards

- Atul

[Former Member · Accepted solution]

Hi Atul,

Wow, thats a lot of info. Thanks a lot for so many helpful tips.

I'll do the checks and update you.

A quick question : When I use the N step BADI and its corresponding workflow, will it show me all the approvers from different approval levels in the approval preview before I order the SC or would it show me only the approvers of the 1st approval step?

Regards

Kishan

[Former Member · Accepted solution]

Hi Kishan,

You need to check Doct type ECP3 in R/3. Goto doc tyep in spro and check that item catagory B (i.e. Limit) is allowed or not?

If not then maintain there and then once again in BBP_PPOM reassign your document type so as all changes will get updated in SRM and you will be able to transfer your document type PO.

Award points if useful ans.

Regards,

Navneet.

[khan_voyalpadusman · Accepted solution]

It will show all the approvers involved in the approval chain , before the shopping cart itself is ordered.

can you see any errors in the workflow log ? transaction swi6?

for the shopping cart?.

do you see any errors in the application montiors? , please let me know.

[Former Member · Accepted solution]

Hi Usman,

It does show an error in the application monitor, It says that "Shopping cart 300000000268 (Preq. 300000000270) : Me 013 Document type ECP3 is not allowed with doc. category B (Please check input)"

But does this have anything to do with the determination of approvers.

Regards

Kishan

[khan_voyalpadusman · Accepted solution]

yes , the error shows why the follow on document was not created.

And for the follow on document to be created correctly ---> you need to fix this issue.

and the second problem might be with your BADI ---> is not able to identify the second approver and so the shopping cart is set to approved.

and also when the shopping cart is created --> based on the value --> badi will determine all the approvers and will be shown in the review.

can you check the workflow log --> transaction swi6 ---> and see how many approvers are there

[Former Member · Accepted solution]

Hi Usman,

You are right the BADI will check baed on the SC amount.

After the shopping cart is created, I checked it in the T-code SWI6 and saw that only the approvers from the 1st step are determined.

I have written the code in such a way that the 1st step of approvers are determined when the actual_approval_index is 0. The 2nd step of approvers are determined when the actual_approval_index is 1 else I set the no further approval needed parameter.

Is there anything else I need to check?

Regards

Kishan

[khan_voyalpadusman · Accepted solution]

flag no_further_approval_needed is to be set only after all the approvers involved in the approval chain have approved the shopping cart.

for example if you have 3 approvers , this flag need to be set only after the last (third) approver has approved the shopping cart.

if you set the flat before the last approver has approved the cart , then will result in problems.

please also refer to the default implementation which has been provided by SAP.

[Former Member · Accepted solution]

You are right. I'm setting the no_further_approval_needed flag if the approval index is other than 0 or 1, the approvers are determined in the approval index 0 and 1.

[khan_voyalpadusman · Accepted solution]

How many levels of approvers do you have?

two?

please consider the following things.

1) looks like there is problem with your BADI implementation.

2) As soon as the shopping cart is ordered , all the approvers should be available in the workflow log.

along with the user names --> and the index values.

3) you have mentioned > that you see only one approver ( first approver ) in the workflow log-> this is wrong.

4) All the approvers are not considered in your system.

5) since the system is not able to determine the second and further approvers , as soon as the first approver approves the shopping cart ---> it is set to approved.

[Former Member · Accepted solution]

Hi,

Yes I have two levels of approval.

I did a few changes to the code and now after the approvers in the 1 step approve, it shows me the next set of approvers of the 2nd step.

It still does not show me all the approvers of various steps. It only shows me the approvers of the 1st step.

One small question: When the approval BADI is triggered the 2nd time for determining the approvers for the next step, the approval_history_table is empty. It does not have values of the approvers of the had previously approved. Why is that so?

Regards

Kishan

[khan_voyalpadusman · Accepted solution]

hi,

1) Now is the workitem going to the second approver (or) not?

2) what is the Support pack in your system.

3) It is very easy to find out why the system behaves , if you know how to debug

1) shopping cart creation

2) approval by the first approver

3) approval by the scond approver.

4) starting point to debug ---> is

Program --> SAPLBBP_PD

subroutine -->procdoc_wfl_update

5) as you debug---> you will get in to FM

BBP_PDH_WFL_DB_UPDATE ---> in this one as you proceed, you need to set the flag for

lv_in_dialog to X and then DEBUG

FM --> BBP_WFL_DIN_APPR_CONTAINER_SET ---> which in turn calls FM

BBP_WFL_DIN_APPR_FINALLIST_GET ---> which calls

FM

BBP_WFL_DIN_APPR_BY_RULE_GET (used for finding the approvers in each step).