Skip to Content
avatar image
Former Member

Incorrect status table E_STATUS from FM BBP_PD_CTR_GETDETAIL

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    Apr 20, 2010 at 06:43 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 27, 2010 at 12:49 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded