Solution Design Document

Customer: GulfCryo
Version: 1
Date: 20th June 2023

1/8
Index
Version Change History ................................................................................................................................. 3

Introduction ................................................................................................................................................... 4

Module: Adhoc Orders .................................................................................................................................. 4

Problem Definition ..................................................................................................................................... 4

Proposed Solution...................................................................................................................................... 4

Module: Milkrun Cash collection ................................................................................................................... 7

Problem Definition ..................................................................................................................................... 7

Proposed Solution...................................................................................................................................... 7

2/8
Version Change History
Previous Latest Date Module Changes
Version Version

Adhoc Orders 1. Module introduction and solution

for raised problem statement
provided.
- 1 20th June 2023 Milkrun Cash 1. Module Introduction and solution
Collection for raised problem statement
provided

3/8
Introduction
This is a Business Solution Document intended to provide a clear and detailed overview of the
requested modules to associated stake holders. It enables a better understanding of the
specific functionalities, requirements and objectives. One of the key features of this
documentation is its provision of clear and concise steps to handle the user stories associated
with each requested module. By providing step-by-step instructions, the documentation offers
guidance on how to implement and address these user stories effectively. Importantly this
documentation assumes a significant role in the development process. It serves as the sole
reference point for development on the requested module and its associated feature lists.

Module: Adhoc Orders

Problem Definition
GulfCryo serves as a manufacturer and distributor for the gas industry in the MENA
region. Distribution of the gases occurs in 2 ways a. Bulk b. Package c. Milkrun. Sales orders for
every movement get punched in the MSD 365 by GulfCryo Sales team, serving as the FnO ERP.
MSD pushes the sales order – delivery note information to FERO through API Integration for
Transport and delivery management. Requirement of the gases from GulfCryo customers can
be preplanned or in an Adhoc manner. Adhoc requirements cannot align with the working
hours of the sales team. In such cases, Order fulfillment happens through offline channel. This
record of the movement in sales order may get punched next morning in MSD, for which order
has already been executed. In this cycle, GulfCryo loses the visibility of the Sales Orders and
assets utilization.

Proposed Solution
1. Adhoc Order Management:
a. Operational Interface: FERO
b. Description: FERO will introduce a new Order management module named
“Adhoc Order Management”. This module will serve as a standalone section to
track and monitor the adhoc order requirements. Adhoc order requirements will
be provided for Bulk and Package movements. Trip management for adhoc
orders will not be provided. Adhoc orders will not be considered for any FERO
provided reports, dashboard and calculations.
c. Process Flow:
i. User with given access to the Adhoc Order management module will be
able to view, create and update the orders respectively.
ii. Upon getting the gas requirement, the user will create a new Adhoc order.

4/8
 iii. On creation of the order, the user will be asked to link the driver and
assets to the order.
iv. Upon successfully delivering the order, the dispatcher will mark the same
as “Delivered” by providing the delivery information such as POD,
delivered item quantity, etc.
d. User Story:
i. As a GulfCryo operations team member, I will receive the
emergency/adhoc Gas requirement from Customer on offline channels.
ii. I will create an adhoc order by mentioning the customer – customer
address, items and required number of quantities.
iii. I will link the Driver and Assets with the Orders who are going to perform
the delivery to mentioned customer.
iv. The driver will complete the delivery and return to the warehouse.
v. As a dispatcher, I will collect the delivery information against provided
orders.
vi. As a dispatcher, I will mark the order as “Delivered” in Order management
by providing the POD, Delivered Quantity and amount collected through
cash if available.
vii. As a dispatcher and user with given access to the module, I will be able to
list, filter and search through all the order created through Adhoc
movements.
2. Sales Order Creation:
a. Operational Interface: MSD 365
b. Description: MSD 365 and FERO have a feature called “On Site Order”.
c. Process Flow:
i. The sales team will punch the Adhoc customer requirement in MSD 365
after the actual delivery of the order.
ii. Sales team will create a Sales Order in MSD 365
iii. Upon enabling the On-Site flag by the Sales team, delivery note for
created sales order will be integrated into FERO as same.
iv. Operations team will mark the delivered inventory in MSD 365.
d. User Story:
i. Though customer gas requirements may have been met during the night, I
will create a new Sales order for delivered requirements in MSD 365 on
next morning.
ii. As a sales manager, while creating a sales order I will be given an option to
mark the order as an On-Site.
iii. I will mark the delivery note as available for integration.
iv. As an Operations member, I will provide the delivered quantity of
inventory in Inventory managements.
5/8
 3. On-Site Order Execution:
a. Operational Interface: FERO
b. Process Flow:
i. FERO will receive the Delivery note as an on-site order. This order has
already been executed in FERO.
ii. The mentioned on-site order will not be available for any MSD inbound
integrations to restrict the duplication of data on either system.
iii. Available data in on-site orders will be considered for the FERO provided
reports and dashboard.

6/8
 Module: Milkrun Cash collection

Problem Definition
GulfCryo serves as a manufacturer and distributor for the gas industry in the MENA
region. Distribution of the gases occurs in 2 ways a. Bulk b. Package c. Milkrun. Milkrun orders
are those for which drivers take the necessary assets and inventory and make a trip without
prior orders. Driver goes to designated areas and sale the gases. Delivered quantity to a
customer gets punched in as a Milkrun Order in FERO. All milkrun orders serve the Cash/COD as
a payment type. Milkrun items have a designated minimum selling price and drivers may sell
above this value. Driver will collect the cash from Customer location for sold items. MSD 365
will create the sales order for delivered milkrun orders through integration with FERO. To
generate a sales order, MSD requires line-item sold unit price and net amount. As this
information is getting missed on delivery platoform, MSD 365 cannot auto generate Sales
Order.

Proposed Solution
1. Milkrun Item Master:
a. Operational Interface: FERO
b. process flow:
i. FERO has introduced the milkrun item master. All the items available in
the master will be available while creating the trip for the milkrun.
ii. Base/Minimum unit price for the milkrun items will be created and
updated through MSD integration in FERO.
iii. Users with milkrun item master create/update access can create or
update the item master and unit price manually.
iv. Note: Currency will only be stored in MSD 365.
2. Milkrun Trip Management:
a. Operational Interface: FERO
b. Process Flow:
i. Dispatchers will create a milkrun trip by assigning the Driver, Asset and
Milkrun Items information.
ii. The driver will start the milkrun trip through a mobile app.
iii. The driver creates a direct order by delivering required items to
customers.
iv. To mark the order as delivered the driver will be asked to fill in the line-
item quantity and net price for each line-item. Driver will not be allowed

7/8
 to fill the amount below multiplication of quantity sold and line-item base
price.
v. FERO mobile app will calculate the Net amount by unit price and delivered
quantity of every line item.
vi. The driver will complete the trip by delivering orders on the following
steps 3 to 5.
vii. Dispatchers will be able to view and update the trip details by accessing
the Milkrun Trip Management.
viii. Dispatchers can correct the delivered quantity and unit price against every
line item of an order.
ix. Once the dispatcher marks the trip as complete, Milkrun orders will be
sent to MSD 365 with orders, line items and unit price.
3. Sales Order Creation:
a. Operational Interface: MSD 365
b. Process Flow:
i. On marking the trip as complete in FERO, milkrun order will be sent to
MSD 365.
ii. MSD 365 needs to take the currency from the given item code and legal
entity.
iii. Based on the provided data, MSD 365 will auto create sales order and
delivery note against legal entity.

8/8