| Oracle® Retail Merchandising Implementation Guide Release 15.0 E65391-01 |
|
 Previous |
 Next |
This chapter is an overview of Oracle Retail Invoice Matching (ReIM).
The following information is maintained in the ReIM application.
Multi-dimensional matching utilizes complex matching logic designed to maximize match rates and processing productivity for both invoice and credit note matching.
Discrepancy routing identifies cost and quantity discrepancies when a match has not occurred after a user-specified period of time and automatically routes discrepancies to the Discrepancy Review List.
Resolution dialog offers a powerful, streamlined approach to handling invoice discrepancies where reviewers can disposition a discrepancy based on a set of user-defined reason codes.
Self-billing and deals bill-back integration provides robust integration with the Oracle Retail Merchandising System that supports supplier billing for RTVs, rebates and other deals, consignments, direct store delivery, evaluated receipts, and other non-merchandise billings from obligations and customs entry.
Receiver adjustments integration provides direct updates of receiver cost and quantity adjustments initiated from the matching/resolution process to inventory valuation and positions in the RMS.
Best terms date uses payment terms rankings (predetermined by the user) to identify the invoice or purchase order term best supporting the retailer's cash management objectives. Payment terms and terms date information is exported to the retailer's accounts payable solution to support payment of the invoice, as well as processing of other documents..
Debit reversals allow the user to efficiently convert a supplier-disputed debit memo into an editable credit memo with supplier comments for resolution.
Matching tolerances offers the flexibility to set up tolerances by monetary range, nominal amount, or percent. Separate tolerances can be applied for quantity and cost and for discrepancies in either the retailer's or its supplier's favor. Tolerances created as individual entities and can be mapped to supplier site, supplier, supplier group, or department. One tolerance entity can be designated as the system default.
The Invoice Matching application's primary purpose is to match invoices so they can be exported to Accounts Payable (AP) to be paid. Invoice Matching has limited interaction with the Oracle Retail Merchandising Operations Management applications with the exception of RMS. RMS is the owner of the information that Invoice Matching needs to match invoices it receives.
Information from the Invoice Matching application is shared with 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, Invoice Matching packages based on Oracle Retail Merchandising Operations Management application tables, and batch processes.
For more information on the Merchandising Architecture, see Retail Reference Architecture artifacts on My Oracle Support.
RMS provides the following to Invoice Matching:
Foundation Data is essential to all parts of invoice matching, including valid locations for invoices to be executed, valid suppliers from which to receive invoices, supplier addresses to send credits and debits based on invoice matching results, and more.
Item information 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 information is used by Invoice Matching to determine if a PO has been received, which affects the matching algorithm used by the AutoMatch batch program in Invoice Match, as well as online matching process.
Deals and Rebate-Invoice Matching creates credit memos, debit memos, and credit note 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.
Staged Accounts Payable transactions-Accounts Payable documents created in RMS for consignment invoices, Obligations invoices, customer entries invoices, payment transactions sent through ReSA, and Return to Vendor chargebacks (either debit memos or credit note requests) are staged to Invoice Matching staging tables in RMS and extracted using the batch EDIDLINV to be loaded as EDI documents into Invoice Matching.
Invoice Matching provides the following to RMS/RTM/ReSA:
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 Matching, which attempts to match all invoices in ready-to-match, unresolved, or multi-unresolved status, as well as online matching process.
Receiver Cost Adjustments-An API 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 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.
RTM provides to Invoice Matching:
Finalized Customs Entry-When Customs Entries are confirmed in RTM, a non-merchandise invoice is automatically created in Invoice Matching staging tables.
Approved Obligations-when an Obligation is approved in RTM, a non-merchandise invoice is automatically created in Invoice Matching staging tables.
|
Note: Invoice Matching provides no information to RTM.RTM data, as well as any other data staged for ReIM in RMS would need to be extracted from RMS using EDIDLINV RMS process to generate EDI files and loaded into ReIM using EDIInjector from EDI files. |
ReSA provides the following to Invoice Matching:
Store Level Purchasing-Payments for merchandise purchases done at store level are booked against a corresponding merchandise invoice. Payments of non-merchandise purchases or miscellaneous services availed at the store are booked against a corresponding non-merchandise invoice. These transactions are passed from the POS/OMS to ReSA as specially designated PAID OUT transactions. All these invoices are assumed paid. The batch program SAEXPIM transfers the specially-designated PAID OUT type of transactions to the Invoice Matching staging tables for extract to the Invoice Matching application.
Escheatment Processing - Unclaimed monies of outstanding, non-expiring vouchers are totaled after a defined period from the date of issuance of the voucher and posted to Invoice Matching staging tables as a non-merchandise invoice by SAEXPIM. The unclaimed amount is paid out as income to the issuing retailer or, in some U.S. states; it is paid out to the state. ReSA determines who receives this income and accordingly posts a non-merchandise invoice for the partner. These invoices are assumed not paid.
|
Note: Invoice Matching provides no information to ReSA. |
ARI is a monitoring system that interacts with any applications database (including Invoice Matching). As such, it does not use any information from Invoice Matching; rather it monitors the Invoice Matching database for events defined by a client and notifies the client when said events occur.
Invoice Matching exports data to financial staging tables through the FinancialPosting batch program. However, clients using any other system for financials must create their own interface to deliver information to that system. Invoice matching validates accounts against the financial system.
Valid accounts can be pre-loaded into Invoice matching to improve performance of the posting process.
Payment terms and currencies need to accurately synced between the financial system and RMS.
Invoice Matching allows drilling forward to see the interfaced document in PeopleSoft application.
|
Note: Invoice Matching does not provide drillback functionality from PeopleSoft. |
Invoice Matching gets invoices from external suppliers in one of two ways: EDI or hardcopy. When EDI is used, the EdiInjector batch program is responsible for uploading the invoice details from the vendor using a standardized file format. When a hardcopy is used, the client needs to manually enter the invoice in the system before matching can proceed.
Notification to suppliers of charge backs and requests for credit notes is provided in a flat file extracted by EdiDownload batch process.
