Skip to Content

This blog summarizes how the standard will behave when handling creation of classic Purchase Order from RFx response and shopping carts in Sourcing Cockpit (SoCo).

First of all, let’s identify some different situations while creating PO in SRM:

 

1 – From RFx Response using “Create PO” 

Here, user will be allowed to choose transaction type because, at this time, system does not have the information on what type of PO will be created.

Despite of the value that user is selecting here, PO will be created with BSA attribute determined in PPOMA_BBP.

 

Pic1. Pop-up from “Create PO” in RFx response

create_po.JPG

 

Pic2. Transaction type defined in PPOMA_BBP for Local and ECS scenario (DP_PROC_TY)tx_typePO.JPG

 

2 – From RFx response using “Simulate and create PO” 

Here, system is in simulation mode and identifies that a backend PO will be created. Hence, no transaction type is listed and PO is created with BSA attribute determined in PPOMA_BBP.

 

Pic3. Pop-up from “Simulate PO” in RFx responsesimulate_po.JPG

 

Pic4. Attribute BSA in PPOMA_BBP for classic scenariobsa_att.JPG

 

3 – From Sourcing Cockpit (SoCo) 

Here, system will determine according to the shopping cart category. In case it identifies that category belongs to classic scenario, no transaction type will be available and PO will be created based in the attribute BSA determined in PPOMA_BBP.

 

Pic5. Step 3 in SoCo after creating draft POSoCO_txtype.jpg

 

From several notes and information regarding this behavior, we can understand that:

1712226 – Explains the standard behavior since previous releases (BSA attribute for backend POs)

2021864 – Incorrect behavior that was fixed with note 2049504

1580116 – Explains in detail how the behavior is done in SoCo

In this wiki page here you also find code explanation when determining Classic and Extended transaction types in SoCo.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply