cancel
Showing results for 
Search instead for 
Did you mean: 

Incorrect status table E_STATUS from FM BBP_PD_CTR_GETDETAIL

Former Member
0 Kudos

Hi,

I have an SRM 4.0-implementation (SAP SRM server 5.0, Supportpack 13) in extended classic scenario.

BADI u2018BBP_DOC_CHECK_BADIu2019 has been activated for filter u2018BUS2000113u2019 so I can create some custom made errormessages for the active lines in a contract and only when mode = 'T'. Thats okay so far.

I then mark one of the lines in the contract as status 'Inactive' and press controll. The BADI calls FM 'BBP_PD_CTR_GETDETAIL' with the original GUID for document and returns with table e_status showing the line marked with an 'X' in inact.

If I then mark an other line with status 'Inactive' and press control the BADI call FM 'BBP_PD_CTR_GETDETAIL' again with the original GUID and returns with table e_status - but the new line is NOT marked with an 'X' in inact - only the first is still marked.

The BADI is called two times in mode = 'T' when I press controll. First time with the original GUID and second time with the change version GUID - and it is the first time that gives the problem with e_status. The second call with the change version GUID only gives the e_status for the lines that are active, but the first call allready fills in the logfiles with errormessages and show errors on inactive lines...

Added Apr 20, 2010

I can see, that my problem has something to do with JEST_BUF.

JEST_BUF is not maintained when making two or more changes (setting lines inactive) and then press 'controll' - only the first line changed is marked 'inactive' in status field.

Edited by: Dorthe Lauritzen on Apr 20, 2010 2:59 PM

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

In my opinion there are two issues with your approach:

1) BBP_DOC_CHECK_BADI is commonly used for validating procurement document, not to make changes to them. There is BBP_DOC_CHANGE_BADI for customized changes if required.

2) Changing the status is often not as trivial as changing the internal table E_STATUS. Status is managed on a cross application level. Often times, you would realize that even if you have changed the internal table, the document would not result in the status you want it to have, or worse, erroneous stage. A more feasible approach to change status is to call FM BBP_PROCDOC_STATUS_CHANGE and let the system determine if such change is possible.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi, I found out what was wrong or could use instead of e_status-inact

Instead of using the e_status table, which was not updated with 'X' in inact, I used the e_item-itm_released - when blank, the position is inactive.