Oracle Retail Merchandising System (RMS) - Purchase Orders

Welcome again Oracle Retail fans. Purchase Order functionality is one of the key and a critical functional in RMS. Understanding PO in RMS, can help in turn understanding many other business processes like Procurement to Pay, Fulfillment, Receiving etc. In this article, I'm going to talk all about RMS Purchase Orders. Please note that this post is a continuation of Oracle Retail Merchandising System Deep Dive article and if you are a beginner, you may want to visit Oracle Retail Merchandising System Overview article before proceeding on this article, however, it is not completely necessary.

Also, as mentioned in my earlier posts, this article covers each and every detail required for Item related questions in Oracle Retail Merchandising Systems (RMS) Certification (Pearson Vue Exam Number 1Z0-453) preparations. 

In Oracle Retail, the purchase order is a legal agreement between a supplier and retailer for the purchase of merchandise.  Key information on any purchase order includes the supplier, terms, dates, items, quantities, costs, and locations. In RMS purchase order functionality touches the following key buying processes:

·         Creation and Approval of the purchase order

·         Communication of the PO to the Supplier and other systems

·         Receipt of an Advanced Ship Notice (ASN) against the purchase order (this could be one more many)

·         Supplier shipments of the product on the purchase order

·         Receipt of the product on the purchase order at the store or warehouse

·         Receiving/Entering the Invoice from the supplier for the product shipped on the purchase order

·         Matching of the Invoice against the purchase order and receipts

·         Paying the supplier for the product on the purchase order

Purchase Orders in base RMS can be created:

·         Purchase orders can be created manually by a buyer for non-basic items and replenishment of basic items

·         Purchase orders can also be created and approved automatically from an external system based on the replenishment parameters that have been set for items at the store locations.

·         Purchase orders can be created against entered contracts and deals, or directly through direct store delivery

·         Vendor Managed Inventory (VMI) from the supplier

·         Copy from an existing purchase order

·         RMS also provides the ability to maintain the items, locations, and quantities ordered for purchase orders.

Following is the high level diagram for any PO Creation in RMS:

Order Header

Purchase orders are written in RMS for one supplier or supplier site (if enabled).  Supplier sites are set up in RMS as a one to one relationship with the supplier.  When the supplier site is added to the purchase order, the payment terms, currency, payment method, EDI indicator and Quality Control indicator are defaulted from the supplier site. The order header can be divided into fields that default, that are mandatory and that are optional. Most of these defaults from the supplier. 

Following are the key default, mandatory and option fields on PO Header:

}  Default ◦      Status ◦      Currency ◦      Exchange rate ◦      OTB date ◦      Terms ◦      Payment method ◦      Include on order ◦      Quality control ◦      EDI PO ◦      Revisions exist ◦      Pre-Mark	ð  When the purchase order is first created the status defaults to worksheet. The currency is the currency that the supplier’s invoice will be paid in. The exchange rate will be used in the conversion from the system’s currency to the currency that the supplier needs to be paid in. ð  OTB date is the open to buy end of week date that purchase order dollars will be applied to. OTB is allotted to three purchasing categories by subclass/week: ·         Order of non-basic goods (N/B) ·         Buyer replenishment of basic goods (BRB) ·         Automatic replenishment of basic goods (ARB) ð  The terms and method of payment are specified at the supplier level and can be overridden if special terms apply to this particular order.  Include on Order will determine if the quantities on this purchase order will be included in the quantities reported in the ‘on-hand’ inventory bucket.  ð  QC indicates if all or a percentage of the goods coming in on this purchase order need to go through quality control before they are received into inventory.  EDI PO indicates to the warehouse that this is an edi purchase order and that and edi document should accompany the shipment.  Revisions exist will be checked in the future if the order is an edi po and has been changed. ð  Pre-mark indicates that the goods will come labeled in the correct quantities for each of its final destinations from the vendor.  This is the same as cross docking.  The only difference is that the warehouse doesn’t have to divide out the quantities for each location. ð  There are 3 types of orders. N/B, ARB, BRB.  N/B indicates a Non/Basic type which is a manual purchase order that might be created for a new product. ARB or Automatic Replenishment Basic is generated from a replenishment process but can also be chosen during the manual process and finally BRB which is a Buyer Replenishment basic. This type of order might be placed for a promotion. The order type determines which OTB bucket the purchase order dollars fall into. ð  Supplier indicates who the order is being placed with and the not before and not after dates indicate the date range when the purchase order is expected.  The Not After Date will determine the week that the open to buy dollars are decremented from but will not prevent the warehouse from receiving it if it arrives after that date.
}  Mandatory ◦     Order number (generated) ◦     Order type – N/B, ARB, BRB ◦     Supplier ◦     Pickup date ◦     Not before & after dates	ð  The order number is system generated.  The only time it would not be system generated is the buyer is using a pre-issued order number. Pre-issued order number can be given to a buyer so that he can leave purchase orders with a supplier during a buying trip and then have it entered into the RMS system when they return.  The numbers are system generated outside of the purchase order dialogue.  Each pre-issued purchase order number is validated when used and can be purged when expired (since they are created with an expiration date).  This type of purchase order looks like a manual purchase order in all other ways in that it will default to the same purchase order type as manual one and impact the same open to buy bucket.
}  Optional ◦      Payment method ◦      Location type & location ◦      Promotion ◦      Country of origin ◦      Vendor order number ◦      Customer order

Order Dates

RMS uses a variety of Purchase Order Dates to manage Purchase Orders.  The dates are listed below:

·         Written Date – This is the Date the PO was created in RMS.  This date cannot be modified.

·         Earliest Ship Date – This date represents the earliest ship date for all Items on the Purchase Order.  This date is calculated based on the order lead time and the transit lead time (pickup lead time).

·         Latest Ship Date – This date represents the latest ship date for all Items on the Purchase Order.  This date is calculated based on order lead time, transit lead time (pickup lead time) and the system option latest ship days.

·         Not Before Date – This is the earliest (first) expected delivery date to the receiving location(s), which could be a consolidator or the distribution center.  The 'Not Before Date’ lets a Supplier know that the Retailer will not accept delivery of this order before this date.  This is very important for Suppliers to plan and schedule when they will ship orders to the Retailer (consolidator or distribution center).

·         Not After Date – This date is considered the cancel by date for the Purchase Order, or the latest date the merchandise should arrive at the receiving location(s), which could be a consolidator or the distribution center.  The 'Not After Date’ lets a Supplier know that the Retailer will not accept delivery of this order after this date.

·         Close Date – The date the Purchase Order is closed, either manually by a user (who cancels remaining quantities on the PO) or by the system using auto-close Purchase Order rules.

·         OTB End of Week Date – The Open-to-Buy Date is manually entered or calculated based on the end of the week for the 'Not after Date.'  This is the Retailer's best guess as to when they expect this order to impact their planned open to buy.  This data is used in the automated posting book to automatically place an order against a correct open to buy Subclass / Week

·         Pick Up Date – This date is generally used to identify the date merchandise that would be picked up from the Supplier by the Retailer. 

·         In Stock Date – The date a retailer can expect the Items ordered on the PO to be available in Stores.  The 'In Stock Date' allow retailers to better manage the staffing of its supply chain in addition to Store Personnel who are responsible to receive delivery and process the put away of merchandise.  If this date will be used, it will be manually keyed into the form.

·         Original Approved Date – this date represents the first date the Purchase Order was originally approved.  This can be various dates, depending on the number of approvals and is system generated.

·         Cancel Date – this date represents the date that the item location quantity was cancelled on the Purchase Order.

Order Status

Purchase Orders in RMS will reside in various statuses during their life cycle.  Some statuses are changed by users online and others can be set automatically by the system.  The statuses which relate to purchase orders in RMS are as follows:

·       Worksheet – this status allows information to be added or updated on a purchase order.  A PO must be in worksheet status when it is first being entered into RMS.  In addition, once a PO is approved, it is required to be changed back to Worksheet status if certain information on the PO needs to be changed.  A PO cannot be changed to worksheet status once it is fully received. 

·       Submitted – this status indicates the PO is ready for review and approval.  No changes can be made to a PO within Submitted status.

·       Approved – the PO has been reviewed and is considered ready for communication to the Supplier.  Once the PO is approved in RMS, it cannot be deleted, only cancelled.  It is possible for a PO to be edited in Approved status.

·       Closed/Cancelled – Indicates that the PO will no longer have receipts processed against it.  All items on the PO are either received in full or the outstanding quantity has been cancelled.  A receiver unit adjustment (RUA) in RMS can modify the receipts on the PO. 

o    Reinstate a closed PO

Order Cost

The unit cost on the items on the purchase order is defaulted from the Item / Supplier / Sourcing country but can be overridden by the user.  When overridden by the user, an audit trail of the cost change is maintained in the system. When a cost change event for an item/supplier is created, the user has the option to update the cost on existing open purchase orders that have not been received.

RMS will automatically close purchase orders under various scenarios, which are described below.

1.     Orders that have received quantities equal to or greater than the ordered quantities are closed by the nightly batch.

2.     Orders that are approved, but have never been received, and have no outstanding shipments or appointments are closed by a batch process.  This is based on a system parameter, Approve PO Close Delays, days that have passed after the Latest Ship Date.  In this scenario, any outstanding order quantities are cancelled, the status of the order is changed to closed and the close date is set to the system date.

3.     Orders that are approved, have partial receipts but have outstanding order quantities, and the system parameter, Partially Receive PO Close Delay days, have passed after the Not After Date are closed by the batch. Any outstanding order quantities are cancelled, the status of the order is changed to closed and the close date is set to the system date.

4.     Orders that were never approved, are in worksheet status, and are not replenishment orders will be deleted by the batch, after system parameter worksheet PO clean up days have passed.

Order Maintenance

An approved purchase order can be modified until it is received.  The following elements may be changed on purchase orders:

·         Addition/Deletion of Items

·         Cost Changes

·         HTS Code Changes

·         Quantity Change

·         Delivery Location Change

·         Dates Change

·         Retail Change

Some changes require the purchase order status to first be changed to worksheet. Once the changes are final, the PO will be re-approved.  RMS keeps the history of PO in revision tables and users will be able to view the new and old PO's. 

Distribution

At the time of creation, items can optionally be distributed.  Retek allows distribution by SKU, style or item list.  This is the starting point for distributing the product down to the item/location level.  There are 2 ways available to distribute further:

·         All items simultaneously

·         Using filters

Distribution can be done with mainly following ways:

·         Diff 1

·         Diff 2

·         Diff 3

·         Diff 4

·         Store grade

·         Location

·         Diff matrix

·         Specific criteria

·         Specific blank fields

PO Submission & Approval Checks

Following are the soft and hard stop checks performed at the time of PO Submission:

·         Soft checks

o    Within open-to-buy

o    The item(s) are not on clearance.

o    Any stores designated as end locations are open.

o    Automatic checks

o    Quantities rounded to supplier pack size

o    Distributed quantities are rounded to store order multiple.

·         Hard stops

o    All items within the same department if department level orders are required.

o    Supplier minimums/maximums are met.

o    The item(s) are active.

o    Buyer Packs marked as eaches are exploded to item level components.

Following are the soft and hard stop checks performed at the time of PO Approval:

·         Soft checks

o    Open-to-buy is checked and reduced.

·         Hard Stops

o    Check PO meets supplier minimums and is within supplier maximums ($, qty., weight).

High Level Steps for PO Creation

Field Detail	Required	Functionality
Order Number	Yes	Contains the number that uniquely identifies an order within the system. This number is automatically generated when a Purchase order is created.
Order Type	Yes	Indicates the type of order and which Open To Buy bucket will be updated.  Valid values include: 'N/B' - Non Basic                                                'ARB' - Automatic Reorder of Basic ‘BRB’
Import Country	Yes	The identifier of the country into which the items on the order are being imported.  This field will default to US and can’t be changed after items have been added.
Supplier	Yes	Contains the supplier number who will provide the merchandise specified in the order. This field is populated with the RMS Supplier ID associated with the Supplier Site ID.
Supplier Site	Yes	Contains the supplier site number who will provide the merchandise specified in the order.
Importer / Bill-To Type	No	Valid values are I'M (porter) and E'X (porter).  This is the default importer/exporter type assigned to the supplier of the Purchase order.
Importer / Bill-To Location	No	This identifies the importer/exporter location assigned to the supplier.
Routing Location	No	This is the default routing location for the import order.
Terms	Yes	The Payment terms that should default when an order is created for the supplier. This field will be populated from the supplier. These terms specify when payment is due and if any discounts exist for early payment.
Pay Method	No	Indicate how the purchase order will be paid.  Valid options are: 1.     Bank Letter of Credit 2.     Private Letter of Credit 3.     Wire Transfer 4.     Open Account (check)
PO Type	No	Contains the Purchase Order type for the order.
Department	No	Contains the department number for orders limited to a single department and will be Null for orders involving items in more than one department.
Location Type	No	This field contains the type of location in the location field for orders limited to a single location and will be Null for orders involving more than one location.  Valid values are:  Store or Warehouse.  When the PO is for a single location, this field will be populated.
Location	No	If populated, this field identifies the location all items on the order will be delivered to (i.e. it will mean a single location order).  When the PO is for a single location, this field will be populated.
Promotion	No	Contains the RPM promotion ID associated with the order to provide a link between the order dialog and the promotions dialog.
Country Of Sourcing	Yes	This field defaults to the Country Of Sourcing of the items on the PO.
Order Currency	Yes	Contains the currency code for the order. When creating an order within RMS, this field will always default to the currency of the supplier, but it can be overwritten.  This field will default from the supplier and today is always USD.
Order Exchange Rate	Yes	The rate of exchange used for the purchase order between the order and primary currencies.
Pickup Date	No	Contains the date when the order can be picked up from the Supplier.  This field is only required if the Purchase Type of the order is 'Pickup'.
Not Before Date	Yes	Contains the first date that delivery of the order will be accepted.
Not After Date	Yes	Contains the last date that delivery of the order will be accepted.
OTB End of Week Date	Yes	This field contains the OTB budget bucket the order amount should be placed into.  This field will default to the week ending date of the Not After Date.  Used for reporting.
Vendor Order Number	No	Contains the vendor's unique identifying number for an order.
Import Order Indicator	Yes	Indicates if the purchase order is an import order.   Options are Yes and No.  Defaults to No.  Automatically set to Yes if items on PO have different Country Of Sourcing than the PO Header Import Country.
Include On Order Indicator	Yes	Indicator to determine if the order should be included in on-order calculations. Options are Yes and No.  Defaults to Yes.  Yes - include the order in the on-order calculations No - do not include the order in the on-order calculations
QC Required Indicator	Yes	Determines whether or not quality control will be required when items for this order are received.  Options are 'Yes' or 'No'.
EDI PO Indicator	Yes	Indicates whether or not the order will be transmitted to the supplier via an Electronic Data Exchange transaction. Valid values are: Y = Submit via EDI N = Do not use EDI
Revisions Exist Indicator	Yes	This indicator defaults to No and is automatically checked when PO revisions exist.
Pre Mark Indicator	Yes	This field indicated whether or not a supplier has agreed to break an order into separate boxes so that the boxes can be sent directly to stores.  This indicator will trigger whether allocation data is sent via EDI.  It defaults to No and is only enabled if the Supplier Pre-Mark indicator is set to Yes.
Customer Order Indicator	Yes	This field indicates whether or not the order is generated for a customer.  When checked the PO Customer Maintenance form is enabled so that the customer information can be associated to the order.
Prepack Indicator	Yes	This indicator must be checked to allow PO specific packs.
Comment	No	A free form text field that can be used to capture any miscellaneous comments attached to the PO.
Buyer	No	The buyer associated with the order.
Status	Yes	Select the status of the order. Valid values include: 1.     Worksheet – orders interfaced from FlexPLM start in this status 2.     Submitted – will not be used 3.     Approved 4.     Completed

Summary Note

As mentioned earlier, Purchase Order is one of the vast functionality in RMS and I'm sure I might not have covered many details. Please do top a note or let me know if you want any additional topic covered in this area related to PO's in RMS. 

In next article, we are going to dive more in Oracle Retail Merchandising Systems functionalities and try to understand all about Stock Counts in RMS and best practices to use that. 

You may also want to refer to parent article Oracle Retail Merchandising Systems - Deep Dive. Do drop a note in case you have any question, comments or feedback.

— Share It —

• Facebook
• Twitter
• Google+
• Linkedin
• Pin It

About Nagesh Mishra

Nagesh Mishra - A Passionate Oracle Retail Certified Professional with more than 17 years of overall experience in IT industry and more than 15 years of domain expertise in Oracle Retail Applications. Worked extensively in diversified fields of Product Implementation, Business Consulting, Pre-Sales, Application Software Development, Maintenance and Support and Re-Engineering Oracle Retail projects.