Aller au contenu principal

How Hyperfox matches the item on each order line

  • Utilisateur
  • Admin

Every order line needs an item from your reference data, but the document gives only text. That text can be an item code, a name, an EAN, and sometimes the customer's own code. Hyperfox matches that text to an item in your reference data. To correct an item on an order, change the item on the line.

What Hyperfox reads from a line​

For each line, Hyperfox records everything that could identify the item: every code, the description and the EAN. A line often carries two codes, the customer's item number and yours. It keeps both, and the matching step takes one.

Where it searches​

Your AI mapping sets which lists Hyperfox searches for an item. In most environments, that is your item list. Some environments search a customer-specific list first. Examples are the item codes your customers use for your items, or the items a customer ordered before. Hyperfox searches those lists in order and takes the first hit. A line with the customer's own code therefore finds your item through that list. In the mapping editor, admins see the lists as labels under the field name, for example item.

Hyperfox searches a customer-specific list for the customer on the order. It matches the customer first and then searches only that customer's codes. If the customer on the order is wrong or empty, Hyperfox does not find the customer's own codes. Many lines can then stay without an item.

Hyperfox searches only the columns your admin set as searchable, for example item code, name and EAN. It cannot find a code in a column that is not searchable, however exact the code is. Your admin sets per list which columns are searchable. Make a column searchable gives the steps.

The search allows small differences in spelling and word order, so "premium tray lid" can still find "LID TRAY PREMIUM". Hyperfox then takes the best candidate from the results. If no candidate fits well enough, the item stays empty.

Hyperfox applies the extraction instruction of the item field at both steps: when it reads the line and when it takes a result. That is why an instruction can say which column holds your code. An instruction can also say how your codes relate to the codes your customers write.

Codes that differ by a letter or a prefix​

The search also returns items whose code shares a large part of the text on the document. A customer who writes 4711 therefore brings up your item 4711 G, and Q4711 brings up 4711. Whether Hyperfox takes that item depends on the rest of the line, such as the description. The code alone does not tell Hyperfox that your letter stands for a colour or a pack size. A variant that is a different item for you can therefore look like the same item to Hyperfox, and the reverse.

Codes your customers make up themselves, such as their numbers for private-label items, share nothing with yours. Hyperfox finds them only through a list that links them to your items, or through a Codex entry after someone corrected the item.

When you type in the item cell of a line, the picker searches the text it shows for each item. It keeps the items that contain every word you typed. When Hyperfox reads the document, it searches the searchable columns of your item list instead. The automatic match can therefore find a code that you cannot find, and the reverse. The picker is not sorted by how well an item fits the line, and it loads more items as you scroll.

Sets and packs​

Hyperfox has no notion of a set or a bundle. A line holds one item, a quantity and a unit. The document can say "set of 3" or list the pieces of a set. Hyperfox can then read 3 as the quantity or each piece as a line. Nothing turns the pieces back into the set. The set is found only when it is an item in your reference data. In a stock order, Hyperfox accepts "set" as the unit only when "set" is one of that item's units.

Why a similar item wins​

Most wrong matches are close to the right item. Examples are fresh instead of frozen, 500 cc instead of 750 cc, and a box of 50 instead of a box of 100. This happens when:

  • The document gives only a description, no code, and two items have almost the same name.
  • The code on the document is the customer's own number, and no list in your environment links it to your item. Hyperfox then matches on the description instead.
  • The distinguishing word, such as the size or "frozen", is missing from the searchable columns.

An exact code in a searchable column beats any description. The more lines carry a code you can find in your reference data, the fewer wrong matches.

Why no item is found​

The item stays empty when:

  • The item is not in your reference data yet, for example a new item your ERP has not sent to Hyperfox.
  • The code on the document exists only in a column that is not searchable.
  • The text is too far from any item, for example an abbreviation only that customer uses.

An empty item shows as "Item is required" in the validation screen. That is intentional, because an empty field is an error you cannot miss.

Hyperfox can match an item that is still in your reference data, even when your ERP no longer sells it.

How it learns from your corrections​

When you change the item on a line and validate the order, Hyperfox records a Codex entry for that customer. The entry says: "for this text, not item A but item B". On later orders from that customer, Codex applies your correction when Hyperfox again matches the item you replaced, for a similar text. How Codex learns from your corrections explains how entries work.

An entry replaces an item Hyperfox found. It never fills an empty line, and choosing an item on an empty line records no entry. When an import deletes an item from your reference data, Hyperfox also deletes the Codex entries that point to that item. Later orders then need that correction again.

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​

If Hyperfox matched a similar item, an operator corrects the item and validates.

If the same customer's code fails again and again, the lever depends on your environment. If your environment has a list of customer codes, whoever maintains your reference data adds the code there. Otherwise an operator corrects and validates, and Codex links the text to the item for that customer.

If the item is missing, whoever maintains your reference data adds it, or checks why your ERP did not send it. The steps are in Add, edit and delete reference data records.

If the code on the documents is in a column that is not searchable, an admin makes the column searchable.

If Hyperfox reads the wrong code, such as the EAN of the outer box, an admin changes the extraction instruction of the item field.

What each lever changes, and what it does not, is in What you can change so Hyperfox reads your orders better.

See also​

Dernière mise à jour le