4 Match Credit Notes to Credit Note Requests

Manual Match Credit Notes to Credit Note Requests

The manual matching of credit notes to credit note requests mirrors the manual matching of invoices to receipts. Therefore, the credit note matching feature includes the ability to Summary Match credit notes to credit note requests, as well as the ability to detail match a credit note to one or more credit note requests.

Credit note requests documents are of three types; CNR-Cost, CNR-Quantity, and CNR-Tax. A CNR-Cost and CNR-Quantity document could be pulled into the same match pool and matched to one or more credit note(s). (CN's do not have a separate type for cost or quantity, there is just a CN document which could include cost, quantity, or both.) A CNR-Tax is the reversal of an invoice which was determined to have the wrong tax applied. It is likely to be matched separately from other types of CNR's, it should be able to be matched like any other CNR document.

Search for Credit Note Requests and Credit Notes to Match

Navigate: From the Tasks menu, select Credit Note Matching > Summary Match. The Credit Note Summary Match window opens.

Figure 4-1 Credit Note Summary Match Window

Enter criteria as desired to make the search more restrictive. You must enter at least one search criterion.
Click Search. The search results pane displays the credit note requests and credit notes for each supplier that match the search criteria.

Figure 4-2 Credit Note Summary Search Results

The Credit Note Summary Match screen allows for the manual matching of Credit Notes which were not matched by the Credit Note auto-match batch program. The screen shows Credit Notes (CN) and Credit Note Requests (CNR) which meet your specified search criteria and allows you to select any combination of Credit Notes and Credit Note Receipts to attempt to bring the documents within a match tolerance. If matching at the summary level is not possible (or not desirable), the screen allows you to navigate to a detail match screen where matching is performed against the items on the Credit Notes and Credit Note Requests.

Summary Match Credit Notes

The summary matching windows allow you to match credit notes and credit note requests. By limiting the credit note request and credit note criteria on the Summary Match Find window, you can view credit note requests and credit notes with similarities.

Suggested Match

Suggested Match is used to suggest which CNRs might be a good match for the CN or CNs that are selected.

Navigate: From the Tasks menu, select Credit Note Matching > Summary Match. The Credit Note Summary Match window opens.

Perform a search for credit note requests and credit notes. See Search for Credit Note Requests and Credit Notes to Match for additional details.
In the search results, select all CNs and CNRs from your search results and click Summary Match. The Credit Note Summary Match screen is displayed.

Figure 4-3 Select CNs for Suggested Match
Select one or more CNs and verify that all CNRs are unselected. Click Suggested Match.

The system evaluates various combinations of the CNRs to determine what is the best match for the selected CNs. The combination of CNRs which are considered the best match for the selected CNs are flagged as selected and the Summary Match table is updated to reflect the selected CNRs.

Note:
The suggested match returns the best match it finds even if that match is outside of tolerance.
If the suggested match is within tolerance, click Match to match the CNs to the CNRs. If the suggested match is out of tolerance you can elect to make adjustments as necessary.

Adding Documents to Summary Match

Navigate: From the Tasks menu, select Credit Note Matching > Summary Match. The Credit Note Summary Match window opens.

Perform a search for credit note requests and credit notes. See Search for Credit Note Requests and Credit Notes to Match for additional details.
In the search results, select the CNs and CNRs you want to match from your search results and click Summary Match. The Credit Note Summary Match screen is displayed.

Figure 4-4 Credit Note Summary Match Screen
Determine whether a CN or a CNR are needed to reach tolerance. From the Action menu of the CN or CNR list, select Add. The Find Credit Notes and Credit Note Requests dialog is displayed.

Figure 4-5 Find Credit Notes and Credit Note Requests Dialog
Enter your search criteria and click Search. A list of CNs and CNRs is displayed based on your search criteria.
Check the CN or CNR that you want to add to the summary match and click OK. You are returned to the Credit Note Summary Match screen and the selected CN or CNR is added to the respective list.

Detail Match Credit Notes

Detail Match enables the user to match the items on a CN to the items on a CNR.

When navigating to the Detail Match screen CNs and CNRs are grouped by item. All the items are in an unmatched status. Items which are within tolerance are flagged as selected.

Note:

If there are multiple CNRs and the unit cost on the CNR items is different then matching is not allowed so the item will not be selected. The same issue exists if the unit cost on an item for two CNs in the match are different. For these items, the CN and CNR amounts are included in the Detail Items Selected totals table. In addition, the Detail Match button is enabled allowing the user to complete the matching for within tolerance items.

Matching Items within Tolerance

Navigate: From the Tasks menu, select Credit Note Matching > Summary Match. The Credit Note Summary Match window opens.

Perform a search for credit note requests and credit notes. See Search for Credit Note Requests and Credit Notes to Match for additional details.
In the search results, select the CNs and CNRs you want to match from your search results and click Summary Match. The Credit Note Summary Match screen is displayed.

If the selected CNs and CNRs are within line level tolerance, click Detail Match. The selected items are flagged as cost and quantity matched and the status on the selected items is changed to matched.

Note:

The Detail Match button is enabled if the variance on each selected item is within line level tolerances. If any one of the selected items is outside of the tolerance, the detail match button is disabled. If there is a tax discrepancy on an item, the Detail Match button is also disabled.

Resolving Discrepancies

The Resolve button on the Credit Note Detail Match screen is enabled when there are one or more unmatched items selected.

Note:

If there is a tax discrepancy on an item, the Resolve button is disabled.

Clicking the Resolve button opens the Resolve dialog which allows the discrepancy resolution process to proceed on all selected items.

Resolving Tax Discrepancies

The Tax Resolution button on the Credit Note Detail Match screen is enabled if the selected item fails the tax validation check.

Note:

If an item has a tax discrepancy, the Detail Match and Resolve buttons are disabled.

This action allows user to Resolve tax discrepancies between a Credit Note and a Credit Note Request.

There are two basic types of actions; either the Credit Note is correct, or the Credit Note Request is correct. If the Credit Note Request is correct, the corrective action is to reverse either the entire Credit Note (by generating a Credit Memo), or reverse just the single item on the Credit Note (again by using a Credit Memo).

Reversing the entire Credit Note includes:

Setting the Credit Note to a matched status
Creating the Credit Memo to offset the Credit Note.
Generate a new Credit Note Request in approved status which is sent to the supplier to prompt them to send the correct Credit Note.

Reversing a single item of the Credit Note includes:

Setting the Item on the Credit Note to matched status.
If all other items on the Credit Note are also matched, set the credit note itself to matched status.
Creating the Credit Memo for the single item to offset the matched Credit Note item.
Generate a new Credit Note Request in approved status for the single item. The CNR is then sent to the supplier to prompt them to send the correct Credit Note.

If the Credit Note is determined to be correct, the Tax Discrepancy indicator on the item is turned off (for the current matching session), and the user is allowed to either match or resolve the item (which ever is applicable). If the user does not match or resolve the item in this session, the next time the Credit Note is brought into the matching dialog, the Tax Discrepancy needs to be considered again.

Auto-Match Credit Notes

Credit Note Auto-Matching pairs credit note requests to corresponding credit notes sent by the supplier. The CreditNoteAutoMatchBatch attempts auto-matching of credit notes from suppliers, to credit note requests from the retailer without manual intervention. The batch also creates and resolves detail level discrepancies utilizing a predefined set of reason codes. These reason codes are defined within Invoice Matching through the System Options Maintenance screen. In addition, the batch utilizes a variety of configurable keys to allow for document groups to be matched in ways other than just distinct purchase order and location combinations.

The following table describes under which circumstances credit notes and credit note requests are eligible to be matched by the CreditNoteAutoMatchBatch process.

Table 4-1 CreditNoteAutoMatchBatch Eligibility

Document Status	Document Hold Status	Holding Supplier	Credit Notes	Credit Note Requests
Approved	Never held	Yes	N/A	Eligible
Approved	Held	Yes	Eligible	N/A
Approved	Released	Yes	Eligible	Eligible
Approved	Never held	No	Ineligible	N/A
Posted	Never held	No	Eligible	N/A

In addition to the requirements listed above, the following criteria must apply for documents to be processed by the CreditNoteAutoMatchBatch:

Credit notes must never have had a discrepancy created against them.
Credit notes must never have been previously detail matched.

If the documents are eligible for matching, they are collected into a pool of matchable documents by the batch. The batch process is multi-threaded. It performs matching on eligible documents by first grouping the eligible documents with respect to the supplier. Once grouped with respect to the supplier, the documents are processed for each configurable key. Each document-key set is further processed using the following three matching algorithms.

Summary matching
One-to-one matching
Detail (line level) matching

In summary matching, documents are matched in groups at the summary level by comparing the total extended costs for all the documents in the group. Quantity matching is only attempted if the supplier options indicate it as required. If a match is achieved, the documents are marked with the matched status, and drop out of the matching pool.

If the summary match attempt fails for the group, the batch attempts matching at the one-to-one level. One-to-one matching attempts to match each distinct eligible credit note to a single credit note request. The match is again attempted by comparing the extended cost on the credit note to that of the credit note request, and quantity matching is only attempted depending on the supplier options. If one-to-one matches are found, they are flagged as such and will not be processed by subsequent match attempts.

Line level matching is the last attempted match algorithm. This algorithm attempts to match documents at the item line level. To avoid item matching between unrelated credit notes and credit note requests, this algorithm expects just one unmatched credit note to be remaining in the matchable pool. In case there is more than one credit note still in unmatched status, no match attempt will be made. Line level matching also automatically creates and resolves discrepancies, if the appropriate system options have been set. Once these discrepancies are created, the algorithm also attempts to resolve the discrepancies by creating resolution actions in the system in accordance with the nature of the discrepancies.

On the next run of the ReasonCodeActionRollupBatch, documents are generated for any resolution action generated by the CreditNoteAutoMatchBatch.

Configurable Keys (Flexible Pool Keys)

Grouping documents into sets using configurable (flexible) pool keys allows for matching in combinations beyond just the PO / Location combination. Note that when we refer to a document set, the set can only contain documents within the same supplier.

These document-key sets are categorized by common attributes which are defined on the document itself (credit notes and credit note requests). These attributes are referred to as Configurable or Flexible Pool Keys. By default, the credit note auto match process aggregates document sets based on the following keys:

Credit Note Request ID
Original Invoice ID
PO / Location combination

Credit Note documents include the Credit Note Request ID and Invoice Number in the Credit Note Match Key fields on the header tab. Credit Note Request documents include the Invoice Number in the Credit Note Match Key fields on the header tab (The CNR # is not needed in the Credit Note Match Key field since it is already on the document). The Credit Note Match Key fields are optional, if they are populated then documents are pooled for the key and matching is attempted within the document-key set (match pool).

A document can exists in only one document-key set at a time. Note that a document-key set will exist only if it contains both credit notes and credit note requests. Matching will be attempted only for sets not containing both credit notes and credit note requests. This makes it impossible to create, route and resolve discrepancies for credit notes that are yet to be received by the retailer.

Within each document-key set, matches are attempted using three different matching algorithms. If a match is obtained with an algorithm, the matched documents are flagged as such, and processing continues on to the next document-key set. When all configurable three algorithms are finished processing within a document-key sets, processing moves to the next configurable key-set and starts again from the first matching algorithm.

Below is the order for attempting a match in a document-key set when no match is found:

Credit Note Request ID (configurable key)
- Summary Matching (matching algorithm)
- One to One Matching (matching algorithm)
- Line -level Matching (matching algorithm)
Original Invoice ID (configurable key)
- Summary Matching (matching algorithm)
- One to One Matching (matching algorithm)
- Line -level Matching (matching algorithm)
PO / Location (configurable key)
- Summary Matching (matching algorithm)
- One to One Matching (matching algorithm)
- Line -level Matching (matching algorithm)

Summary Group Matching Algorithm

Summary matching attempts to match the total extended cost of the credit notes with the total extended cost of the credit note requests. Extended cost is defined as the unit cost for an item multiplied by the quantity of the item on the document. The total extended cost for each credit note and credit note request is taken from the document header.

Quantity matching also is sometimes required. Whether quantity matching is performed is determined by supplier options. Quantity matching compares the total quantity on the credit note, with the total quantity on the credit note request. As in cost matching, the total quantity for each credit note and credit note request is taken from the header.

If the costs and quantities do not match exactly, then the system attempts to match them within tolerance. If a match is achieved, all of the credit notes, credit note requests, and their lines for that document-key set are assumed to be matched. If a match is not achieved, all credit notes and credit note requests for that document-key set are left in their original approved status. After summary matching has been completed, the credit notes and requests become eligible to be processed with a different matching algorithm if no match was found at the summary level.

Consider an attempted summary match where two credit notes were received for two credit note requests. Assuming that the invoice and receipt data in the application is as follows:

Purchase Order=89890
Location=1000001

Table 4-2 Attempted Summary Match

Document Type	Document ID	Unit Cost	Extended Cost	Quantity
Invoice	INV555	$11.00	$440	40
Receipt	SHP444	$10.00	$300	30

When matched, the invoice and receipt will create a cost discrepancy of $40, and a quantity discrepancy of $100--which will generate a credit note request cost for $40 and a credit note request quantity for $100.

The default Invoice Matching Pool Key configuration will have the following priority and values.

Credit Note Request ID
Invoice ID
Purchase Order/Location

Example 1: Matchable by credit note request ID; quantity matching not required by supplier

The following example illustrates a successful match using the first Pool Key attribute, Credit Note Request ID.

Table 4-3 Example 1: Matchable by credit note request ID

Credit Note Request ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNRC-123	40	CRDNRC-123	INV555	40
CRDNRQ-456	100	CRDNRQ-456	INV555	10

Table 4-4 Example 1: Matchable by credit note request ID

Credit Note ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNT-246	40	CRDNRC-123	INV555	40
CRDNT-369	100	CRDNRQ-456	INV555	10

The credit note request associated with a credit note is determined from the Credit Note Request ID field that should contain the credit note request Id. In the example, the total extended cost for a credit note matches exactly with the extended cost of its respective Credit Note Request. Therefore, all credit notes and credit note requests will be set to matched status.

Example 2: Quantity matching required by supplier, outside tolerance

The following example illustrates an unsuccessful match, where quantity matching is required by the supplier, and the tolerance level is set to 10%. It is assumed that the documents are matchable by credit note request ID.

Table 4-5 Example 2: Quantity matching required by supplier, outside tolerance

Credit Note Request ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNRC-123	400	CRDNRC-123	INV555	20
CRDNRC-456	100	CRDNRQ-456	INV555	2

Table 4-6 Example 2: Quantity matching required by supplier, outside tolerance

Credit Note ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNT-246	500	CRDNRC-123	INV555	25

In the example, the match is unsuccessful, despite the fact that the extended costs do match. The failed match is due to the requirement by the supplier to match quantities, and the difference in quantities on the credit note request--and the credit note is more than the allowed tolerance of 10 percent. The credit notes and credit note requests will remain in their original status.

Example 3 (quantity matching required by supplier, within tolerance)

The following example illustrates an unsuccessful match when the pool key is the credit_note_request_ID (Credit Note Request ID), but a successful match when the pool key is Invoice_ID. In this scenario, quantity matching is required by the supplier, and tolerance level is set to 10.

Table 4-7 Example 3 quantity matching required by supplier, within tolerance

Credit Note Request ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNRC-123	400	CRDNRC-123	INV555	20
CRDNRC-456	100	CRDNRQ-456	INV555	4

Table 4-8 Example 3 quantity matching required by supplier, within tolerance

Credit Note ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNT-246	500	CRDNRC-123	INV555	25

In the example, the match is not successful when using Credit Note Request ID as the pool key, because the extended cost difference (500 - 400) is outside of tolerance.

However, if the batch process was using the Invoice ID as the pool key the match would be successful because the extended costs (400+100 = 500) match, and the quantities match within tolerance (20+4 = 24, where 24 is within 10% of 25). All the credit note requests and credit notes will be set to the status of matched. Example 4 illustrates a scenario in which Invoice ID is used as the pool key.

In case of cost discrepancies, the costs will match if the extended cost differences between the credit note request and the credit note are within tolerance.

Example 4: Matchable by invoice ID

If the credit notes and credit requests are not matchable by the credit note request ID. The matching process will attempt a one-to-one, and then a line-level match before moving to the next document key-set which is the invoice ID. The invoice ID is populated in the Invoice number field of the credit note. The following example illustrates an attempted summary match which failed when using credit note request ID, but is successful when the match is attempted using the second priority Pool Key attribute, Invoice ID.

Table 4-9 Example 4: Matchable by invoice ID

Credit Note Request ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNRC-123	20	CRDNRC-123	INV555	2
CRDNRC-456	80	CRDNRQ-456	INV555	8

Table 4-10 Example 4: Matchable by invoice ID

Credit Note ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNT-246	100		INV555	10

In the example, the Credit Note Request ID on the Credit Note is empty. Therefore, a match attempted with the Credit Note Request ID fails. Assuming that one-to-one and live-level matches also fail, a second attempt to summary match will be made in the next document-key set (using the invoice ID). In this case, because the credit note and credit note requests match by Invoice ID, all credit notes and credit note requests will be set to matched status.

Example 5: Matchable by PO Location

If a credit note and credit request is not matchable in the document-key sets utilizing credit note request ID, or invoice ID, then the match will be attempted using the PO and Location combination which is the third priority in the default Pool Key Attributes of the system.

Assuming that the invoice and receipt data in the in application is as follows:

Purchase Order=89890
Location=1000001

Table 4-11 Example 5: Matchable by PO Location

Document Type	Document ID	Unit Cost	Extended Cost	Quantity
Invoice	INV555	$11.00	$440	40
Receipt	SHP444	$10.00	$300	30

When matched, the invoice and receipt will create a cost discrepancy of $40 and a discrepancy of $100, which will generate a credit note request for $40 and a credit note request quantity for $100.

Table 4-12 Example 5: Matchable by PO Location

Credit Note Request ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNRC-123	40	CRDNRC-123	INV555	40
CRDNRC-456	100	CRDNRQ-456	INV666	10

Table 4-13 Example 5: Matchable by PO Location

Credit Note ID	Total Extended Cost	CNR ID	Invoice ID	Quantity
CRDNT-246	140			50

In the example, both the Credit Note Request ID and Invoice ID fields on the credit note are empty. Therefore matching is not even attempted at the Credit Note Request ID or invoice ID pool keys. A third attempt to match will be made with the PO and Location combination. As calculated from the above data, the PO and location combination for all three documents is: 89890-1000001. Since this combination is the same for all three documents, and the extended cost of the credit note requests match with the credit note, all credit notes and credit note requests will be set to matched status.

One-to-One Invoice Matching Algorithm

One-to-one credit note matching is considered another form of summary matching. The only addition to the rule is that instead of attempting matches in groups, one-to-one matching attempts to match a single credit note with a single credit note request.

The batch first attempts a match between the total extended costs. If the total extended costs do not match exactly for the credit note and the credit note request pair, then tolerances are applied to check if the cost discrepancy is within tolerance. In case quantity matching is required by the supplier, header level quantity matching is also attempted for the document pair within tolerance. If no match can be found, the documents are left in their original status.

One-to-one algorithm will attempt a match only when at least one unmatched credit note exists in the document-key set. If no unmatched credit notes remain, then processing stops for the document-key set.

Some scenarios of one-to-one matching are listed below. Note that the examples are given to demonstrate an understanding of one-to-one matching algorithm. It is assumed that quantity matching is required in the supplier options, and documents are matchable only by credit Note Request ID.

Example 1: Exact Match

The following example illustrates how one credit note matches with one and only one credit note request. One credit note and two credit note requests are left in their original approved status.

Table 4-14 Exact Match

Credit Note ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNT 1	$50,000	$5,000	Matched
CRDNT 2	$100,000	$10,000	Approved

Table 4-15 Exact Match

Credit Note Request ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNRC 1	$50,000	5.000	Matched
CRDNRC 2	$25,000	2,500	Approved
CRDNRC 3	$35,000	2,500	Approved

In the example, CRDNT 1 matches with CRDNRC 1. However, the remaining credit (CRDNT 2) does not match with either of the two remaining credit note requests so it remains unmatched. The remaining credit note requests (CRDNRC 2 and CRDNRC 3) are also left in their original state. The matching algorithm will now move to the next matching algorithm within the document-key set to consider matching these documents.

Example 2: Match unsuccessful; one credit note but two credit note requests

The following example illustrates an unsuccessful match i.e. no successful matches.

Table 4-16 Match Unsuccessful; one Credit Note – two Credit Note Requests

Credit Note ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNT 1	$50,000	5,000	Approved
CRDNT 2	$25,000	2,500	Approved
CRDNT 3	$35,000	3,000	Approved

Table 4-17 Match Unsuccessful; one Credit Note – two Credit Note Requests

Credit Note Request ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNRC 1	$40,000	5,000	Approved
CRDNRC 2	$25,000	2,500	Approved
CRDNRC 3	$25,000	2,500	Approved
CRDNRC 4	$10,000	1,000	Approved

In the example, CRDNT 2 can be successfully matched to both CRDNRC 2, and CRDNRC 3. Therefore, no match can be obtained for Invoice 2. All credit notes and credit note requests are left in their original status.

Example 3: Match unsuccessful; two credit notes for one credit note request

The following example illustrates another multi-unresolved match, with no successful matches.

Table 4-18 Match Unsuccessful

Credit Note ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNT 1	$40,000	4,000	Approved
CRDNT 2	$25,000	2,500	Approved
CRDNT 3	$25,000	2,500	Approved
CRDNT 4	$10,000	1,000	Approved

Table 4-19 Match Unsuccessful

Credit Note Request ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNRC 1	$50,000	5,000	Approved
CRDNRC 2	$25,000	2,500	Approved
CRDNRC 3	$35,000	3,000	Approved

In the example, CRDNRC 2 can be successfully matched to both CRDNT 2 and CRDNT 3. All credit notes and credit note requests are left in the original Approved status.

Example 4: All credit notes are matched, but credit note requests remain

The following example illustrates a scenario in which all credit notes match, but there are remaining unresolved credit note requests.

Table 4-20 All Credit Notes Matched, Credit Note Requests Remain

Credit Note ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNT 1	$50,000	5,000	Matched
CRDNT 2	$25,000	2,500	Matched
CRDNT 3	$35,000	3,000	Matched

Table 4-21 All Credit Notes Matched, Credit Note Requests Remain

Credit Note Request ID	Total Extended Cost	Total Quantity	Status Post Matching
CRDNRC 1	$50,000	5,000	Matched
CRDNRC 2	$25,000	2,500	Matched
CRDNRC 3	$15,000	2,500	Approved
CRDNRC 4	$35,000	3,000	Matched
CRDNRC 5	$75,000	10,000	Approved

In the example, all three credit notes are successfully matched to one and only one credit note request. However, two unmatched credit note requests remain. Since there are no credit notes left for matching, processing will stop for this document-key set.

Line Level Matching Algorithm

Once summary matching and one-to-one matching pools have been exhausted, the CreditNoteAutoMatchBatch proceeds to attempts match at the line level.

In addition to the eligibility requirements for summary matching, lines must be present on the documents for Line-level matching to proceed. The batch assumes that all lines are present and valid for that credit note and credit note request. Moreover, the algorithm attempts matches only if there is just one credit note left unmatched in the document-key set.

Considering that only one eligible credit note and zero-to-many credit note requests are unmatched for a document key-set, the system attempts to match each line item on that credit note to a credit note request line item. When a detail level match is found, the detail on the credit note and credit note request documents are both flagged as matched. Once line level matching is complete for a document key-set, and all lines have been matched, then the entire credit note and all of its related credit note requests are considered matched. Otherwise, they remain in their original approved status.

For line-level matching, cost and quantity matching are always performed. If cost matching fails, quantity matching is still performed in order to route potential quantity discrepancies that may be discovered.

For quantity line level matching, the comparison is made between the sum of quantities from the credit notes and sum of the quantities on the credit note request for that item. If a quantity match cannot be obtained, then a quantity discrepancy is generated and routed for the credit note and the credit note request lines for that item.

Example 1 (match within tolerance)

The following example illustrates a scenario in which all lines match within tolerance, and the credit notes and credit note requests are set to matched status.

Table 4-22 Credit Note Match Within Tolerance

Credit Note	Item	Unit Cost	Quantity	Status Post Matching
CRDNT 1			550	Matched
Line	1	$5.00	100	Matched
Line	2	$10.00	200	Matched
Line	3	$15.00	250	Matched

Table 4-23 Credit Note Request Match Within Tolerance

Credit Note Request	Item	Unit Cost	Quantity	Status Post Matching
CRDNRC			565	Matched
Line	1	$5.02	105	Matched
Line	2	$10.10	210	Matched
Line	3	$15.03	250	Matched

In the example, assume line-level tolerances are set such that all lines match, therefore the line-level statuses are set to matched accordingly.

Example 2 (match resolving discrepancy)

The following example illustrates a scenario in which tolerances allow only one line to matches, but the CreditNoteAutoMatchBatch is able to resolve the discrepancies in other items, and match the credit note and credit note request.

Table 4-24 Credit Note Match Resolving Discrepancy

Credit Note	Item	Unit Cost	Quantity	Status Post Matching
CRDNT 1			550	Matched
Line	1	$12.00	100	Matched (by resolving discrepancy)
Line	2	$10.00	200	Matched
Line	3	$12.00	250	Matched (by resolving discrepancy)

Table 4-25 Credit Note Request Match Resolving Discrepancy

Credit Note Request	Item	Unit Cost	Quantity	Status Post Matching
CRDNRC 1			600	Matched
Line	1	$12.00	110	Matched (by resolving discrepancy)
Line	2	$10.10	200	Matched
Line	3	$10.10	250	Matched (by resolving discrepancy)

In the example, the lines value for Item 2 is matched. However, Items 1 and 3 do not match within tolerance. If however, reason codes are entered in the appropriate default columns for automatically handling Credit Note matching discrepancies in the system options table, then discrepancies are created automatically for Item1 and Item 3 and the two items are set to matched status on both documents.

Discrepancy Creation and Resolution in Line Level Matching

When discrepancies are created as part of the line-level matching process, they are automatically resolved by the batch process. This resolution takes place by selecting the appropriate reason code from the system options and then resolving those discrepancy by creating resolution actions in the system. For instance, if a cost discrepancy is detected, then a resolution action in the form of a Credit Note Request for cost or a Credit Memo is generated. On the next run of the reason code action rollup process, these newly created resolution actions will be rolled up to create the appropriate resolution documents.

It is important to distinguish the differences between overages that are in favor of the retailer as opposed to the supplier. In credit note matching, when a credit note is greater than the credit note request issued for it, the overage is in the favor of the retailer and a credit memo is issued to reconcile the discrepancy. This is because the credit note already represents an asset to the retailer. The supplier has issued more credit to the retailer than was appropriate based on the credit note request. If the retailer does not wish to automatically issue credit memos when the credit note is larger than the credit note request, then the system options, Auto-resolution Reason Code for Credit Memo - Cost and Auto-resolution Reason Code for Credit Memo-Qty, should be left blank.

If the applicable system option for a resolution action code type does not have a reason code defined in the System Options Maintenance screen then discrepancies of that type are not generated. It is assumed that the retailer will handle these discrepancies manually. This means that the credit note will not be matched and processing will stop for the document set. This allows for the retailer to have the batch resolve only specific discrepancy types. For example, many retailers may not want to automatically generate Credit Memos in response to Credit Note overages.

Example 1 (cost discrepancy)

The following example illustrates a scenario in which the first line on the credit note matches with the first line on the credit note request. The second line has a cost discrepancy.

Table 4-26 Credit Note Cost Discrepancy

Credit Note	Item	Unit Cost	Quantity	Status Post Matching
CRDNT 1			300	Matched
Line	1	$12.00	100	Matched
Line	2	$5.00	200	Matched (by resolving discrepancy)

Table 4-27 Credit Note Request Cost Discrepancy

Credit Note Request	Item	Unit Cost	Quantity	Status Post Matching
CRDNTR 1			300	Matched
Line	1	$12.00	100	Matched
Line	2	$10.00	200	Matched (by resolving discrepancy)

In the above scenario Item 2 in credit note and credit note request has a cost discrepancy of $5. The Line level match algorithm automatically generates a cost discrepancy for the item, and generates a Resolution Action in the system for a Credit Note Request - Cost, where the total extended cost on the credit note request is $1,000.00.

Example 2 (quantity discrepancy)

The following example illustrates a scenario in which the first line on the credit note matches with the first line on the credit note request. The second line has a quantity discrepancy.

Table 4-28 Credit Note Quantity Discrepancy

Credit Note	Item	Unit Cost	Quantity	Status Post Matching
CRDNT 1			300	Matched
Line	1	$12.00	100	Matched
Line	2	$10.00	200	Matched (by resolving discrepancy)

Table 4-29 Credit Note Request Quantity Discrepancy

Credit Note Request	Item	Unit Cost	Quantity	Status Post Matching
CRDNTR 1			310	Matched
Line	1	$12.00	100	Matched
Line	2	$10.00	210	Matched (by resolving discrepancy)

In the above scenario, Item 2 in credit note and credit note request has a quantity discrepancy of 10 (assumed to be above tolerance values). The Line level match algorithm automatically generates a quantity discrepancy for the item, and generates a resolution action in the system for a Credit Note Request - Quantity. The above discrepancies are in the favor of the supplier. In case of the discrepancy being in the favor of the retailer, resolution actions would have been Credit Memos (cost or quantity).

Example 3 (orphan items - credit memo)

A case might exist when an item on the credit note does not exist on the credit note request. The CreditNoteAutoMatchBatch will resolve the discrepancy of the orphan items by utilizing the resolution actions for Credit Memos.

Table 4-30 Credit Note Orphan Items - credit memo

Credit Note	Item	Unit Cost	Quantity	Status Post Matching
CRDNT 1			300	Matched
Line	1	$12.00	100	Matched
Line	2	$10.00	200	Matched (by resolving discrepancy)

Table 4-31 Credit Note Request Orphan Items - credit memo

Credit Note Request	Item	Unit Cost	Quantity	Status Post Matching
CRDNTR 1			150	Matched
Line	1	$12.00	100	Matched

In this scenario Item 2 in credit note does not exist in the credit note request. This orphan item creates a cost discrepancy. Since the discrepancy is in the favor of the retailer, the Line level match algorithm will automatically generate a Resolution Actions in the system for a Credit Memo-Cost, where total cost on the memo is $2,000.00.

Role of Reason Code Action Rollup Batch in Credit Note Matching

The ReasonCodeActionRollupBatch facilitates the CreditNoteAutoMatchBatch process in the following ways:

Document Creation

Resolution actions created as part of the discrepancy creation process of the CreditNoteAutoMatchBatch are converted to first class documents on the next run of the ReasonCodeActionRollupBatch. This is an existing feature of the ReasonCodeActionRollupBatch.

Tolerances

Tolerances are handled in a manner similar to the invoice auto match batch process, and tolerance values used for credit note auto match are same as the tolerance values used for invoice matching.

Matching tolerances are defined at the following levels:
- Summary or Line
- Cost or Quantity
- Favor of Retailer or Supplier
- Amount or Percentage
Summary matching and one to one matching are both considered types of summary matching, therefore, one to one matches also uses summary level tolerances.

During the match process, tolerances are selected in the following order:
1. Supplier
2. Department
3. System
If no supplier level tolerances are defined, then departmental tolerances are used for a random item in the document set. If departmental tolerances are not defined for that item, then system level tolerances are used for the document set. Note that a document set must have items to use department level tolerances.

Currencies

Credit Note Matching will only be attempted if the Credit Note and the Credit Note Request are in the same currency. If that currency is not the same as the tolerance currency, the documents will be converted to the tolerance currency before variances are calculated.

TAX Matching

CreditNoteAutoMatchBatch only detects Tax discrepancies at the detail level. This means that when documents are being processed by the detail matching algorithm, a check is performed prior to matching, ensuring that for each item the Tax codes and rates on the credit note match those on the credit note request for the corresponding item. When a discrepancy is detected, processing for that document stops and detail matching is not performed for that document. In this circumstance, the user will have to resolve the Tax discrepancy manually through the user interface.

History and Record Keeping

ReIM records summary and detail history for matched credit notes and credit note requests. The existing credit note matching history data model will be leveraged to ensure than an accurate accounting of match data is stored in the system. In addition, a new history data model has been introduced which holds history data for a specific match. The new history tables are populated after the completion and success of a match.

Data Purge

When document data becomes dated, it is purged from the system through the TablesPurgeBatch. This is also true for the CreditNoteAutoMatchBatch related data.