Hello, I’m Sung Hyun Yoon, and I’ll be leading the Order Process session
of the SERVEONE MRO Process course
Today’s lecture focuses on the order process
within the overall workflow
The goals of this session are:
To understand the order process within SERVEONE
To distinguish the characteristics of each order method
To identify what can be changed after an order is created
In the FAQ session, we’ll cover most common topic among sales, operations, and managers,
pre-receipt eligible documentation
I’ll explain why this documentation needs to be managed
and what information must be included
First, let me introduce myself
I’m a dad of a three-month-old daughter,
enjoying a very happy daily life these days
My hobby is playing badminton
I’ve been with SERVEONE for eight years
and currently handle operations system management and planning
Order process Overview
To briefly explain the SERVEONE order process,
it can be illustrated as shown in the flowchart
So, what is an order?
By definition
it is a request made to a seller
to produce, deliver, or provide a product or service
In today’s session, I’ll explain
how a customer requests a product from SERVEONE
and how the order process flows within SERVEONE
I'm going to explain these
First, when a customer visits SERVEONE Mall,
they search for products, add them to the cart, and confirm the purchase
After completing internal approval, the order is finalized
Alternatively, when SERVEONE receives a customer order,
it runs a simulation based on a preset logic
that considers price, product characteristics, items, and regions
Then, a purchase order is issued to the supplier
For direct-shipment, no-stock orders,
the supplier ships the products directly
After the S/O (Sales Order) is created,
for Center VMI orders,
the hub ships the products stored in its own inventory
At set intervals, transactions related to deliveries
are settled,
finalizing receivables and payables through
purchase settlement with suppliers
and sales settlement with customers
Afterward, any orders not financially realized are handled as exceptions
Do you have a general understanding of the SERVEONE order process?
Next, we’ll break it down
to review each concept and basic workflow
Refer to the process diagram
to help you understand it better
When a customer places an order and SERVEONE’s S/O is created,
the delivery method is determined through the order simulation,
and the supplier or hub ships the products
Once the delivery is complete,
purchase settlement with the supplier and sales settlement with the customer are processed,
completing the order process
Order creation simply means that
a customer places an order with SERVEONE
In daily life, when we want to buy something,
there are various ways to place an order
Visiting a store in person,
shopping online,
or requesting through a delivery service, and so on
There are several ways for customers to create orders with SERVEONE
We’ll cover four main methods
When the customer places an order directly
through the SERVEONE Mall, it’s called a Front Order
When the customer places an order directly
but through their own system,
it’s called an Integrated Order
When the customer requests offline
and SERVEONE creates the order first,
with delivery starting immediately, it’s called a Proxy Order
When the customer requests offline
and SERVEONE creates the order,
but delivery is arranged in advance, it’s called a Pre-Receipt Order
The first method is the Customer Front Order, the most common way to place an order
The customer orders on the SERVEONE Mall,
The customer selects products,
adds them to the cart, and places the order,
the system then checks for credit and budget limits
If there are no issues, the order is created,
and after internal approval, the final S/O is generated
SERVEONE Mall is where we purchase office supplies
Here, the customer searches for products,
adds them to the cart, and places an order
Once the order is created,
a message saying “Order has been created” appears,
confirming that the order was successfully placed
The second method is the Customer Integrated Order
When the customer creates an order in their own system,
the order is automatically transferred to the SERVEONE system,
and an S/O is generated there
The only difference between Front Orders and Integrated Orders
is the site used to place the order
either the SERVEONE Mall or the customer’s system
In terms of process, they are essentially the same
The third order type is the Proxy Order,
where SERVEONE’s role becomes more important
In this method, the operations manager creates an order
in the SERVEONE system based on the customer’s request data
Orders handled this way start with 700 in the SERVEONE order number,
and SSP proxy orders start with 400
This method is not available to all customers
and is only allowed for those who have signed
a Proxy Order Agreement with SERVEONE
In this process, when a customer requests an order offline,
the operations manager first reviews the attached documents
to check if they meet internal eligibility standards
Only with valid documentation, operations manager create the order in the SERVEONE system
After that, the system checks credit and budget approvals,
and if there are no issues, the order is successfully created
Compared to regular Front Orders,
Proxy Orders require more work,
such as document review and manual order creation in the system
However, based on the customer’s situation,
they are carried out by internal decisions
You might be wondering how operations managers actually create proxy orders
This process will be explained in the video,
which shows tasks automated through RPA, recorded as the PC performs them automatically
Log in to S-Portal
Check the proxy order emails in the unread mailbox
Save the documents and request files
Log in to S-MRO
Search operating units
Download the registered delivery address information
Compare the order request form with the delivery data to extract new addresses
Search postal codes (1st: Korea Post App)
Search postal codes (2nd: Daum)
Search postal codes (3rd: Road name address)
Generate the S-MRO bulk upload file for new addresses
Log in to S-MRO
Bulk register the new delivery addresses
Download the updated delivery address data
Compare it with the order request form to create the proxy order upload file
Search operating units and member IDs
Upload the documents and proxy order file
Create the order
Check the order status
Generate the result file
Log in to S-Portal
Send an email with the RPA results to the responsible manager
Lastly, we have Pre-Receipt
This applies to customers with a signed agreement
and happens before the system order is created, based on the customer’s request
It’s divided into pre-receipt order and pre-receipt processing
When the customer hasn't received the product yet, it's pre-receipt order
When the customer has already received the product, it's pre-receipt processing
As the term “processing” implies, this type handles cases where the delivery is already completed,
and the system update is done afterward
To clarify the difference between Pre-Receipt Orders
and Proxy Orders,
Proxy Orders follow the normal process,
but the order is created by SERVEONE instead of the customer
In contrast, Pre-Receipt Orders are also created by SERVEONE,
but they’re a non-standard process, orders can be created
even without budget approval or internal authorization
Think of them as an exception type outside the normal workflow
Pre-Receipt Orders and Pre-Receipt Processing are further classified
based on who makes the request and who creates the request in the system
If the customer requests directly from the supplier,
and the supplier submits it through the supplier portal, it’s called Supplier Pre-Receipt Processing
If the customer requests through sales or operations,
and operations submit it in S-MRO, it’s called Sales Pre-Receipt Processing
Do you see the section marked in red that says “Supplier Selection”?
As we’ll cover again in the FAQ,
since Pre-Receipt Processing happens after the product is already delivered,
the actual supplier who handled it must be specified
Let's look closer at Pre-Receipt Orders and Pre-Receipt Processing
For Pre-Receipt Orders, the order is registered first, and the product is delivered afterward
For Pre-Receipt Processing, the customer requests delivery in advance,
receives the product first,
and the system order is created later
Also, for both types, before the order can be marked as delivery completed,
the customer must perform a Pre-Receipt Order Confirmation
This confirmation step is unique to Pre-Receipt
and serves as a verification process between the customer and SERVEONE
to confirm how many products were pre-received and that they were indeed delivered
Wondering when Pre-Receipt is used?
Pre-Receipt is a non-standard process
used when products are urgently needed
It’s mainly applied when there’s an urgent delivery request
or when the customer’s internal approval is delayed
This means an order can be created even without budget or approval
Because of this, SERVEONE managers need to be extra cautious
Since orders can be created even with a negative budget,
you must ensure there are
no cancellations or returns due to budget issues after creating a Pre-Receipt Order
Also, when processing Pre-Receipts, if the order is placed with a different supplier
instead of the designated Pre-Receipt supplier, it can cause duplicate orders,
so extra caution is needed
Lastly, since settlement is only possible after the customer’s Pre-Receipt approval is completed,
you must always check the approval status to avoid any sales settlement issues
The smart RPA introduced earlier for Proxy Orders
is also used for Pre-Receipt Processing
Let’s watch a video to see how Pre-Receipt processing works
So far, we’ve covered the four order creation methods in SERVEONE
Front Orders, Integrated Orders, Proxy Orders, and Pre-Receipt Orders/Processing
We\'ve learned about these things
Next, we’ll move on to order modifications
Order modification covers what can be changed and managed
from the time a customer places an order
until delivery is completed
Although the actual changes are handled by the operations manager,
it’s important to understand what can be modified and how
Knowing this will help with internal and external communication,
so I’ll give you a brief explanation
First, let’s look at the overall order management types
Order management can be divided into three categories
Customer-related, supplier-related, and internal tasks
Customer-related tasks include handling order cancellation, returns, and exchanges/AS,
following up on customer system inquiries, managing urgent delivery requests
Supplier-related tasks include
handling supplier requests, managing partial deliveries, checking purchase order details and delivery schedules
Internal tasks include managing integration error orders, verifying POs, handling delivery proofs and basic docs
These are the main tasks
The scope of order management is very broad,
but here we’ll focus only on a few items that can be modified
in the order inquiry screen
Most customer-related changes
can be handled here
Customer information
Shipping address, cost, department, purchase reason, and reference codes
These can be changed
You can also update approver information in the SERVEONE system
when the customer’s internal approver changes
In addition, you can modify the sales information for an order,
such as currency (KRW, USD, etc.) and distribution channel, including doemstic, local, direct or indirect export
For integrated customers, any changes made in the customer’s system
are not updated in real time for orders that have already been created
In such cases, details like the PR number or PO number
can be manually updated in the order
You can also attach files to an order, not just update text fields
Attaching files
helps streamline communication between the customer, supplier, and SERVEONE
Through these order management features, you can handle customer requests
Next, we’ll briefly talk about Pre-Receipt documentation,
a topic that often comes up in inquiries
After that, we’ll wrap up today’s session
What if Pre-Receipt is handled without documentation and only through verbal requests?
It could lead to communication errors,
wrong products delivered, incorrect quantities,
or even duplicate orders if the request
goes to the wrong supplier
To minimize future issues
and keep proper records,
documentation is essential
Sales and operations managers must also be able to
review customer-provided documents and judge whether they are valid and risk-free
The purpose of Pre-Receipt documentation
is to clearly confirm the customer’s request and delivery status
when products are supplied or requested before a system order is created
For both Pre-Receipt Orders and Pre-Receipt Processing, you must verify what products
and how many were requested
For Pre-Receipt Processing, you must also confirm
whether the products were actually delivered through the specified supplier
By verifying these details with proper documentation
before creating the system order,
you can prevent settlement issues later on
The required documents vary depending on the request channel
The goal is to minimize creating separate documents
and instead use existing data whenever possible
For example, you can use the customer’s Pre-Receipt form,
closing documents, weighing slips, or interface-linked data
as valid Pre-Receipt documentation
From this page through the next nine pages,
you’ll find explanations of the different Pre-Receipt proof types,
including real case examples, required fields, and important notes or exceptions
This is the basic Pre-Receipt request form
As shown in the example, it must include the following required fields
customer name, requester, signature, supplier,
product name, quantity, and specifications
If the same proof is provided as an Excel file,
its content can be modified,
so you must verify separately, via email or another method
that the customer actually requested the order with those details
Next is a VOC Pre-Receipt case received through the customer front
In this case, since the system already confirms the customer’s request or receipt,
you only need to verify the product and quantity without requiring any additional documents
The next case involves a supplier transaction statement
The statement must include the product name and quantity,
and you must also confirm which customer actually received the products
through the customer’s signature
Next is the customer Pre-Receipt request form
Regardless of the template used, it must include product information,
and after obtaining the customer’s signed confirmation, the supplier’s name must also be specified
The next case is the customer’s closing documents
In the email agreed upon with the customer, make sure the closing data or receipt details are mentioned,
and confirm that the document includes all necessary information, such as product name, ID, and quantity,
to enable order creation in the system
A weighing slip can be used as proof of delivery by attaching a screenshot of the slip
However, since it lacks order details,
you must also include additional information such as
requester, product name, product ID, and order quantity
This is the Pre-Receipt interface screen
For certain customers, if Pre-Receipt data is received through the interface from the customer’s system,
that data itself is considered valid documentation
In this case, the interface data can replace the customer’s signature,
but you must ensure that all required fields are properly included
Alright, we’ve now covered the key topics
Order creation methods, order management, and Pre-Receipt documentation
I hope this session helped you understand the basics
Thank you for your time and effort
Thank you