PO Transaction Type (Document Type) determination in Classic Scenario

[SF111]

Hi,

We currently have SRM 7.01 up and running in Extended Classic Scenario for part of our company but as part of our next rollout, I'm using BADI BBP_EXTLOCALPO_BADI to override the Configuration and force the PO's to go out via the Classic scenario.  For the Extended Classic PO's, we have them copying into ECC as document type ZEBP but for the PO's going over using the "Classic" scenario, I would like to change the document type to ZSRM instead. Here are the changes I've made so far to try and make this happen:

1)  I've created the ZSRM PO document type in the ERP system

2)  I've created the matching ZSRM transaction type in config in the SRM system and assigned it to the BUS2201 Transaction Category (SRM Purchase Order)

3)  I've created the number range in ERP and assigned this number range as an "External" one on the SRM side and and assigned to my new ZSRM transaction type

4)  In the organizational structure I set the "Document Type in R/3 System" (Attribute ID BSA) for the company code/plant/and purhasing group levels to be my new ZSRM document

I then went in and created a requisition for the new plant and used sourcing cockpit to convert it into a PO.  The PO shows up in the ERP system but it created as a ZEBP document type and not my new ZSRM document type (and the number range it used was wrong).  I'm not sure what I'm missing here.  I thought that the organizational structure changes would force the PO to create as the ZSRM but it didn't work.  Can anybody tell me what I may have missed as part of the setup?  Since I'm programatically forcing these PO's to be "Classic" scenario through the BADI, am I also going to have to make changes in another location to override the Transaction/Document type  as well?

Thanks in advance!

Hal

[SF111]

I've gotten a little further with this request.  I went into org structure and set the "Document Type in R/3 System" (Attribute BSA) to my new document type ZSRM and I did the same thing for "Transaction Type: Create PO Manually" (Attribute DP_PROC_TY) but here are the problems I"m still hitting:

1) Right now, if I create an "Ad-hoc" PO that must be converted using sourcing cockpit, the PO is generated in the backend with the correct document type (ZSRM) and number range (30***) but the sourcing cockpit returns an error saying that "Purchasing document 65***** does not exist".  It appears that SRM is still wanting to assign a 65*** number internally even though the PO in the backend system has a completely different number range.  I'm still trying to figure out how to debug this to fix the mismatch here.

2)  On Catalog orders where the shopping cart goes through approval and then automatically creates the PO, all of my new ones for this process are failing and getting stuck in the "Approved" state.  If I look in the Shopping Cart errors in Application Monitors, all I get is "Error creating follow-on document".  I'm still trying to figure out the proper way to debug these but not having a whole lot of luck so far.

[former_member22425]

Hello Hal,

What is the logic you are using in the BBP_EXTLOCALPO_BADI .

Regards,

Rahul

[SF111]

Hi Rahul,

We created a custom implementation of the base BADI and we added the following code to the "DETERMINE_EXTPO" method:

method IF_EX_BBP_EXTLOCALPO_BADI~DETERMINE_EXTPO.
  CONSTANTS: c_comp_code_1001 TYPE bukrs VALUE '1001'.
  CLEAR: bbp_extpo_gl-bbpexpo.

*extended classic will be activated only for specific company codes
  IF item_data-be_co_code  = c_comp_code_1001..
    bbp_extpo_gl-bbpexpo = ''.
  ELSE.
    bbp_extpo_gl-bbpexpo = 'X'.
  ENDIF.
endmethod.

For right now we have the company code to check against hardcoded but in production we'll changes this into a table lookup.  We haven't made any changes to the DETERMINE_EXTPO_CREATE method though. 

edit: Forgot to mention that we extended the interace so that we could pass the be_co_code value through item_data.

[ricardo_cavedini]

Hello,

I faced a similar issue in my system.

I created an implementation of BBP_DOC_CHANGE_BADI for shopping carts and I am assigning to the field BE_DOC_TYPE the PO document type.

In my case I am assigning the PO document type to field BE_DOC_TYPE in shopping cart based on product categories.

As I could see, system assigns the first value found from BSA attribute. In order to ensure that assignment will be correct, I am using the BAdI.

Regards,

Ricardo

[SF111]

Hi Ricardo,

I'll give that a try this morning and see if that straightens it out. 

Thanks for that idea!

Hal