| Oracle® Retail Invoice Matching Cloud Service Oracle® Retail Invoice Matching Cloud Service Implementation Guide Release 19.3.000 F44371-03 |
|
 Previous |
 Next |
| Oracle® Retail Invoice Matching Cloud Service Oracle® Retail Invoice Matching Cloud Service Implementation Guide Release 19.3.000 F44371-03 |
|
Previous |
Next |
The batch auto-match program performs several types of match attempts in an effort to match invoices to receipts. The Match Strategy rules feature allows retailers to build and maintain match strategies which specifically define the types of matches which should be attempted and the order in which they should be tried during the auto-match process. The match strategies can be defined at the system, supplier group, or supplier level.
The mapping of a Match Strategy to a Supplier or Supplier Group is done in the Supplier Options UI. The Match Strategy is a field on the Supplier Options table, available for either suppliers or supplier groups. If it is populated, then the supplier or supplier group is mapped to that strategy. If the supplier is not mapped at one of these levels, then the match strategy default is used for that supplier
Tolerance settings in Invoice Matching are independent entities with an ID and a description and the definition of the various cost and quantity tolerance levels that are established for for matching invoices to Purchase orders and Receipts. Each tolerance can have many tolerance levels both for unit costs and for quantities at summary, detail or parent item level, in favor of the retailer or in favor of the supplier. Within detail level tolerances, a resolution action can be defined to automatically resolve any detail level discrepancies that are found. These Tolerance entities are mapped to supplier sites, suppliers, supplier groups, or departments. One of the tolerance entities is also defined as the system default. The match engine looks at the documents in the match and determines the appropriate level to search for a tolerance to be applied.
Tolerance Mapping Maintenance allows users to create a mapping between a supplier sites, suppliers, supplier groups, or departments entity with a Tolerance ID. For example, it allows a tolerance ID to be mapped to a particular supplier. The auto and manual matching processes would then use that Tolerance to determine matches between Invoices and receipts.
Supplier options control certain functions in Invoice Matching that may need to vary between Suppliers, Supplier Sites and across Groups of Suppliers. All suppliers must have various options defined in order for their invoices to be processed by the system. The Invoice Matching processes require that a supplier must exist in RMS before supplier options can be established in Invoice Matching.
Supplier Options can be set at three different levels, Suppliers Sites, Suppliers and Supplier Groups with specific options at each level having some differences. When there are similar settings across levels, the general rule is that if a specific option can be set at a lower level, then that lower level setting will apply however there are exceptions to the rule. This document does not describe all of the options and will only touch on a few of the key options and differences.
The options that can be set at the Supplier Group level are primarily tied to the matching process as the Supplier Group exists only for the purpose of matching documents across suppliers that are part of the group. There are a number of options that can be set at this level but the primary options that can be set at the Supplier Group level are the Match Strategy that will be used for all Suppliers in the Group and the Match Key that will be used.
Supplier Level options are required for all Suppliers in Invoice Matching. At the Supplier Level many of the same options exist that are used at the Supplier Group as well as a number of other options that both the Supplier and Supplier Site have. Supplier Level options will in general be applied to all Supplier Sites that belong to a Supplier, unless Supplier Site level options have also been set up. At the Supplier Level you can optionally assign the Supplier to a Supplier Group. Similar to Supplier Groups, a Supplier can also have a Match Strategy and Match Key assigned.
Beyond these options that are also part of the Supplier Group settings, the Supplier Options includes a few other optional flags and parameters that may be more specific to a supplier such as how chargebacks are managed, the correct use of terms on matching processes and whether a suppliers invoices are typically paid by an outside process.
Supplier Site level options are entirely optional in Invoice Matching and are used when specific supplier sites for a supplier operate differently than the parent supplier and therefore require the system to treat them differently. Supplier Site level options when set, will override the same settings that would normally default from the parent supplier.
Reason codes are used to resolve discrepancies between receipts and invoices. A discrepancy originates when the price or quantity variance exceeds acceptable tolerance levels. Using the Reason Code Maintenance window, you can set up and maintain reason codes. Reason codes are used to resolve discrepancies between receipts and invoices. A discrepancy originates when the price or quantity variance exceeds acceptable tolerance levels. After you create the reason code, you must associate it with a reason code action that helps you resolve the discrepancies. The reason code actions are a base Invoice Matching entity. These actions are described in the Invoice Matching Foundation Entities section of this document.
Once Invoices are matched, they are sent to the financial system for payment in accounts payable and recording in the general ledger. In order to properly communicate the Invoices with the AP and GL systems, configuration is required to translate the Invoice Matching data to data required by the financial system. There are two main areas of configuration for this; General Ledger Options and General Ledger Cross Reference.
The GL Option Maintenance in Invoice Matching allows the retailer to configure Information about how Invoice Matching transactions will be mapped to the general ledger. This feature allows the retailer to specify the structure of the GL chart of accounts for the Invoice Matching mapping including how may segments are used, the labels for the segments and whether any segments will use dynamic mapping based on Merchandising Locations or Merchandise Hierarchy. Setup of actual Dynamic mapping is also done through the General Ledger options configuration.
The GL Cross Reference Maintenance screen allows users to build and maintain the cross reference between Invoice Matching transactions and the accounting segment values necessary to interface transactions to external AP and GL financial systems.
The majority of the foundational data that is used by Invoice Matching is supplied by direct integration with Merchandising. In addition to the items, locations, Suppliers and Partners used by Invoice Matching, the following information is also used:
Languages and data translations
Currencies and exchange rates
Currency and quantity precisions
Units of measure (UOMs)
Tax Codes and Rates
Non Merchandise Codes
For details on configuring currencies, languages and translations, currency and quantity precisions, UOMs, and VAT information, see the Oracle Retail Merchandising Implementation Guide.
Invoice Matching supports the ability to upload documents using spreadsheets. These spreadsheets are all managed using a template that allows you to configure different versions of the template based on how you want to create the document. Configurations include displaying or hiding certain columns, defining default values, and changing the worksheet and column labels.
For example, you could have one template that is used for uploading merchandise invoices, and another that is used for uploading Credit Notes. For uploading merchandise invoices, you may have one template which is used for entering invoices with items, and another template which is used for header only documents. For one template, you may want to include the total quantity column as part of the document, for another template you may want to hide the total quantity column.
As a starting point for all template configuration, it is recommended that you take the base template for each document and create one or more copies to apply your configuration, instead of using the base template. This will help to insulate your configurations from any future changes to the base template when Invoice Matching is patched, such as if new columns are added as part of a product enhancement.
All template configuration for Invoice Matching is done in the Merchandising screens. For more details on this configuration, see the Oracle Retail Merchandising Foundation Cloud Service Implementation Guide.
Invoice Matching supports operating the user interface in 19 languages, including English. As part of the install options for Merchandising, you'll designate one language as "primary", which also applies for Invoice Matching. This primary language is what is loaded as a default for all screen labels and error messages in Invoice Matching at the time of installation. By default, only the primary language you indicated at installation is loaded in Invoice Matching, but if you wish to have more languages loaded, then you can request to have the language strings loaded for these languages as well.
Arabic
Chinese (simplified)
Chinese (traditional)
Croatian
Dutch
French
German
Greek
Hungarian
Italian
Japanese
Korean
Polish
Portuguese
Russian
Spanish
Swedish
Turkish
This means that all screen labels, error messages, and menu options are supported out of the box in these languages and users are able to select from these languages as their preferred language. Data translation is also supported to allow data that you create as part of your implementation, such as tender types, can be seen in the preferred languages of your users as well.
|
Note: Data translation is not supported for any Invoice Matching owned entities. |
If you would like to modify the translations for labels and error messages, or add translations for other languagesFoot 1 that are not included in the list above, there are several methods provided. The method used will depend on the data that needs to be updated/added. Translatable text is held in two different ways:
Resource bundles, which contain most of the screen labels, menus, and messages
Database tables, which contain strings used in drop-downs, and some labels
Screen labels and other UI related data that may require updates/additions for Invoice Matching are managed in resource bundles. For details on how to make updates to resource bundles see the Resource Bundles section in the Oracle Retail Merchandising Customization and Extension Guide.
Users can choose their preferred language to have the user interface displayed as part of setting up their user preferences. As noted above, the values loaded in the base table of an entity are always maintained in the primary language. And as such all users, irrespective of their configured language, will see the primary language in the screens where an entity is created and maintained, and translations (including their preferred language) are shown in separate translation screens. However, if that same screen is accessed in view mode the description will be shown in their preferred language. Similarly, if viewing the entity in another UI - for example, viewing the item description in the purchase order details screen - the description will be shown in their preferred language.
Footnote Legend
Footnote 1: Additional support is also available for the following languages by adding your own translations using the tools described in this section for adding your own translations: Czech, Danish, Finnish, Hebrew, Norwegian, Thai, Albanian, Latin Bosnian, Bulgarian, Estonian, Latvian, Cyrillic Serbian, Lithuanian, Slovakian and Slovenian.