Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
maciej_jarecki
Contributor
Description

On every project where sales is done through multiple sales channels there is always same problem – stock allocation. How to protect stock for example per distribution channel or even per Customer within distribution channel. Of course company will not accept lack of solution and either functional solutions are applied or custom development is done. The simplest one that I've seen, was to protect stock with batches. In sales order batch was mandatory and determination is either on distribution channel or Customer. Each batch has characteristic of distribution channel or Customer. Allocation is done with transfer posting from generic to specific batch. Solution works quite well until Client doesn't have articles batch managed in SAP.

Second option that could be interesting is to create for each distribution channel separate storage location. In sales order storage location field is mandatory and determination of storage location is done within user exit based on sales area. Solution is not so nice as if we would like to allocate quantity per distribution channel and Customer then number of storage locations are needed to be created plus more complex determination cause that solution is becoming hard to maintain. In both cases ATP check works well as executed either on storage location or batch level.

Finally we get a solution from SAP. Cross-Channel Order Management for Retail is whole addon to SAP IS-Retail, but contains as well mechanism called, Stock Pools. SAP Cross-Channel Order Management is addon for SAP IS-Retail that allows you to manage and fulfil orders from Customers.

Due to this article describes only short part of it for more details please visit:

 

https://help.sap.com/viewer/2b5019f8cc17451b83bbd49e7d17cc9a/2.0/en-US

SAP Fashion Management with Order Allocation Run also is partially use this functionality.

https://help.sap.com/doc/saphelp_fms10/1.0/en-US/76/4c18530e209254e10000000a4450e5/frameset.htm

Terminology needed:

Hard Allocation

Whenever you create Sales Order, ATP check is performed (depends on configuration of requirements class and schedule line type) and confirmed quantity is recorded for each schedule line. Later on if not full quantity of order has been confirmed or orders with higher priorities have been created, backorder processing is possible to shuffle available quantity. However, when the time of logistical execution and delivery to the Customer comes closer, it’s necessary to change this to real hard allocation, which is understood as a fixed assignment between open sales orders and the stock available in the delivering site.

The hard allocation transaction allows you to allocate available quantities to a list of sales orders, contracts, or stock transport orders. Hard allocation processing consists of three steps, Stock Selection, Stock Allocation and Fix Allocation. Logic to be used of each step is configured by assigning class (that implement proper interface) to respective step.

Fix allocation

This is exactly quantity that is allocated to particular schedule line of Sales order or generally to Sales Contract or STO. Only Sales Order that has schedule lines with fix allocation can be delivered to the Customer. During the fix allocation step (one of the steps of hard allocation processing), it is decided if in the run of allocation, quantity  becomes fix or reserved depending on the allocated quantities and release rate.

Free floating

This is quantity of stock (used by hard allocation) that remains available to be distributed after satisfying all open quantity of active pools. Decision if pool can use free floating quantity is done on stock pool level.

Stock pool

As described at the beginning stock pools are kind of virtual segmentation to protect particular quantity of your stock for some purpose like distribution channel or promotion segmentation. Stock pools limit the quantity that is available for allocation. The important is that stock pool can be time dependant or undefined in time.

Customizing

All customizing is done under Sales->Cross-Channel Order Management for Retail.

First step is to active stock pool per site under general settings:



For particular site like in example above (second row)

  • Hard allocation is activated.

  • Stock pools use in ATP is activated – means that stock pool for site is active.

  • Stock pools in hard allocation is activated – that means that during hard allocation, quantity available for allocation could be limited by pool quantity. Example presented later on.

  • Stock pool priorities:

    • Limited priority means that pool can only use their available quantity plus free floating

    • Full priority pool takes it’s available quantity plus available quantity of other stock pools with lower priority




Under Stock Pools node

For General settings there is an option to select if stock pool determination is done on sales order item or header level. By default determination is done on header level. Additional setting to activate time-dependence for stock pools is done here.



Under Maintain Rule Types for Stock Pool Calculation node, we can assign class that will be used during distribution of stock pools calculated available quantity.



Example

Below few steps that are required to go through after configuration to set up stock pools functionality in system.

Set article relevant for stock pool with transaction /WOM/SPREL - Set Article Relevance for Stock Pools.



Set up stock pools with transaction /WOM/SPID - Stock Pool Header Definition



In above case three stock pools were created.

  • Prio column - describes priority of each pool. This is required in case if on site level configuration has been set to Full Priority or in case of Limited Priority during shortage situation.

  • FFQ column – exclude pool from use of free floating quantity.


Stock situation is following:

  • Stock 82 PC

  • Inbound delivery for 12 PC on 18/10

  • Inbound delivery for 16 PC on 26/10




Stock pool maintenance is done with transaction /WOM/SPWB - Stock Pool Workbench Maintain. In my case article is assigned to each previously created pool.



Calculation logic (as described before standard class is used to calculate quantities) and meaning of columns is following:

  • Pool – this is quantity available for pool.

  • Open – quantity still available from pool.

  • Pool Pot. – It’s a quantity that potentially can be used by pool. Due to limited priority each pool can use only assigned quantity plus free floating quantity (if not forbidden in pool definition like in case of Pool 2). Calculation is done in following way: ATP quantity deducted by all other pools open quantity.

    • Pool 1 calculation is: ATP: 110 – Pool 2 open quantity 25 – Pool 3 open quantity 10



  • HA Pot. – It’s quantity that potentially can be used for hard allocation (if stock pool usage in HA activated for site in general configuration). Calculation logic is following: HA qty (stock quantity) deducted by all other pools open quantity plus Pool GI qty.

    • Pool 1 calculation is: HA qty: 82 – Pool 2 open quantity 25 – Pool 3 open quantity 10 – Pool 2 quantity used - Pool 3 quantity used + Pool 2 GI qty + Pool 3 GI qty




Pool 2 has been forbidden to use free floating quantity that’s why potential quantity and hard allocation potential quantities are equal to open quantity.

Let’s create three Sales Orders. Assignment between Customer and Pool is done in Customer master data on dedicated screen for Cross-Channel Order Management.

First Customer uses Pool1.

  • Delivery date 15/10, Quantity 20 PC, Confirmed quantity 20PC (max quantity 75PC, pool plus free floating quantity)

  • 16230504


Second Customer uses Pool2.

  • Delivery date 19/10, Quantity 15 PC, Confirmed quantity 15PC (max quantity 25PC, only pool quantity)


After two placed Sales orders Pools situation now is following:



  • Pool Pot. = ATP – Pool 2 open quantity – Pool 3 open quantity => Pool 1, 75 – 10 – 10 = 55

  • HA Pot. = HA qty – Pool 2 open quantity – Pool 3 open quantity – Pool 2 quantity used – Pool 3 quantity used + Pool 2 GI qty Pool 3 GI qty => Pool 1, 82 – 10 – 10 – 15 – 0 + 0 + 0= 47


Third Customer doesn’t use any pool, means quantity is taken from stock (in this case system created artificial stock pool)

  • Delivery date 12/10, Quantity 25 PC, Confirmed quantity 12PC/12PC/1PC (max quantity 40PC, ATP quantity – open pools quantity)

  • Pool situation now is following:


After Sales orders has been placed Pools situation now is following:



  • Open quantity remains the same, because quantity has been consumed from stock

  • Pool Pot. = ATP (changed from 75 to 50 PC) – Pool 2 open quantity – Pool 3 open quantity => Pool 1, 50 – 10 – 10 = 30

  • HA Pot. = No changes to open pool quantity and pool used quantity means no impact on HA Pot. Quantity


After posting goods issue to Order1 (Pool1, quantity 20PC) and Order3 (No pool, 12PC only first schedule line that is confirmed) situation is following.



  • Pool Pot. = No changes to ATP quantity and pool open quantity means no impact on Pool Pot. Quantity.

  • HA Pot. = HA qty – Pool 2 open quantity – Pool 3 open quantity – Pool 2 quantity used – Pool 3 quantity used + Pool 2 GI qty Pool 3 GI qty => Pool 1, 50 – 10 – 10 – 15 – 0 + 0 + 0 = 15


 

Time dependent stock pools have valid from and valid to field at the header level. Activation of time-dependency is done in general setting for stock pools. In this type of pools, important to remember is that date used to check validity of pool can differ per program where calculation is requested. In Stock pool workbench by default date to calculate is system date but in ATP it’s confirmed delivery date. Calculation logic regarding open quantity remains the same, but still not all pools are taken into consideration.

  • Date is before the date in the SP Header Valid From field. Pool quantity is calculated as normal by considering pool priority from header data. All open quantities from stock pools that fulfil this condition are taken into account.

  • Date is after the date in the SP Header Valid To field. Available pool quantity is not calculated for pools for which the date is after the SP Header Valid To date. The open quantity for these pools is also not considered when calculating quantity for other pools. That is, stock pools that have a SP Header Valid To date that lies in the past are no longer considered in the Stock Pool Workbench.


 

Stock pool and hard allocation

In general setting for Stock Pool there is an option to activate Stock Pool use for Hard Allocation. This setting is done on site level and indicates if stock pools quantity should be deducted from hard allocation quantity.

As a continuation of previous example I create new Sales Order for a Customer from Pool_3. At the moment open pool quantity is 10PC with potential quantity 25PC. HA quantity is 50PC but for this particular pool it’s only 10PC (based on current stock, other pools open quantity, HA quantity already used and GI quantity for other pools).

Sales order has been created for 19PC (with limitation of 25PC due to Pool 3 potential quantity). Now if I would like to do hard allocation, system will only do allocation of maximum 10PC.



But if you deactivate use of Stock Pools in Hard allocation then you can allocate up to 40PC but in the case of this Sales Order, you can allocate full 19PC quantity.
Labels in this area