Doorgaan naar hoofdinhoud

How customers and delivery addresses are matched

  • Gebruiker
  • Admin

Every order needs a customer, and most orders also need a delivery address and an accounting customer. The document gives only text, such as a company name, a customer number and a few address lines, often for several parties at once. Hyperfox matches that text to records in your reference data. Add a missing customer, address or item while validating shows how to correct a customer or address on an order, or add a missing one.

What Hyperfox reads​

A document names parties in several places. These are the customer who orders, the party that pays, the address to deliver to, and in most documents your own company as the supplier. Hyperfox reads each party with the name, the number and the address lines it finds. Your AI mapping sets which of those parties fills which field of the order. The instruction on each field tells Hyperfox where to look, for example under "Sold-to" or "Deliver to". It also says which party to skip. Steer how the AI reads a field shows how to write it.

Where it searches​

Your AI mapping sets which list Hyperfox searches for each field. It searches your customer list for the customer and the accounting customer, and your address list for the delivery address. As with items, it searches only the columns your admin set as searchable. In most environments, those are the name and the customer number. Hyperfox cannot find a number in a column that is not searchable, however exact the number is.

An exact customer number beats any name. If the document carries only a name, Hyperfox compares it with the names in your list and takes the best candidate. If nothing fits well enough, it leaves the field empty, and you choose the record in the validation screen.

The customer number needs to be unique in your list. If two records share a number, Hyperfox cannot tell which one the document means and can take either.

Customer, accounting customer and delivery address​

An order has three party fields, and their labels differ per environment. They are the customer who orders, the accounting customer who receives the invoice, and the delivery address. Hyperfox fills each field on its own, from what the document says. It does not derive the accounting customer from the customer. If the document does not name a payer, the accounting customer stays empty.

In most environments, the address list is linked to the customer list. The picker for the delivery address then shows only the addresses of the customer on the order. That filter starts on, and you can switch it off to see every address. You cannot switch it off if Hyperfox locked the filter for your environment. In environments set up for it, the field shows a warning when the customer has several addresses that fit: "Several options are possible. Check the selection." What each part of the validation screen shows lists that warning.

Some environments keep the bill-to, the payer or the ship-to of each customer in a list of their own, as in many ERPs. In that list, every record belongs to one sold-to customer. In those environments, Hyperfox matches the customer first. Then it searches each of these fields only among the records of that customer. It does not take a record that belongs to another customer, even when its name fits better. If none of the customer's records fits the text on the document, the field stays empty. In the validation screen, the picker of such a field can be filtered on the customer, in the same way as the address picker.

Hyperfox still fills each of these fields from what the document says. It does not copy a bill-to or payer from the customer record. If the document names no bill-to or payer, the field stays empty, even when the customer has only one in your list. When you change the customer on an order, the bill-to, payer and ship-to Hyperfox matched stay as they are. Those fields then need a check too. Some kinds of documents never name a bill-to or payer. For those, an instruction on the field can tell Hyperfox what to take instead, for example the customer's own number. Your admin writes it as described in Steer how the AI reads a field.

If Hyperfox matched the wrong customer, every field that depends on the customer can be wrong or empty too. The customer then comes first in your corrections, before the bill-to, the payer and the address.

Why the wrong customer wins​

Most wrong customers are close to the right one. This happens when:

  • Two records have almost the same name, for example two branches of the same group, and the document carries no customer number.
  • The document names several parties and Hyperfox matched the wrong one. Examples are the party that pays instead of the one that orders, or a parent company instead of the branch.
  • Hyperfox took your own company, which the document names as supplier, for the customer.
  • The customer number on the document is in a column of your list that is not searchable, so Hyperfox matched on the name instead.
  • Two records in your list share the same customer number.

Why no customer is found​

The customer stays empty in three cases. The first is a customer that is not in your reference data yet, for example a new customer your ERP has not sent to Hyperfox. The second is a number on the document that exists only in a column that is not searchable. The third is a name on the document that is too far from any name in your list.

An empty customer shows as required in the validation screen, with the name of the field followed by "is required". Validate stays blocked until you choose a customer. An empty customer or accounting customer also lowers the accuracy of the order.

How it learns from your corrections​

When you replace the customer Hyperfox matched and validate the order, it records a Codex entry. That entry applies to every later order where Hyperfox reads a similar text, whoever the sender is. When you replace the accounting customer or the delivery address, the entry applies only to later orders of that customer. The rules for this are under the scope of a Codex entry.

If Hyperfox found no record at all and you choose one, there is no wrong match to correct, so no Codex entry is recorded. Hyperfox still records your choice. The next time it reads exactly the same text and finds nothing, it fills in the record you chose. This is part of how Hyperfox matches to your reference data.

Rejecting an inquiry deletes the choices Hyperfox recorded from that inquiry. A new run can read the document differently, for better or worse. Hyperfox does not learn from a retry. Only a validated correction records a Codex entry.

What you can change​

Correcting the customer or address on the order and validating is the first lever. It is the only lever an operator needs, and Codex does the rest.

If Hyperfox matches a similar name again and again, whoever maintains your reference data checks the customer number. The number needs to be on the record and unique in the list.

If the number on the documents is in a column Hyperfox does not search, your admin makes that column searchable.

If Hyperfox takes the wrong party again and again, such as the payer or your own company, an admin changes the field's instruction. The new instruction names the right spot on the document.

Your admin sets on the field whether the address picker is filtered on the customer, and whether you can switch that filter off. The steps are in Switch a picker filter on, off or to enforced.

See also​

Laatst bijgewerkt op