BE priority and matching

As mentioned previously, ATE transactions will attempt to match a customer or supplier in a transaction with a record in the BE table. This matching is determined by configured priorities. This section describes the matching and priority process in ATE.

Matching is simply a selection process, or the process by which an element of your master data is selected from the BE table for use in a current transaction.

For example, assume you send ATE information about a buyer with a CustomId of 12345 in transaction data. Using the buyer information, ATE will review the BE record for that buyer to see if there’s a BE with a CustomId of 12345. At this point, behavior changes depending on whether ATE finds that match.

If there’s a match
- ATE will verify the buyer's legal name, address, and licenses.
- If any information about the buyer differs between what is in the BE and what is in the transaction (for example, the address), then ATE will follow your business practices to determine what to do (for example, update the BE, do nothing, and so on).
If there isn’t a match, then based on your business practices, ATE may attempt to create a new BE if there’s enough information.

Note Matching puts the burden on specific ID fields that are used to connect a record in transaction data with a record in the BE table. Once a match is made, the values in the table override any values provided in the transaction data.

Priority describes the way that identifying elements are used to make a match. The above example assumed matching based on the custom ID. In ATE, matching can be prioritized based on the custom ID (using CustomIdPriority), the legal name (using LegalNamePriority), and the BE ID code/type (using IdCodeAndIdTypePriority). The priority value for each decides the priority order when making a match. Example priority settings can be:

Custom ID priority 1, legal name priority 0, ID code/type priority 0:
- Use just the CustomId to match an entry in the BE table. If a match isn't found, create a new record.
- Matching records solely on a BE's CustomId is generally the preference, but these priorities should follow your specific business practices.
Custom ID priority 1, legal name priority 1, ID code/type priority 1:
- ATE will match a record based on the CustomId, LegalName, AND the ID code and type included in the BusinessEntityIdCodes model.
- This priority matching most closely matches a system of record (SOR) matching rule.
Custom ID priority 1, legal name priority 2, ID code/type priority 2:
- ATE will attempt to match on the CustomId first. If there isn't a match, then ATE will attempt to match on BOTH the LegalName, AND the ID code and type included in the BusinessEntityIdCodes model.

Note It's possible for multiple business entities to have the same CustomId. This can occur when BE is obsolete (using ObsoleteDate), and then a new, unlocked entry is created by copying the obsolete BE. When performing a search based on a CustomId, ATE will search unlocked records first, then return any obsolete records.