I set SRM as ECS (extended classic scenario), I create a PR with service line and transfer to SRM , in performing sourcing screen, I create PO reference this service PR, but the system creates a Backend PO not local PO. PO creation of no service PR is normal with SRM local PO.
Please tell my why, I think that it must have a Note provided to correct, Am I right?
ECC: SAPKH61711, SRM: SAPK-71311
Are you replicating the service PR to SRM via ESOA?
If so, then I have to say that this is how standard system works.
Let me explain firstly as below.
1. If you replicate PR with RFC transfer (report BBP_EXTREQ_TRANSFER):
When user creates PR with service and transfers using RFC, we create SC with outline type as HIER. Since we do not support nested hierarchy in RFC transfer, we use one outline (HIER) and one or more service lines under it. While creating SC, we consider each service line and check if it is EP or classic. But we ignore the Outline as it is only dummy from SRM point of view. So in all follow-on cases, i.e. SOCO, finding SOS, or creating follow-on documents, we ignore outline and consider only the functional items. Even in SOCO, since we look for functional items, we get SUBTYPE as EP and logical system as SRM. In this case, we could have extended classic PO.
2. If you replicate service PR with ESOA:
Not handling service hierarchy was SRM limitation when we consider integrated scenario, while ERP was handling it with no issues. So in SRM 7.0, we introduced SOA for tranfering PR from ERP. While doing this design, we also considered having nested hierarchy from PR in SC. So we introduced HIER_SE template and grouping level M.
Owing to the complexity and bring in the behavior like ERP, we also introduced handling follow-on activities at top outline level (like SOS, SOCO, creating follow-on document). So since outline is coming from ERP and we don't set secnario (classic or extended classic), from SOCO it allows only to create classic PO. Since SRM PO doesn't support hierarchy and since grouping level M can have nested hierarchy, SRM is designed to have only classic PO for this scenario. If we use HIER_SRM in case of ESOA, we can still do the extended classic PO, but we might loose out the hierarchy structure from ERP.
Considering the reasons above, if you want extended classic PO, I'm afraid you have to consider to handle this in DOC change BADI (setting BE_LOG_SYSTEM and SUBTYPE at outline level).
I hope this could provide you with some understanding of the design.
Check the below points and ensure everything is maintained according to settings defined below:
1. In SPRO :"
SAP Implementation Guide
> SAP Supplier Relationship Management
> SRM Server
> Cross-Application Basic Settings
> Activate Extended Classic Scenario
2. Check if any code in bADI :
3. Check number ranges :
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.
4. Do debugging using below link :
If nothing works then you might want to raise to SAP .
but it should work if everything is done correctly as in the links mentioned .