| Oracle® Retail Merchandising Implementation Guide Release 14.1 E56350-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 user groups capable of efficient and effective disposition.
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.
Debit reversals allow the user to efficiently convert a supplier-disputed debit memo into an editable credit memo with supplier comments for resolution, allowing for flexible handling through the routing process or central processing.
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 are set at supplier, merchandise department, and system levels.
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.
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.
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.
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 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.
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. |
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 gets invoices from external suppliers in one of two ways: EDI or hardcopy. When EDI is used, the EdiUpload 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.
Users in Invoice Matching can be set up either using LDAP or the database through the IM_USER_AUTHORIZATION table. If clients have existing applications that use LDAP, Invoice Matching can be configured to point toward the clients' LDAP server to prevent the creation of multiple user IDs for the same user. Clients need to determine which method works best for them during implementation.
Users logging in to Invoice Matching are validated against LDAP or the database to authenticate the user prior to beginning an application session. A system administrator is responsible for setting up new users in the system (LDAP or the database).
When a user is authenticated, Invoice Matching provides a two-tier security structure to limit the functions and information that they are authorized to use.
This provides a way for clients to limit the functionality that users have access to in the Invoice Matching application. Invoice Matching provides clients with the ability to grant users with one of three levels of access to various functionalities:
Edit provides a user group with total access to the functionality in question.
View provides a user group with the ability to access a functional area. However, the user group is not able to interact with information in the functional area (only view it).
No Access prevents a user group from accessing the functional area in question.
Application Level Security for Invoice Matching is maintained on the IM_BUSINESS_ROLES table and is associated to users through the IM_BUSINESS_ROLE_MEMBER table.
This level provides a way for clients to limit the information that users have access to in the Invoice Matching application. Invoice Matching allows clients to limit user access for three types of information:
Dept/Class limits a user group to performing Discrepancy Resolution functions for specific department/classes. This information is maintained on the IM_BUSINESS_ROLES_DEPT table.
Location limits a user group to performing Discrepancy Resolution functions for specific locations. This information is maintained on the IM_BUSINESS_ROLES_LOC.
Reason Codes limits a user group to specific reason codes that they are allowed to use. This information is maintained on the IM_BUSINESS_ROLES_REASON_CODES table.
To implement the security structure offered by Invoice Matching, the concept of business roles is used. Business roles are unique to each client and need to be defined during the implementation effort. Business roles should accurately represent the different types of users that access the Invoice Matching application and the types of functions and information that those roles need to access.
The Invoice Matching application allows a client to set up these business roles through the application by using the User Group dialog. The Invoice Matching application also allows a client to associate users to a respective business role (User Group) through the User Group dialog. This results in the user inheriting the security characteristics of that user group. It is important to note that the relationship between a user and a user group is one-to-one.
