BAdI BBP_PGRP_FIND

[Former Member]

Hi all

I've implemented BAdI BBP_PGRP_FIND to set purch.org. and purch.group. If the SC item was added from the catalog then it should be set to '9000' and '900' and if the SC item is a described requirement then the purch.org. and purch.group shall be determined using the standard logic delivered from SAP (function module used for that is 'BBP_OM_FIND_SC').

I'm able to differentiate those situations using field IS_RESP_ITEM_DATA-PRODUCT_SRC_SYS. If it is empty, then the SC item to be added is a described requirement, else an item coming from catalog.

So far the BAdI implementation works fine. At the end of the BAdI coding I can confirm that the purch.org. and purch.group were set correctly and according to above described logic (verified it in debugging mode).

In the end users screen (item details) I can see that the correct purch.group was set as well!

But when ordering the SC, the follow-on document in the backend (purch.req.) is created with the wrong purch.org. / purch.group.

To verify this I put a MESSAGE statement in BAdI BBP_DOC_CHANGE_BADI to confirm it. The dialog box pops up during runtime. It confirms that the purch.org. and purch.group is wrong.

However, in item details screen the purch.group remains the correct one!

Does someone out there know anything about this behaviour?!? I'm really stuck on it.

Thanks a lot for any appreciated hints!

Kind regards,

Renaud

[Former Member · Accepted solution]

Hi Renaud,

for catalog/free text determination, you can also use field CATALOGID (if available in the BADI item interface).

For the PR creation, if the standard does not work correctly, you can use BADI BBP_CREATE_REQ_BACK to pass the SRM purch group (its corresponding R/3 backend ID) in REQ_ITEMS-PUR_GROUP.

You say that when checking the purch group in BBP_DOC_CHANGE_BADI, the values are wrong: what does it mean ? what do you check ?

In BBP_PD, check 2 things:

- the item org data (with SRM org IDs) : this is what is displayed in the SC item basic data

- the item backend data in BBP_PDBEI-BE_PUR_GROUP: <b>it should be aligned with the previous item org data</b>. This is what will be transfered to R/3.

Rgds

Christophe

PS: please reward points for helpful answers

[Former Member · Accepted solution]

Hi Christophe

> For the PR creation, if the standard does not work

> correctly, you can use BADI BBP_CREATE_REQ_BACK to

> pass the SRM purch group (its corresponding R/3

> backend ID) in REQ_ITEMS-PUR_GROUP.

Will switch over to this BAdI if no other solution will work. For now, I'd simply like to have correct purch.org. and purch.group being determined using BAdI BBP_PGRP_FIND and to have the standard take this into account.

> You say that when checking the purch group in

> BBP_DOC_CHANGE_BADI, the values are wrong: what

> does it mean ? what do you check ?

I implemented some code in BBP_DOC_CHANGE_BADI to raise a message before leaving the BAdI. This message pops up during run time (from an enduser point of view) and shows me the purch.org. and purch.group of the SC item. With this I'm able to check what purch.org. and purch.group is set in SC item... and that's where I can see that it sometimes differs from the data determined in the BAdI BBP_PGRP_FIND.

> In BBP_PD, check 2 things:

> - the item org data (with SRM org IDs) : this is

> what is displayed in the SC item basic data

> - the item backend data in BBP_PDBEI-BE_PUR_GROUP:

> it should be aligned with the previous item org

> data. This is what will be transfered to R/3.

Checked it and it both (item org data and BBP_PDBEI) the purch.org. and purch.group are wrong! No wonder it creates the purch.req. in backend with the wrong data.

In the meantime I found a workaroung to my problem. See next post for details.

Kind regards,

Renaud

[Former Member · Accepted solution]

Hi Christophe

Found a workaround to this strange behaviour. The BAdI code of BBP_PGRP_FIND is already called when entering SC transaction (e.g. BBPSC03).

In this situation the field "is_resp_item_data-catalogid" is initial. Therefore my coding thinks it is a described requirment item and passes through the part of my BAdI code where I call the standard purch.org./purch.group determination. This then determines the wrong purch.org./purch.group based on a default product category contained in field "is_resp_item_data-category_id".

When now adding a SC item from catalog, the field "is_resp_item_data-catalogid" is no more initial. Therefore my BAdI coding runs through my own determination logic setting the purch.org. and purch.group to 9000 and 900.

But when ordering the SC it creates a wrong purch.req. in the backend. There it got the purch.org. and purch.group that was first determined when entering BBPSC03 (see explanations above). It seems like the standard coding running after the BAdI somehow remembers it and applies the wrong purch.org. / purch.group when ordering the SC.

BUT, and this is really "funny":

When you go and view the SC item details BEFORE ordering the SC, then it creates the purch.req. in backend system with correct purch.org. and purch.group (as determined by my BAdI code setting it to 9000 and 900).

The workaround I implemented now checks whether or not the BAdI code is called when entering BBPSC03. In that case field "is_resp_item_data-product_type" is initial and I leave the BAdI without touching anything. In all other cases the same field is not initial. This tells me that I'm trying to add an item to the SC. The differentiation between catalog item or described requirement item is still done using field "is_resp_item_data-catalogid". Now it works like we need it.

For those who find some time to confirm this behaviour, here's my BAdI coding of BBP_PGRP_FIND:

  DATA: is_return        TYPE BAPIRET2.
  DATA: it_objects       TYPE TABLE OF BAPI_OBJEC.
  DATA: wa_objects       TYPE BAPI_OBJEC.
  DATA: i_ekorg          TYPE ekorg.
  DATA: i_ekgrp          TYPE ekgrp.
  DATA: i_ekorg_pd       TYPE BBP_OM_PORG.
  DATA: i_ekgrp_pd       TYPE BBP_OM_PGRP.
  DATA: ls_search_catid  TYPE BBPS_ATTR_PRCAT_SINGLE.
  DATA: lt_hitlist       TYPE TABLE OF BBPS_OM_PURCH_DATA.
  DATA: wa_hitlist       TYPE BBPS_OM_PURCH_DATA.
  DATA: wa_et_purch_data TYPE BBPS_PURCH_DATA_BADI.
  DATA: wa_search_for    TYPE HRROOTOB.

* Workaround: pass through coding only if
* items are being added to SC... not when BBPSC03
* is entered

* Uncomment this and it will work...
*  IF NOT is_resp_item_data-product_type IS INITIAL.

*   If item added from a catalog, then
*   determine purch.org./group IDs from PPOMA_BBP
    IF NOT is_resp_item_data-catalogid IS INITIAL.
      CALL FUNCTION 'BAPI_PDOTYPES_GETDETAILEDLIST'
        EXPORTING
          planversion = '01'
          objecttype  = 'O'
          startdate   = sy-datum
          enddate     = sy-datum
          language    = sy-langu
        IMPORTING
          return      = is_return
        TABLES
          objects     = it_objects.

      IF is_return-number = '000'.
        LOOP AT it_objects INTO wa_objects.
          CASE wa_objects-short_text.
            WHEN 'VertLogEKO'.
              es_purch_data-PROC_ORG+0(2) = wa_objects-objecttype.
              es_purch_data-PROC_ORG+2    = wa_objects-object_id.
              es_purch_data-BE_PUR_ORG    = wa_objects-long_text+8(4).
            WHEN 'VertLogEKG'.
              es_purch_data-DESCRIPTION     = wa_objects-long_text+12.
              es_purch_data-PROC_GROUP+0(2) = wa_objects-objecttype.
              es_purch_data-PROC_GROUP+2    = wa_objects-object_id.
              es_purch_data-BE_PUR_GROUP    = wa_objects-long_text+8(3).
          ENDCASE.
        ENDLOOP.
        IF es_purch_data-PROC_ORG    <> space AND
          es_purch_data-PROC_GROUP   <> space AND
          es_purch_data-BE_PUR_ORG   <> space AND
          es_purch_data-BE_PUR_GROUP <> space AND
          es_purch_data-DESCRIPTION  <> space.
          es_purch_data-LOGICAL_SYSTEM = is_resp_item_data-product_src_sys.
          APPEND es_purch_data TO et_purch_data.
        ENDIF.
      ENDIF.
    ELSE.
*     If adding described req. item, then
*     run standard purch.org./group determination
      CONCATENATE is_resp_item_data-logical_system
                  is_resp_item_data-category_id
             INTO ls_search_catid.
      MOVE-CORRESPONDING is_object to wa_search_for.
      CALL FUNCTION 'BBP_OM_FIND_SC'
        EXPORTING
          search_for    = wa_search_for
          search_logsys = is_resp_item_data-logical_system
          search_catid  = ls_search_catid
        IMPORTING
          hitlist       = lt_hitlist
        EXCEPTIONS
          INTERNAL_ERROR = 1
          NOTHING_FOUND  = 2
          NO_AUTHORITY   = 3
          .
      IF sy-subrc = 0.
        LOOP AT lt_hitlist INTO wa_hitlist.
          MOVE-CORRESPONDING wa_hitlist TO wa_et_purch_data.
          APPEND wa_et_purch_data TO et_purch_data.
        ENDLOOP.
        READ TABLE lt_hitlist INDEX 1 INTO wa_hitlist.
        MOVE-CORRESPONDING wa_hitlist TO es_purch_data.
      ENDIF.
    ENDIF.
* Uncomment this as well to make it working...
*  ENDIF.

Hope this helps someone in future...

Kind regards,

Renaud

[Former Member · Accepted solution]

Hmm...

The behavior you describe is not strange at all. When launching BBPSC03, the SC initialization step will populate global values: from the default prod cat, you will get a default purch org/grp. So ypu BADI is called as well.

Renaud can I give you a short advise to prevent you from raising performance problems soon ?

BAPI_PDOTYPES_GETDETAILEDLIST retrieves ALL the organizational units of your system !!!

if the goal is to find the purch group named <b>VertLogEKG</b> and the purch org named <b>VertLogEKO</b>, I think it will be more direct to request table HRP1000...

To be more flexible, you could also define a custom customizing table where you define the default purch org/group and request it in the BADI.

Last point: instead of using org id long text to define the R/3 code, why don't you read the "real" R/3 code defined in function tab, in backend field ????

Rgds

Christophe

PS: please reward points for helpful answers

[Former Member · Accepted solution]

Hi Christophe

> The behavior you describe is not strange at all.

> When launching BBPSC03, the SC initialization step

> will populate global values: from the default prod

> cat, you will get a default purch org/grp. So ypu

> BADI is called as well.

Agreed. But it does not explain why in my case it takes into account the purch.org./purch.group from global values instead of the correctly values I'm determining in my BAdI code...

> Renaud can I give you a short advise to prevent you

> from raising performance problems soon ?

>

> BAPI_PDOTYPES_GETDETAILEDLIST retrieves ALL the

> organizational units of your system !!!

Thanks, I was aware of it already. Just didn't yet find the time to optimize it...

> if the goal is to find the purch group named

> VertLogEKG and the purch org named VertLogEKO, I

> think it will be more direct to request table

> HRP1000...

Good point! Now I'm able to optimize it very quickly... thanks!

> Last point: instead of using org id long text to

> define the R/3 code, why don't you read the "real"

> R/3 code defined in function tab, in backend

> field ????

Wanted to do this but couldn't find the tables containing this data... maybe you know

Kind regards,

Renaud

[Former Member · Accepted solution]

<b>Behavior:</b>

In global structure you have the default prod cat and corresponding purch group.

When adding an item, if this SC item prod cat = global prod cat, then the global purch group is copied, without launching an new purch group determination (and your BADI).

That's why you got a different result.

<b>Purch Group ID:</b>

Stored in tables HRT5500, linked to HRP5500. Or use view HRV5500A.

Can be accessed via FM BBP_OM_READ_PURCH_GRP_BE and BBP_OM_READ_PURCH_ORG_BE.

(lots of functions with BBP_OM*).

Rgds

Christophe

PS: please reward points for helpful answers

[Former Member · Accepted solution]

> In global structure you have the default prod cat

> and corresponding purch group.

What do you mean with "global structure"? The org.structure in PPOMA_BBP?

I have created this purch. structure like this (simplified representation):

our organization
   Purchasing
      POrg1
         PGrp11
         PGrp12
      POrg2
         PGrp21
         PGrp22
      POrg3
         PGrp31
   Org.Unit X
     Position A
       User a
   Org.Unit Y
     Position B
       User b
   Org.Unit Z
     Position C
       User c

In function tab I assigned the real R/3 backend purch.org./purch.groups. In responsabilities tab I assigned corresponding product categories and for which org.unit each purch.group is responsible for. But I do not see any possibility to set one of the product categories to be the global default one...?!?

Or are you saying, that one can specify a global default product category in the extended attributes of the org.unit of a purch.group? If yes, then I didn't understand this correctly until now.

For retrieving the purch.org. and purch.group ID out of the settings in the function tab of the org.structure: THANK YOU!!!

Kind regards,

Renaud

[Former Member · Accepted solution]

Renaud,

I just mean the global variable (gs_global) used in BBPSC03 program, not the HR structure. It is also used to store default settings.

Allowed prod cat for the requestors are defined in extended attribute tab. Here you can define a default one. This one will be loaded when initializing the SC (in the global "structure").

Rgds

Christophe

PS: please reward points for helpful answers