Online Tutorials & Training Materials | STechies.com
Register Login

Extended Classic Scenario (ECS) Limitations on limit and service PO

|| || 0

Extended Classic Scenario (ECS) Limitations on limit and service PO
Stechies

In case of extended classic scenario, when creating shopping carts with more than one limit items irrespective of the data ( that is, vendor, document type, purchasing group, company, location, performance period, etc) in each item (although they are identical), when ordering the shopping cart, always separate PO's will be created for each item. This is the standard behaviour of the local PO creation in all the releases until SRM 4.0 (SRM_SERVER 500).

For example, a shopping cart with 2 limit positions is ordered, always two PO's will be created but not one PO for two items.

This is a consulting note which gives additional information on the limitations of the limit and service PO's in case of extended classic scenario.

This behaviour is due to the split criteria performed for creation of local PO's in case of extended classic scenario.

Split Criteria is performed when creating a local PO out of the following:

  • Shopping Cart
  • Sourcing Cockpit (External requirements and Shopping Carts)
  • Bidding Scenario (only when Bid Invitation is created out of Sourcing cockpit.


Splitting is not performed when PO is created out of manually created Bid Invitation.

Additional splits are done in following cases:-

  • Always split extended limit items
  • Always split if there is a missing vendor
  • Items grouped by hierarchies are split to separate PO's.

List of splitting criterias in case of SRM 3.0 (EBP 4.0).

  • proc_org Purchasing Org
  • proc_group Purchasing Group
  • co_code Company Code
  • Pcins Procurement card company
  • Pcnum Procurement card number
  • ext_quote_id External Quotation
  • logsys_fi Logical Financial System
  • ext_dem_logsys Logical System from where an External requirement comes
  • ext_dem_posid External Requirement Item Number
  • Subtype Item Subtype (Extended, local scenario)
  • guid_ven Vendor Guid
  • guid_prpven Desired vendor Guid
  • suppl_addr. Ship to address fields
  • Doc_type Process Type

This behavior is caused by the way we convert SRM POs to R/3 POs
A PO in SRM can have several Limit and Service Items.
In R/3 also we can have as many Material items & services as we want but only 1 limit per item. And R/3 can only handle 99 different account assignments (for example 80 cost centers and additionally 19 order numbers).That is, because we are creating only one package.


Related Articles