In the Extended Classic scenario, what creates the PO on the SRM side?

Hi Experts,
This sounds like a simple question, however, I've been unable to find the answer.
What I am looking for is the process (report, workflow or function module etc etc) that actually creates the PO on the SRM side once the shopping cart has been approved (before it is replicated to ECC).
The reason for this is, after a support stack upgrade, the creation of the PO seems to have slowed down once the shopping cart has been created. I'm trying to track down where the PO gets created and what triggers that to happen, in order to work out why it isn't as quick as it was prior to the upgrade, but can't piece together the full end to end process.
I can see the "Workflow Without Approval Shopping Cart" workflow that obviously Releases the shopping cart and sets the status to Approved... I can then see the equivalent workflow for the PO (Workflow Without Approval for PurchOrder), but I can't work out the bit inbetween -
- How does the PO actually gets created in SRM and what triggers that to happen?
Any help will be gratefully received - thanks in advance.

its an event related to the shopping cart business object- BUS2121.
your approval workflow should be of status set released, which will trigger the methor BBP_REQREQ_TRANSFER, finished approval is the event which will be triggered by the workflow, based on this event, system will trigger reqreq_transfer.

Similar Messages

Freight is not updated in R/3 in the Extended Classic scenario

Friends,
Freight is not updated in R/3 in the Extended Classic scenario.
Once a PO is ordered, if a freight condition in SRM is applied, it does not get updated in R/3.
We have created a condition for Freight (Value and Percentage)in Create
Payment Conditions using the following menu path:
spro
--> Supplier Relationship Management
--> SRM Server
--> Cross-Application Basic Settings
--> Pricing
--> Process Payment Conditions
When creating a Purchase Order in SRM in the "Item Data" tab, there is
a"Pricing" option. Choose "Pricing" and select "Add Further Conditions"
from the drop down menu. Here Freight is available. Add Freight and
the PO record in SRM is updated with the Freight Condition. However,
upon ordering, the Freight condition does not transfer to the PO
recordin R/3.
We've heard this can be achieved by enhancement: only ie by implementing
set of BADIs.. But does anyone know WHICH BADIs we need? Or how we could find out? Thanks.

Hi
<b> You can either of these BADIs to handlwe the scenario.</b>
BBP_CREATE_BE_PO_NEW Exit while creating a purchase order in the backend system
BBP_CREATE_PO_BACK   OLD Exit while creating a PO in the backend system
BBP_ECS_PO_OUT_BADI ECS: PO Transfer to Logistics Backend
BBP_EXTLOCALPO_BADI Control Extended Classic Scenario
Hope this will help.
Please reward suitable points.
Regards
- Atul

Are you using the Extended Classic Scenario ?

Hello everybody,
Is somebody using the Extended Classic Scenario - SRM 4.0 ?
If yes, could you describe briefly the config steps that you follow ?
I have received and followed some advices here and I have checked all the official documents without success.. =( Until now, for some reason the EBP tries to create the PO in the backend =(
Thanks for your help guys !
Regards from Mexico.
Diego

Hi Diego,
If you activated the Extended scenario, the system cannot try to create directly a PO in the backend, it first has to create it localy.
If you are sure that:
-You activated the Extended scenario in SPRO (and not in the BADI)
-The system tries to create directly the PO in R/3 (as you say in your post)
Then there are only 2 solutions:
1- You have activated the scenario BADI, and tell the system to work in classic scenario
2- You have a bug in your SRM (which I doubt, cause I implemented this scenario on EBP 3.5, EBP 4.0 and SRM Server 5.0, and I never had this kind of problem).
Regards.
Vadim

MM-SUS for the extended classic scenario

Hi,
I have done SUS-MM for the classic scenario.
Did anyone implement SUS-MM for the extended classic scenario ?
Did you face any problem or will it be same as 'classic' scenario ?
Please help
Thanks
Pranav

There shouldn't be any problem especially when the scenarios are concerned. Since the PO's moves from MM-SUS.
Regards, IA

Extended Classic Scenario not creating backend PO

Hi All
We are just starting with SRM (Using SRM 5.0 SRM Server 5.5) and trying to decide to use Classic or Extended Classic.
I can get the Classic working were an approved SC creates a backend PO without any problem. However when I switch on Extended Classic the backend PO is not created from an apporved SC.
In RZ20 my error is Shopping cart 1000000080 (PReq. ): BBP_BD 002 Buffer table not up to date and Table BBP_DOCUMENT_TAB is empty
In config I activated the extended classic scenario as well as activating the backend purchasing groups as responsible. Under sourcing I also defined for the relevant product categories as "1 - Sourcing Never Carried out"
Am I missing something obvious??
Many thanks for any help.
Daniel

Hi Daniel,
In reference to the info. you have provided, it looks like you have not switched to Extended Classic Scenario properly.
Once you say you are on ECS, the P.O should get created in SRM and the copy of it should get replicated to R/3.
As you said you have flagged both the check boxes in SPRO for ECS activation, try activating sourcing also.
SPRO > IMG > SRM > SRM Server > Sourcing > Choose one Product category for which you want to create shopping cart and set the setting as " Sourcing Always carried out".
Check whether the approved shopping cart is coming to Sourcing cockpit or not.And from there try to create a P.O by assigning vendor.
Also ensure that no BADI is activated which converts ECS to Classic scenario for the Product category you have choosen.
If this cycle woks then definitely what you require will also work.Clarifications are welcome.
Award points for helpful answers.
Rgds,
Teja

Can we use the Extended Classic Scenario with MM-SUS

HI, expert :
    In extended classic scenario ,the PO created in SRM system ,and then replicated into the MM system .You can't change it in MM system .
    So, in this situation ,I want to know the MM-SUS can be suitable or not ?The PO can transfer from ECC to SUS ?
   If I use the decoupled scenario ,which one I can select ?MM-SUS or EBP -sus ?
   BR !
Alex!

Hi Alex,
as noted by Bill, in MM-SUS is the extended classic not possible at all.
By default it's also not supported in the SRM-SUS. Please see the note 543544. If you would like to activate this, you need to pay a consulting fee for SAP:
"Please note that the full scenario can be enabled by a consulting solution, compare OSS note 700350."
Regards,
Peter

Extended Classic Scenario - how does the integration work ?

Hi,
Apologies for asking a basic question, but we are looking at requirements for integrating SRM with R/3 using the extended classic scenario and I need to understand how the integration actually works ? How is the data transferred between the 2 systems ? Does it use BADI's, idocs etc ?
Many thanks,
fiona

Hi Olaf,
I just wanted to give some precision on what you said (in the thread How to "see" PO in EBP ? also)
The Extended classic scenario only refers to the local PO creation replicated in R/3.
In this scenario, in the R/3 PO only the data not managed/sent from the SRM are available for modification (which depends on the SRM version you use)
The "PR transfer from R/3" is called "Plan driven procurement", and in this scenario only RFC is used, the qRFC are only used for BDocs of the CRM Middleware.
Regards.
Vadim

Extended classic scenario - no backend PO created

I try to activate the extended classic scenario. It's not activated in customizing, tried to do it only with BADI implementation for special material groups. We are able to create POs in SRM but transfer to backend doesn't work.
I get following error messages in application monitor as backend application errors:
No instance of object type PurchaseOrder has been created. External reference:
PO header data still faulty
Document number 100000093 not within defined inter val
What's going wrong here?
Hubert

Hello,
Check if you have set up the customizing as below:
Extended classic scenario:
a) at SRM side:
- To assign the transaction type to the extended classic scenario you have to maintain the transaction type name (= the R/3 PO document type) to the attribute DP_PROC_TY (in contradiction to BSA in classic scenario) in PPOMA_BBP of the responsible Purchazing group.
- Create a number range for a local PO.
- Assign the local PO number range as a internal numer range to the transaction type.
b) at R/3 side:
- Enter the Number Range (corresponding to the SRM number range PO) and flag it as an external number range (trx. OMH6 Number Range for Purchasing Documents)
- Maintain the document type corresponding to the SRM transaction type and assign the R/3 number range for POs as "NoRge Ext" (field V_T161-NUMKE) (trx. Document type within Purchase Order Customizing)
- Make sure that the SRM and R/3 number ranges match are exactly the same.
Kind regards,
Ricardo

Extended Classic Scenario - SHC: Buffer table not up to date

Hello all,
I'm working in SRM_SERVER 550, SAPKIBKT11, and having issues using BACKEND PURCHASING ORGANISATIONS and the Extended Classic Scenario.
According to SAP note 944918 the following indicator should not be required to be set:
Supplier Relationship Management>SRM Server>Cross-Application Basic Settings>Activate Extended Classic Scenario --> extended classic scenario active.
I did set the Backend Purch. Grps Responsible indicator, and I did create organizational units specifically for the backend purch. grps.
We need to set the main part of all SHCs to ECS, but when I do set the indicator in customizing to "extended classic scenario = active", I get a dump in my web environment: 'buffer table not up to date'.
What is causing this failure in my SHC?
I tried to implement BAdI "BBP_EXTLOCALPO_BADI" (method DETERMINE_EXTPO) like described below here: without the line bbp_extpo_gl-bbpexpo = 'X'., I can continue and create the SHCs. Problem is though: all SHCs will get marked as Classic Scenario. So, to make sure the SHCs will always get marked as ECS, I have added this line in the BAdI. Unfortunately this immediately results in the 'buffer table not up to date' error in the SHC itself, as soon as I try to open the details of the new item.
Hope you help me out here?? It doesn't seem to be related to the BAdI, but somehow the system doesn't allow me to mark SHC items as ECS.
Thanks & Regards,
Berend Oosterhoff
SRM Consultant Accenture Technology Solutions - The Netherlands.
BAdI BBP_EXTLOCALPO_BADI:
method IF_EX_BBP_EXTLOCALPO_BADI~DETERMINE_EXTPO.
data definition----------------------------------------------------*
DATA:    wa_mattype     TYPE BAPIMATDOA,
           wa_char18      TYPE MATNR,
           attrib_tab     TYPE TABLE OF bbp_attributes,
           wa_attrib_tab TYPE bbp_attributes,
           wa_value       TYPE om_attrval,
           wa_product_id TYPE comt_product_id.
    bbp_extpo_gl-bbpexpo = 'X'.
from here I did the specific selection for the SC, but that's not relevant here.

Hi Prashant,
Thanks for your quick reply!
Note 1085700 is about Short Dumps when creating or changing a contract. I am trying to create a Shopping Cart, without a reference to a contract. BAdI BBP_DOC_CHANGE_BADI is not active in our system.
Any other thoughts?
Regards,
Berend

Extended Classic Scenario - PO Update issue

Hello experts.
We are working with SRM 5 in the extended classic scenario and we have a serious problem in a productive environment for the following case.
(01) We create a purchase requisition (PR) in R/3 with several items;
(02) We send PR to the SRM generating a shopping cart;
(03) The buyer creates a PO for all items from the shopping cart;
(04) The PO is transmitted to R/3;
(05) For some cases buyer changes the PO wich is sent back (updated) to R/3;
So far so good. The problem happens when some item in the request already has GR or Invoice. In those cases when the PO is updated on SRM, its transmission to R/3 does not occur, generating an error log that can be seen in transaction RZ20 of SRM.
I understand that if any GR or Invoice exists for the item it can no longer be modified, but is it expected that no other item can also be modified from SRM? What is the expected behavior for this case?
Moreover, even if the GR and Invoice have been canceled, we are still unable to update the PO in R/3 from SRM. Is this a expected behavior? It was our understanding that the PO should be updated if all incoming documents (GR, Invoice, SES ..) were completely canceled.
We appreciate any help on this matter.
Thanks and Regards,
Evandro Miasato

Hi, Masa,
Thank you for your advice,
I set the method U:Print Using Berkeley Protocol, after that
in trx. SP01 I have the Error Status on Composite Document -
Status Incorrect (Reason Unknown).
Best regards,
Guzal.

Configuration steps for Extended Classic Scenario

Hi All,
Could you please let me know what are the configuration steps required for extended classic scenario.
Thanks in advance

Hi,
Important Settings that Determine the Extended Classic Scenario
The following settings are required for the extended classic scenario:
u2022 At least one backend materials management system and accounting system is connected to the SAP SRM system and defined in the configuration setting Define Backend Systems.
u2022 Product categories from the backend procurement system are replicated and used in the SAP SRM system.
u2022 The target system for each product category is the backend system in the configuration setting Define Backend Systems for Product Category. Optionally, BADI BBP_DETERMINE_LOGSYS is implemented to determine the backend system.
u2022 The extended classic scenario is activated in the configuration setting Activate Extended Classic Scenario. Alternatively, BAdI BBP_EXTLOCALPO_BADI is implemented to control the extended classic scenario based on customer defined rules.
u2022 If the backend system is an SAP R/3 version lower than 4.6B, you must define local purchasing organizations and purchasing groups.
u2022 If the backend system is an SAP R/3 version 4.6B or higher, you need to map the purchasing group used in the purchase order to the backend purchase group in one of the following ways:
u2022 Use a backend purchasing organization and purchasing group in the shopping cart and purchase order.
u2022 Use BAdI BBP_PGRP_FIND to determine a backend purchasing group in the shopping cart.
u2022 If a local (created in SAP SRM without reference to a backend system) purchasing group and purchasing organization are used, then a valid backend purchasing group is assigned to the RFC user that created the backend purchase order. This assignment is made in the backend system using user parameter EKG in Transaction code SU01.
u2022 Implement the user exit of the BAPIs BAPI_PO_CREATE1 (EXIT_SAPL2012_001 and EXIT_SAPL2012_003), and BAPI_PO_CHANGE (EXIT_SAPL2012_002 and EXIT_SAPL2012_004) to determine the purchasing group with a customer- specific logic.
This is for your additional information.
Hope this helps.
Regards,
Vikas

Convert classic in extended classic scenario

hai,
i wanted to convert classis scenario into extended classic scenario.what are all the steps that i needed to be follow.does it require any implementation of badi?how the po will be sent to the r3 in display mode?
could anyone give the solution
Edited by: chakradhar nannapaneni on May 11, 2009 12:45 PM

Hi,
1.     Activate the extended classic scenario
When the extended classic scenario is set, SRM generates a local purchase order for each item in the shopping cart. All follow-on documents are created in the backend system as well as locally in the SRM
2.     Activate IPC pricing
Since SRM 3.5 IPC (Internet Pricing Configurator) pricing is mandatory for extended classic implementations.
In the classic scenario you can replace the IPC by the simplified pricing
IMG SRM: Sap Implementation Guide  Supplier Relationship Management SRM Server  Cross-Application Basic Settings  Activate Extended Classic Scenario
IMG SRM: Sap Implementation Guide  Supplier Relationship Management SRM Server  Business Add-ins for SRM Pricing
Check whether the BAdIs relevant for the pricing are activated correctly and filled with the correct coding:
BAdI                                     I            PC Pricing (Extended)          Simplified Pricing (Classic)
BAdI: BBP_PRICEDATA_READ
Implementation:. BBP_PRODUCT_PRICE                     Not active         Active
*BAdI: PRODUCT_UPDATE2
Implementation. IPC_UPD_PROD_BUFFER2     Active         Not active
Regards,
Abraham

Service Procurement in Extended Classic Scenario

Hi,
We are planning to use SRM 7 EHP 1 with backend ECC 6 EHP 4. We are leaning toward the extended classic scenario. However we are a bit confused reading some documentation that saying Service Procurement classic can only be used in classic scenario.
What does this mean? To put this in more simple, can we have this scenario in extended classic deployment:
PDP:
1. We create PR with 2 items, each item have 3 sub-line services,
2. We push this PR to SRM
3. We create PO in SRM and it is copied to ECC.
4. PO will have 2 items, with each item have 3 sub-line services.
Self Service Procurement:
1. We create SC with 2 items, each items have 3 sub-line services,
2. We create PO in SRM and it is copied to ECC
3. PO will have 2 items, with each item have 3 sub-line services.
Really appreciate if someone can clarify this point.
Best regards,
Josh

Dear Josh,
For your scenarios below:
Self Service Procurement:
1. We create SC with 2 items, each items have 3 sub-line services,
2. We create PO in SRM and it is copied to ECC
3. PO will have 2 items, with each item have 3 sub-line services.
The shopping cart and PO in local SRM system does not support service hierarchy (Service subline) in the system.
PDP:
1. We create PR with 2 items, each item have 3 sub-line services,
2. We push this PR to SRM
3. We create PO in SRM and it is copied to ECC.
4. PO will have 2 items, with each item have 3 sub-line services.
Here also, the system will not create po in the local srm system. The local PO cannot support service hierarchy. The system by default create the purchase order in the backend system directly.
Thanks and regards,
Ranjan

SUS / no goods receipt doc to backend in extended classic scenario?

Hello
have you any find a solution for problem
in SRM/SUS and goods receipt in extended classic scenario. Gr remains only in SRM not going to backend...
Brg Harri
Message was edited by: Harri Harkonen
Message was edited by: Harri Harkonen

Hi Christophe,
We also have this issue. Goods Receipt from SUS is created in SRM but is not posted in backend (we have implemented extended classic scenario).
I tried to use the BBP_DOC_SAVE_BADI to created an idoc which posts the material document in backend system (using fm IDOC_GR_CREATE).
The goods receipt is posted in backend this way.
Unfortunately we are not able to cancel or make a return delivery on this GR.
I am very interest in your FM. Could you please share this, or tell me what changes you made to the GR in SRM.
Thanks in advance.
Rgds,
Martijn

Extended Classic Scenario, BADI for PO creation in R/3

Hi,
We are using the extended classic scenario. When the PO gets replicated from SRM to R/3, right now the field CATALOGID is not being transmitted to the backend R/3 system.
1) What BADI should I implement (and the method) to transmit the CATALOGID to R/3?
2) After implementing the BADI, do I also have to change the BAPI?
3) Is the BAPI used to transfer data from SRM to R/3, BAPI_PO_CREATE?
Thanks and Regards,
Peter

Hi Peter,
1-You can use BBP_ECS_PO_OUT_BADI for ECS scenario.
Since the R3 PO does not have field for catalog id, the EKKO- BEDNR (Tracking Number) field can been used for example to store this information. In this BADI all the items are identified and their tracking number field is populated with a catalogue id value.
2-If you use the tracking number field, no use of R/3 BADI is required.
3-BAPI_PO_CREATE1
Please check my answers in this post :
catalogid field not going in R3 backend
Kind regards
Yann
Message was edited by: Yann Bouillut
Message was edited by: Yann Bouillut

In the Extended Classic scenario, what creates the PO on the SRM side?

Similar Messages

Maybe you are looking for