Scoping Document

Project Perseus - Sales Order to Delivery Order Transformation – To Be System Process Vision

Objectives (linked to FMCG Strategic Imperatives 2022):

 Enhance operational efficiency: improve end-to-end processes by challenging and removing
manual, repetitive and administrative tasks
 Drive Customer intimacy: improve our Customer Service process for Key Customers, utilizing
automation / EDI whenever possible

High Level Requirements:

1. Create transparency and reduce manual intervention for order processing as much as
possible. Human intervention should only be required in case of issues / exceptions
2. Support the users in order management, giving them a clear and transparent overview of what
is in the order pipeline and the issues which need addressing. When issues arise, the user is
made aware of the issue by the system
3. Provide transparency to our customers on order status and actively communicate to them
when orders are confirmed, and when order issues are encountered

MoSCoW prioritisation
(must-have, should have, could have, won’t have)

Requirements Mo S Co W

Order Receipt and Capture

1. Orders are received from the customers and captured via ‘real’ EDI.
Real EDI: Sales Order is created automatically in the system after
order receipt and processing starts without human/manual
intervention required
Pre-requisite/Requirements to Create a Standard SO in SAP:
a) Order Type
X
b) Customer Number (Sold-to Party, Ship-to Party) (In S4: Customer
is known as Business Partner)
c) Purchase Order Number (Opt)
d) Material Number
e) Order Quantity
f) Plant, Shipping Point (Opt), Route (Opt)
g) Pricing (Net Value) – Either via manual or automatic entry

2. The system can receive orders through different customer order

formats (to be defined – should have several options) to begin the
automatic processing at DKSH
X
The above pre-requisites/requirements have to be included in the
source file (other system/format) and are then mapped to the target
file (SAP)
3. There is visibility over which system an order has been originally X
generated in, if the order comes from a sub-system (order created via
 Excel/ eCommerce system / POS system / etc.)
We can have the sub-system or filename (if the information comes
in via a file e.g. .csv, .txt, .xls) maintained in the SAP system and a
customized report to extract such information out for viewing
purposes.
4. The system automatically checks for data conflicts in the received
order vs data maintained in SAP (and corresponding threshold)
There are some standard SAP validation for EDI available and we can
also add on to it. For example:
a) Check if Purchase Order Number is filled in the file (Std)
b) Check if the Customer Number is flagged for deletion (Std)
c) Check if there is Discrepancy between the source and target
price
d) Check if Requested Delivery Date is in the past (Std)
e) Check if the Material Number is flagged for deletion (Std) (for X
discontinued stocks)
f) Check the validity period for promotional items
g) Check for substitution material

The SO document that did not pass the above validation can either
be saved with warning messages or not created at all. The EDI error
messages can be stored and viewed via a customized report.

- Pricing depends on Incoterms (check if CG has)

Order Processing

5. The system automatically performs a credit check against the

customer, verified against their payment status/history and credit limit
There is a SAP standard credit check and credit block. Credit block
occurs when either the credit limit has been exceeded or there are
overdue payments. The check happens during creation of manual X
sales order and so it will also be there for EDI orders with
assumption that the credit master data (credit limit and risk
category) has been maintained.
(In S4: There is a new module for credit management processes and
credit master data is parked under Business Partner as well)
6. The system automatically checks the stock availability including
customer requirements re: shelf-life, and assigns the correct quantity
in accordance with the defined customer allocation criteria
SAP functionality: ATP check / Batch search strategies etc.
There is a SAP standard check for stock availability and batch search X
strategy based on what are the settings setup. The check happens
during creation of manual sales order and so it will also be there for
EDI orders with assumption that the material master data
(availability check and batch management) has been maintained.

7. The system automatically calculates the correct lead times to the X

customers (taking into consideration cut-off times / goods processing
times / customer requested delivery window etc.) to verify if delivery
 on the requested date is possible
SAP functionality: Shipping point / Route management etc.
There is a SAP standard calculation for lead time, transit time, pick
and pack time based on what are the settings setup. The check
happens during creation of manual sales order and so it will also be
there for EDI orders with assumption that the material master data
(availability check and batch management) has been maintained.

- Material master – in transit, pick, pack

- Route master – lead time also depends on logistics partner
(murali)

8. In case of no encountered issues (perfect order), the order flows

through without manual intervention, and the Delivery Order is
created automatically ‘at the right time’ (criteria to be defined in detail
at a later stage – depends on requested delivery date)
X
If it is a flawless sales order, there is SAP standard process where the
delivery order can be created immediately upon saving the sales
order. There are some standard criteria available for this process, for
e.g., by customer/material/plant.
Order Issue Resolution

9. The system flags any order processing issue in the order to the
nominated DKSH user to action and resolve. After the issue is
X
resolved and the order released (or unblocked), it re-enters the
standard flow

10. If the ordered quantities are higher than the current stock-on-hand,
the system automatically allocates the quantities available to the
‘right’ customers based on different allocation criteria defined by the
business X
SAP functionality: Back-order processing / Product allocation etc.
- Standard process
11. If there is insufficient stock-on-hand, the system proposes to the
DKSH user (for action) the possible delivery dates based on the
replenishment and stock in transit data
SAP functionality: Replenishment lead times / PO processing / GR X
processing times etc.
- Material master – got run MRP (local and global) (Ian)
- Are lead time of replenishment maintain in the ROP

12. The user can manually adjust the allocation of available materials if
needed.
X
SAP functionality: Re-allocation (CO06 / CO09)
- Check with MM team (Ian)
Order Reporting & Management

13. There is an overview that provides ‘live’ visibility of the orders in the X
system, their processing status as well as outstanding issues that
 must be resolved
SAP functionality: Sales Order Monitor/ Incomplete Sales order status
- Standard worklist
14. There is a list of actionable tasks generated for each nominated user,
based on order issues which require resolution (which have been
appointed to them). Each task will have a required due date X
- Customized wf (Yew Lun)
- Standard wf
15. There is an overview/report to provide visibility on ‘perfect orders’ and
orders with issues (including historical data). The report should
provide data/analytics on order issue volumes, allowing a view by X
customer, client and other chosen variables.
- Error viewing through SAP IDOC
Customer Service, Care and Communication

16. In case of a ‘Perfect order’ with no order issues (or upon order
completion), DKSH should notify the customer with an order
confirmation.
The method/channel of order confirmation is to be defined based on
the level of customer service required and/or the customers’ X
requirement. This could be an automated notification sent to a
customer email address, or verbal contact.
In case DKSH ‘human’ action is required, the system should notify
the respective individual of the task to action.

17. In case of order issues for which the customer should be informed (to
be defined), DKSH shall contact the customer in a timely (TBD)
manner.
The method/channel of notification is to be defined based on the level
of customer service required and/or the customers’ requirement. This X
could be an automated notification sent to a customer email address,
or verbal contact.
In case DKSH ‘human’ action is required, the system should notify
the respective individual of the task to action