This chapter gives an overview of the information maintained by RMS and RMS integration with other applications.
RMS is the System of Record (SOR) for the following:
RMS contains data that must be populated at the time of installation. Either the data is required by the application, or the data is static and can be loaded for any client. The code tables CODE_HEAD and CODE_DETAIL are examples of tables with system-required values that must be loaded at the time of installation. Additional codes can be added as needed to these tables after installation, by either using the online form or additional client scripts. Customization of the seed data is based on the client's requirements.
Additionally, some configuration tables must be populated for the application to open and function correctly, even though the configuration values can be modified later. These configurations are maintained in System Options set of tables, and are required for initial setup that can be updated prior to the implementation, to reflect final configuration.
Foundation data is the base for all future information on which RMS builds. This information needs to be present before you begin using the system. The majority of foundation data can be set up online; more commonly, a client performs a data conversion process to import this information from legacy systems.
Foundation data consists of three types of information:
Organizational hierarchy
Merchandise hierarchy
Supplier and partner management
The organizational hierarchy allows you to create maximum of six levels of hierarchy relationships to support the operational structure of your company.
In a Retail store, the customer walks through the store and buys, retails procure goods from suppliers and the retailer acts as a customer. In a Franchise store, the retailer supplies goods to the franchise customers, the retailer acts as a supplier and tracks the sales.
You can create a preferred organizational structure to support consolidated reporting at various levels of the company. You can also assign responsibility for any level of the hierarchy to one or more people to satisfy internal reporting requirements.
The organizational hierarchy also supports two types of stores to satisfy the franchise requirements:
Franchise
Company
A company store act as retail store in RMS.
The Franchise stores are used to support franchise business models. Other applications, such as RPM and RWMS, view franchise stores as they would view any other store in RMS; however, RMS performs special processing based on the store types.
The merchandise hierarchy allows you to create maximum of six levels of hierarchy relationships to support the product management structure of your company. You can assign a buyer and merchandiser at the division, group, and department levels of the merchandise hierarchy. You can also link a lower level to the next higher level. For example, you must indicate to which group a department belongs, or to which division a group belongs.
A supplier supplies the merchandise and a partner is involved in other financial taxation that results in an invoice. Supplier and partner management provides functionality to create and store valid merchandise suppliers and partners. You can maintain a variety of information about suppliers such as financial arrangements, inventory management parameters, types of EDI transactions, and invoice matching attributes. Suppliers are typically created in a financial system and interfaced into RMS; supplier enrichment can be maintained in RMS.
The supplier structure can be extended to supplier-parent and supplier-site relationships, to accommodate financial systems that support this configuration. A supplier site is a location from which the supplier ships merchandise.
RMS is responsible for the creation and maintenance of all items. RMS uses a flexible data hierarchy for an item, with levels that allow you to model items in a desired way. The hierarchy consists up to three levels, highest (level 1) to lowest (level 3). Within the defined levels for an item family, one level is denoted as the transaction level. This is the level at which all inventory and sales transaction takes place. This model gives retailers a flexibility to create families of items that share common characteristics.
RMS creates several types of items, such as regular items, deposit items, packs, concession items, consignment items, and transformable items.
Through item maintenance, RMS also maintains the relationships of items with other entities such as suppliers, locations, and attributes.
The Purchase Order module allows you to create and maintain purchase orders in a variety of ways. It provides commitments to vendors for products in specific amounts for specified locations. Purchase orders are created manually or automatically through replenishment or from an external system. They can be created against entered contracts and deals, or directly through direct store delivery or Vendor Managed Inventory (VMI). RMS also provides the ability to maintain the items, locations, and quantities ordered for Purchase Orders.
The contract dialog gives you the ability to create, maintain, submit, and approve contracts. A contract is a legally binding agreement with a supplier to supply items at a negotiated cost.
In RMS, the contracting functions fit closely with the replenishment and ordering functions. The main functions of the Contracts window are to book manufacturing time, track supplier availability and commitments, and match them with business requirements. The main business benefit of contracting is to achieve supplier involvement during the planning phase of a retailer's business.
Deals management allows you to create and maintain deals with partners or suppliers. Deal partners can be suppliers, distributors, and manufacturers. Within a deal, clients create deal components, specify the items for each deal component, and define thresholds.
Components are deals or parts of deals that a retailer receives from a supplier. There can be multiple components in a single deal. You must define thresholds to define the quantity or amount that must be purchased or sold to receive the deal. RMS components include off-invoice deals, rebates, vendor-funded promotions, vendor-funded markdowns, and fixed deals.
You also define the items and locations for which the deal can be applied. You can choose to include or exclude locations as necessary.
You also define the Proof Of Performance (POP) terms for a deal. POP terms are defined by the deal vendor that offers the deal. For deals, POP terms are defined at the deal, deal/component, or deal/component/item-location combination. For fixed deals, POP terms are defined at the deal level.
The deal pass-through functionality allows a percentage of a deals discount to be passed from a warehouse to a franchise store. This functionality applies to franchise stores.
For clients that choose to use supplier sites with RMS, deals are managed at the supplier parent level.
For cost changes, the Cost Management dialog gives you the ability to:
Accept cost changes received through EDI (flat files)
Create a cost change
Edit a cost change
View a cost change
A cost change is an adjustment to the supplier cost of an item, either up or down. Before you create a cost change, you must create a list of user-defined cost change reasons and then apply a reason to each cost change. This is useful in reporting.
The initial cost of an item is established at item setup. The cost of the item is adjusted in the item record until the status of the item is Approved. After the item is approved, any cost changes needs to be handled through the cost change dialog.
When a cost change is submitted through EDI, the EDI cost change is reviewed and released to create a cost change document. The cost change document is then viewed and submitted for approval.
When a cost change document is created online, you enter the cost change, an event description, an effective date, and a reason code, and then submit the cost change for approval.
After a cost change is approved, the item/supplier cost record is updated. Any outstanding purchase order line items with no received units are recalculated, if recalculation is indicated on the cost change.
Additionally, you use the Cost Management dialog to create cost zone groups for zone-type expenses for item estimated landed cost. Zone-type expenses are incurred when imported goods are moved from the discharge port to the purchase order receiving location. Because the expenses can vary depending on the distance between the discharge port and the receiving location, cost zones can be configured to appropriately reflect the expenses. The locations (stores and physical warehouses) must be grouped to reflect the expense variances for moving the goods. Normally a zone strategy is used for these cost zone groups, but it is possible that every location within the company has different expenses to move the goods from the discharge port. If that is the case, a store strategy would be used. If every location within the company has the same transportation costs from the discharge port, a corporate strategy is adequate (but not when multiple currencies are being used). After these cost zone groups are defined, they are added to new items as they are created, in anticipation of the expense profiles that are needed for the items.
Support for multiple sets of books provides better integration with financials systems that supports Multiple Sets of Books within a single installation. Multiple Sets of Books option is enabled by default in RMS and the client will need to set up additional location-specific foundation data, including:
Organizational units Transfer entities Set of books IDs
Inventory functionality in RMS is the core of the application. Inventory is tracked perpetually and financially in RMS. The following describes perpetual inventory tracking. For information on financial inventory tracking, see Stock Ledger.
RMS achieves inventory control through functions that include transfers, Return to Vendor (RTV), Inventory Adjustments, Sales Upload, Purchase Order Receipts (shipments), Stock Counts, Allocations, Franchise Orders and Returns, and Customer Orders.
Transfers in RMS provide an organized framework for monitoring the movement of stock. RMS creates and maintains transfers; however, you can also interface transfer information into RMS from other systems.
RMS supports a number of different types of transfers such as intercompany transfers, book transfers, Purchase Order-linked transfers, externally generated transfers, customer orders and franchise order. Transfer functions also support the movement of one or more items between two internal RMS locations, and multi-leg transfers in which the intermediate location is considered a finisher location. Finishers are locations where work is performed on merchandise, such as dying fabric and attaching labels.
Mass return transfers are used to reallocate merchandise to locations or to return merchandise to the supplier.
Return to Vendor (RTV) transactions are used to send merchandise back to a vendor. The RTV transaction in RMS allows one or more items to be returned to a single vendor. For each transaction, the items, quantities, and costs are specified. Upon shipment out of a location, inventory is removed from the stock on hand.
RTVs are created manually in RMS or imported from an external system. RMS also provides the ability to maintain RTVs. Shipped RTVs create a debit memo or credit note request (based on supplier configuration) in the invoice matching staging table in RMS, for export to Oracle Retail Invoice Matching.
Inventory adjustments are used to increase or decrease inventory to account for events that occur outside the normal course of business (for example, receipts, sales, stock counts). Inventory adjustments are created in RMS or imported from an external system (store or warehouse application). RMS supports two types of inventory adjustments; stock on hand or unavailable inventory. Inventory adjustments can also be created by locations for multiple items, by item for multiple locations, or through a product transformation for a specific location.
Purchase order receipts (Shipments) record the increment to on-hand when goods are received from a supplier. Weighted average cost (WAC) is recalculated at time of receipt using the PO landed cost. Transaction audit records are created for financial audit, and the receiver is made available for invoice matching.
Stock counts are the processes by which inventory is counted in the store and compared against the system inventory level for discrepancies. RMS supports two types of stock counts:
Unit stock counts
These adjust the on hand quantities for the item-locations affected and create an inventory adjustment transaction for the stock ledger.
Unit and value stock counts
These adjust the on hand quantities for the item-locations affected and adjust the stock ledger to the results of the stock count.
Automated replenishment constantly monitors inventory conditions. Based on inventory conditions, purchase orders or transfers are created to fulfill consumer demand.
Automated replenishment parameters are set up at the supplier, supplier/department, and supplier/location or supplier/department/location level. These parameters include:
Review cycle and order control
Due order processing
Investment buy attributes
Scaling constraints
Rounding attributes
Supplier minimums
Truck splitting constraints
Items can be set up for automated replenishment through the Item Maintenance dialog, either individually or through item lists.
Automated replenishment also supports different methods to determining whether purchase orders are created and quantities ordered. These replenishment methods are applied at the item/location.
Constant is a stock-oriented method in which the item is replenished when the inventory level falls below a specified level.
Min/Max is a stock-oriented method in which the item is replenished up to the maximum when the inventory level falls below a specified minimum stock level.
Floating Point is a stock-oriented method in which the item is replenished when the inventory level falls below a dynamic system-calculated maximum stock level.
Time Supply is a stock-oriented method in which replenishment is based on the number of days of supply for the item a retailer wants in inventory. The Time Supply method requires a forecasting system.
Time Supply Seasonal is the same as Time Supply, but it takes seasonality and terminal stock into account. The Time Supply Seasonal method requires a forecasting system.
Time Supply Issues is used only by warehouses, this is the same as Time Supply, but it uses warehouse issues forecast rather than store sales forecast. The Time Supply Issues method requires a forecasting system.
Dynamic is a method that controls inventory using dynamic calculations of order point and order quantities based on a number of factors, including forecast sales over order lead time, review lead time, inventory selling days, lost sales factor, and safety stock. The Dynamic method requires a forecasting system.
Dynamic Seasonal is the same as Dynamic, but it takes seasonality and terminal stock into account. The Dynamic Seasonal method requires a forecasting system.
Dynamic Issues is used by warehouses only, this is the same as Dynamic, but it uses warehouse issues forecast rather than store sales forecast. The Dynamic Issues method requires a forecasting system.
Store Orders is a method that allows replenishment to look at the store order need quantity when determining the recommended order quantity.
The Franchise Management allows the retailer to manage their franchise business in the following scenarios:
Retailer owns and manages the inventory for a franchise location.
In this case, the franchise customer (location) needs to be set up as stockholding stores in RMS, with a store type as Franchise. A stockholding franchise store functions similar to a company store with locations of inventory transactions such as Replenishment, Allocation, Stock Counts and Inventory Adjustments being allowed for such stores in RMS and the pricing being carried out in RPM. The main differences in these stores are, the way in which the orders are captured and accounted financially.
Retailer does not own or manage inventory for a franchise location.
Here the retailer does not manage the inventory for a franchise location or wherein the wholesale operations constitute a small fraction of the retailers business and thus does not warrant a separate Order Management System.
In both these scenarios, non-stockholding stores must be setup in RMS to represent these franchise (or wholesale) customers.
Franchise pricing determines the price that is charged on a franchise partners for an item. Pricing for these stores is maintained in the future cost table. The pricing for franchise locations are determined by setting up cost templates in RMS and associating these templates with an item or a franchise location. Franchise pricing includes any landed costs and applicable deals through deal pass-through to the final pricing.
The user has an option to override the future cost franchise price and instead define a fixed price to be charged for an item for manually or through the batch upload orders.
Franchise store can source the merchandise from company locations (Warehouse or Store) or from a supplier. The franchise order can be initiated manually using the franchise order form or by an batch upload process using flat file received from an external application. The franchise order created using the flat file also creates a purchase order for supplier sourced and transfers for company location sourced orders.
In addition, franchise order gets initiated in response to any inventory transaction process where the receiving location is a franchise store and the sending location is a company location or supplier. Some of these inventory transactions are Replenishment Requests, Allocation, Store Orders, Items requests; AIP generated Purchase Orders or Transfers, and externally generated transfers.
Franchise stores returns the items back to the company location (warehouse or store). Item return from a franchise store directly to the supplier is not allowed. The franchise returns can either be a physical return to the company location or can be a book return. Book Return is possible when the item is destroyed at the site, in such scenario the inventory is not physically returned but can be financially accounted.
The franchise return can be initiated manually using the franchise return form or by batch upload process using flat file received from an external application. Franchise returns results in creating a transfer to track the inventory movement.
In addition, franchise returns gets created in response to any inventory transaction where the sending location is a franchise store and receiving location is a company location. Some of these processes are AIP or externally generated transfers.
The stock ledger in RMS records the financial results of the merchandising processes such as buying, selling, price changes, and transfers. All of these transactions are recorded in the RMS stock ledger and rolled up to the subclass/location level for days, weeks, and months, depending on calendar settings. The aggregate levels in the stock ledger are used to measure inventory amounts and merchandise profitability. The stock ledger is mainly used for reporting purposes; however, there is some online visibility as well.
The stock ledger supports multiple currencies. All transaction-level information is stored in the local currency of the store or warehouse where the transaction occurred. As transaction-level information is rolled up to the aggregated levels in the stock ledger, records are kept in local currency and converted to primary currency. This allows corporate reporting to be performed in the primary currency of the company, while still providing visibility by location to the profitability in the local currency.
The stock ledger supports both the retail and cost methods of accounting. The cost method can use standard cost or average cost, depending on how the system is configured. The stock ledger supports both the retail (4-5-4) and the normal (Gregorian) calendar. If the retail calendar is used, data is maintained by the 4-5-4 month and the week. If the normal calendar is used, data is maintained only by the Gregorian month. Data can also be maintained daily using the retail (4-5-4) or normal (Gregorian) calendar.
RMS supports multiple sets of books. Clients that use multiple sets of books assign RMS locations to a particular set of books defined in an external financial system. Changes to the stock ledger affect the set of books with which a particular transaction is associated.
Investment buy facilitates the process of purchasing inventory in excess of the replenishment recommendation in order to take advantage of a supplier deal or to leverage inventory against a cost increase. The inventory is stored at the warehouse or in outside storage to be used for future issues to the stores. The recommended quantity to investment buy, that is, to order, is calculated based on the following:
Amount of the deal or cost increase
Upcoming deals for the product
Cost of money
Cost of storage
Forecasted demand for the product, using warehouse issue values calculated by Oracle Retail Demand Forecasting
Target return on investment (ROI)
The rationale is to purchase as much product as profitable at the lower cost and to retain this profit rather than passing the discount on to customers and stores. The determination of how much product is profitable to purchase is based on the cost savings of the product versus the costs to purchase, store and handle the additional inventory.
Investment buy eligibility and order control are set at one of these four levels:
Supplier
Supplier-department
Supplier-location (warehouse locations only)
Supplier-department-location
Warehouses must be enabled for both replenishment and investment buy on RMS WH (warehouse) table.
The investment buy opportunity calculation takes place nightly during the batch run, after the replenishment need determination, but before the replenishment order build. The investment buy module IBCALC.PC attempts to purchase additional inventory beyond the replenishment recommendation in order to achieve future cost savings. Two distinct events provide the incentive to purchase investment buy quantities:
A current supplier deal ends within the look-ahead period.
A future cost increase becomes active within the look-ahead period.
The calculation determines the future cost for a given item-supplier-country-location for physical warehouse locations only.
If the order control for a particular line item is buyer worksheet, it might be modified in the buyer worksheet dialog, and can be added to either new or existing purchase orders.
RMS provides essential information to all of the Oracle Retail Merchandising Operations Management applications (ReSA, RTM, RPM, ReIM, Allocation), and interacts with all of them. RMS exists on the same database schema as all of the other applications, which provides flexibility in how information is shared between RMS and the other Oracle Retail Merchandising Operations applications.
Information is shared with other Oracle Retail Merchandising Operations Management applications through direct reads from Oracle Retail Merchandising Operations Management application tables, calls to Oracle Retail Merchandising Operations Management application packages, batch processes, and the Oracle Retail Integration Bus (RIB) if the client is using this option.
The following diagram illustrates the RMS location in the merchandising footprint.
Oracle Retail Trade Management (RTM) and RMS share the same database instance. When RTM is enabled in an RMS instance, certain import-specific data maintenance is required for country, supplier, partners and items. These are directly updated into the RMS database and subsequently used in RTM.
Oracle Retail Sales Audit (ReSA) and RMS share the same database. ReSA shares some of its master data with RMS. Foundation data such as stores a company/location close dates, location traits, bank setup and tender types are maintained in RMS and used in ReSA.
Current reference data is retrieved from RMS into ReSA by the batch program SAGETREF. The data is extracted into multiple data files. The data in the files is used by the batch program SAIMPTLOG as reference data for doing validation checks on the POS/OMS transaction data during the data upload to ReSA. Having the reference in data file formats increases the performance of the SAIMPTLOG process. SAGETREF generates the following reference files:
Items
Wastage
Sub-transaction level items
Primary variant relationships
Variable weight PLU
Store business day Code types
Error codes
Store POS
Tender type
Merchant code types
Partner vendors
Supplier vendors
Employee IDs
Banner IDs
Along with the reference files, the following files are generated:
Promotions File - This file contains RPM promotions.
Currency File - This file contains valid currency codes in RMS.
Warehouse File - This file contains valid physical warehouses from RMS.
Inventory Status File - This file contains valid inventory status values from RMS.
All clean and audited sales and returns data is extracted from ReSA into a POSU file by the batch program SAEXPRMS. All sale and return transactions that do not have RMS errors are extracted into the file. The sales audit system options parameter work unit controls the export of data into files in case of the presence of RMS errors in the POS/OMS transaction data. The shell scripts UPLOADSALES.KSH and SALESPROCESS.KSH will load the data from the POSU file into the RMS tables.
RPM exists on the same database schema as RMS which allows information to be shared between applications through direct database reads, package calls, and batch processes. RPM uses APIs to facilitate the exchange of information with RMS.
RPM provides the following to RMS:
Regular Price Event Approval/Modification/Deletion-Regular price event creation, modification, or deletion triggers a call to an RMS API to generate (or remove if deleting) the ticket request information.
Price Event Execution- For regular, promotional, or clearance price events that end or are set to go into effect, the PriceEventExecutionBatch owns the process. When the pricing event has been processed by the batch program it updates item/location pricing in RMS by interfacing with the RMSSUB_PRICECHANGE API in RMS.
Initial Pricing-Initial pricing for items in RMS is dependent upon the primary zone group for the item defined in RPM and characteristics of that zone group. These characteristics include markup percent, markup percent type, and pricing guides. RPM provides this information to RMS through an API (MERCH_RETAIL_API_SQL).
Deal Creation- For Price Changes and Clearances, RPM creates new details under existing deals. Promotions can create new deals in addition to creating details under existing deals. When this occurs RPM uses an RMS API (PM_DEALS_API_SQL) to create the deal in RMS.
RMS provides the following to RPM:
Foundation Data is essential to RPM functionality. To successfully set up price changes RPM requires RMS merchandise hierarchy, organizational hierarchy, and suppliers. RPM is able to access this information through the RMS database.
Item-Price changes created in RPM ultimately relate to an item/location within RMS. RPM must know all eligible items currently in the merchandising system, the locations at which they are eligible (item/location relationships) in any status and the suppliers associated with the items. RPM can access this information through the RMS database.
Competitive Pricing Information-RPM has the ability to create price changes based off competitive activity in the marketplace. RPM is able to access this information through the RMS database.
Deals can be associated with price changes in RPM (including vendor funded promotions). In order to associate a price change to an existing deal RPM needs visibility to the deals currently available in the RMS system. RPM is able to access this information through the RMS database.
Event Notification -To ensure appropriate processing, RPM must be notified of certain events:
Store/Warehouse Creation-A zone structure must be added to RPM when new stores and warehouses are created in RMS. To do this RMS provides RPM with the store and/or virtual warehouse being added, its pricing location, and its currency (to ensure it is the same as the zone it is being added to). A store/virtual warehouse creation event in RMS triggers an API call to RPM to perform the necessary processing.
Item/Location Creation-When new item/location relationships are established, RPM must verify that no future retail records currently exist, create an initial future retail record (for sellable items), and determine if there are existing price changes that would affect the item resulting in a future retail record for the price change as well. An item/location creation event in RMS triggers data to be staged in RPM so that it is picked up for the batch processing.
Item Modification is used to notify RPM when an item is reclassified. The details of the reclassification are written to an item modification table in RPM for the next batch processing run. An item modification creation event in RMS triggers an API call to RPM to perform the necessary processing.
Department Creation is used to notify RPM when new departments are created in RMS. RPM creates aggregation-level information for the new department using predefined system defaults. A department creation event in RMS triggers an API call to RPM to perform the necessary processing.
RMS provides the following to Allocation:
Foundation Data is essential to all areas of Allocation including valid locations to allocate to and from, location groupings, and valid merchandise hierarchies to allocate within.
Item-Allocations are generated at the item location level so it is necessary that the Allocation application understand what items and item/locations are eligible in the system.
Purchase Order-One of the sources from which a user can allocate. Allocation relies on RMS to provide Purchase Order information.
Transfer-One of the sources from which a user can allocate. Allocation relies on RMS to provide Transfer information.
Bill Of Lading (BOL)-One of the sources from which a user can allocate. Allocation relies on RMS to provide BOL information.
Advance Shipment Notices (ASN)-One of the sources from which a user can allocate. Allocation relies on RMS to provide ASN information.
Inventory-In order to determine the correct need at an item location level before performing an allocation the application needs visibility to the current on hand inventory at each location being allocated to. Allocation relies on RMS to provide inventory information at the item/location level.
Sales Information-Allocation can use historical sales, forecast sales, and plan sales in order to determine the need at an item/location level for an allocation. Allocation interfaces this information in from external planning system to an Allocation table.
Allocation provides the following to RMS/RTM/ReSA:
Allocations- When the allocations is moved to Approved or Reserved status, the Allocation is written to RMS tables to give visibility to the allocation results.
Purchase Orders created by What-If process in Allocation-If this option is enabled in Allocation the client can create a simulated allocation based on current need and then automatically create a purchase order from that Allocation in RMS to fulfill that need. Allocation uses an RMS API to build the purchase order in RMS.
RMS provides the following to Invoice Matching:
Foundation Data is essential to all parts of invoice matching including valid locations for Invoices to be implemented at, valid suppliers to receive invoices from, and supplier addresses to send credits and debits based on invoice matching results.
Item is essential to the invoice matching process as item information ensures that invoices being received are valid for the business. For example an item received on an invoice is carried by the client, is supplied by the supplier who sent the invoice, and is carried in the locations for which the item was received.
Purchase Orders are used by Invoice Matching to facilitate the invoice matching process which is performed at the purchase order location level.
Shipments-Shipment information is used by Invoice Matching to determine if a PO has been received yet which affects the matching algorithm used by the AutoMatch batch program in Invoice Matching.
Deals and Rebate-Invoice Matching creates credit memos, debit memos, and credit requests based on deal and rebate information in RMS for processing by the financial (AP) system. This is performed by the ComplexDealUpload and FixedDealUpload batch processes that read from RMS staging tables.
Invoice Matching provides the following to RMS:
Invoice Matching results for shipments-Shipment records are updated with the invoice matching results from the invoice match process (this involves updating the match status and quantity matched of the shipments in question). The matching process is handled by the AutoMatch batch process in Invoice Match which attempts to match all invoices in ready-to-match, unresolved, or multi-unresolved status.
Receiver Cost Adjustments-An API is executed when invoice matching discrepancies are resolved through a receiver cost adjustment. The API updates the purchase order, shipment, and potentially the item cost in RMS, depending on the reason code action used.
Receiver Unit Adjustments-An API is executed when invoice matching discrepancies are resolved through a Receiver Unit Adjustment. The API updates the purchase order and shipment in RMS to complete the transaction.
Closing unmatched shipments-Invoice matching closes the invoice matching status for shipments in RMS after a set period of time (defined by the client in system options). This updates the invoice matching status of the shipment on the shipment table in RMS. This process is managed by the ReceiptWriteOff batch program.