What you can change so Hyperfox reads your orders better
- User
- Admin
Most of the time, steering Hyperfox means correcting a value on the order and clicking Validate. It rarely means writing something technical.
When a field is wrong again and again, your admin writes one plain sentence about that field. Your admin writes it the way you would explain it to a new colleague. Hyperfox keeps every save as a version that can be restored, and you test a change on one inquiry first. Both are described under The safety net. The steps Hyperfox takes are in How Hyperfox reads and fills in an order, step by step.
Correct and validate
If you replace the customer, item or unit Hyperfox matched and then click Validate, Hyperfox records that correction in Codex. On later orders from that customer, Codex applies your correction when Hyperfox again matches the record you replaced, for a similar text. A corrected customer applies to every later order with a similar text, whoever sends it. Only Validate records a correction. Save does not. If Hyperfox found no record and you choose one, it records your choice and applies it to the next document with exactly the same text. Matching itself is explained under Match to your reference data.
Every operator can do this, and it takes no knowledge of how Hyperfox reads documents. You correct the order you were going to validate anyway. You can also review, switch off or delete what Codex learned.
A Codex entry changes which record Hyperfox links to a text it read, for that customer. It does not change which text Hyperfox reads from the document. Codex records only corrections of a customer, an item, a unit or another field that links to your reference data. Codex therefore does not learn a typed reference, a date, a quantity or a note. Which corrections become an entry lists the corrections that count.
Write an instruction on one field
Every field of your order has an Extraction instruction in the AI mapping. Your admin edits it under Admin settings > Mappings. When Hyperfox reads the document, it uses that text word for word as the description of the field. The text sits under a heading that asks for the descriptions to be followed carefully. The places an instruction names, such as "after 'Ordernummer:' at the top", are suggestions, not the only places Hyperfox searches. Hyperfox sends the values under Examples with the field as sample values.
An instruction is therefore plain language, not code. A good instruction explains the field the way you would explain it to a new colleague. It says what the field means for your business, where it is on the document and what it is not. English works best. Dutch or French is fine if you express yourself better in it. Operators cannot open Mappings. An operator who needs a change gives the admin the field, the sender and an example order. Steer how the AI reads a field gives the steps and example instructions.
An instruction changes which text Hyperfox takes from the document for that field, on every route that uses the AI mapping. It does not change which records exist in your reference data. An instruction therefore cannot make Hyperfox find an item that is not in your list. It also cannot make Hyperfox read a file it cannot read.
Keep your reference data in order
Hyperfox can only link a text to a record that exists. It finds that record only through the columns set as searchable. Three gaps block it. The first is an item or customer that is missing from your reference data. The second is an item you no longer sell that is still in the list. The third is a number on the documents that is in a column Hyperfox does not search.
Whoever maintains your reference data adds and deletes records, often through the import from your ERP. An operator can add a missing record while validating. An admin makes a column searchable.
A change to your reference data changes which records Hyperfox can match, for every customer at once. It does not change which text it reads from the document.
The safety net
Hyperfox keeps every save of an AI mapping under Version history. Restore this version restores an earlier one. Restoring saves the old content as a new version, so nothing is lost. In Codex, any user can switch off or delete a Codex entry that applies the wrong correction.
A change to an instruction applies only to inquiries Hyperfox reads after you save. Orders already in To validate keep what it read. A change applies to every route that uses the AI mapping. What to check first is listed under Before you begin.
You test an instruction on one inquiry, with Retry > Retry with current category. The test belongs on an inquiry that nobody has worked on. Retry deletes every order of the inquiry, including the changes you saved, and replaces them with a new reading. Then check the result.
What no lever changes
Before reading starts, the channel sets whether an e-mail is picked up and which of its attachments Hyperfox reads. The rules are in Which e-mails and attachments Hyperfox picks up.
An instruction in the AI mapping of one route does not help an e-mail that was sent to another route. The reason is that the AI mapping of the other route read that e-mail. In that case, retry the e-mail with the right route.
Your ERP and the export to it set what happens to an order after Hyperfox sends it. The contents of that export are on What Hyperfox sends to your ERP.
Who does what
Operators correct and validate orders, and review the entries in Codex. Admins write the instructions in the AI mappings and maintain the reference data lists, including which columns Hyperfox searches. Hyperfox sets up the order model, the first searchable columns and the structure of each AI mapping. That structure covers which fields the mapping has, which list each field is matched against and the Split instruction row. The full split of tasks is in What you can configure, and what Hyperfox configures.