Aller au contenu principal

How transport orders are read: stops, references, times and loads

  • Utilisateur
  • Admin

The loading address, the hours, the loading metres and the temperature on a transport order each come from a field of your order model. Each field has its own extraction instruction in the AI mapping.

Hyperfox copies what the document says for that field, as that instruction describes it. It does not calculate loading metres, a temperature, an hour, a weight or a price on a transport order. The fields differ per environment, so this page refers to the fields of your order model rather than naming them. Your environment has a stock order model or a transport order model. Product in Settings shows which one.

Stops: loading and unloading addresses​

A transport order usually has one or more stops. Each stop has its own loading or unloading address, its own dates and hours and its own goods. In the validation screen, such a repeating part of the order is a block with one tab per entry. The tabs are numbered from 1 and named after the block in your order model. A tab with a problem shows how many errors it holds. Each entry has its own fields and its own address pickers. You can add an entry or delete the one you are on.

Hyperfox fills each address on each stop separately, the same way it fills the delivery address of a stock order. It reads the name and address lines it finds for that stop. Then it searches your address list for the record that fits. That search works as described in How customers and delivery addresses are matched. If nothing fits well enough, the address stays empty and you choose it in the picker. If the address is missing from your address list, add it while validating.

Two different instructions set whether an intermediate stop becomes a stop on the same order or a separate order. The instruction on the block of stops says what counts as a stop. The split instruction of the AI mapping says when a document holds more than one order, for example one per truck. Splitting is described in How one e-mail becomes several orders. A stop that appears as a separate order, or two stops where you expected one, comes from those two instructions.

References on a transport order​

A transport document often carries several numbers. Examples are the customer's order number, a booking or file number, a container number and a seal number. Another is a reference for the loading or unloading site. Each number goes to its own field only if your order model has that field. The instruction on each field says which number it takes and which it does not. When Hyperfox reads the document, it lists every number that could fit. If two instructions describe their numbers the same way, a number can go to the wrong field. The way the customer reference is read applies to every other reference field too.

Loading and unloading times​

Hyperfox writes every date and time it finds in a standard form, so "14u30" on the document becomes 14:30 on the order. Depending on your order model, an hour is a field of its own or part of a date-and-time field. When the document shows no value for a field, Hyperfox's own instructions say to leave that field empty. Nothing in Hyperfox says what to do with a date whose hour is missing. The instruction on that field says what to do. A document can carry several moments, such as a loading slot, an opening time and a delivery deadline. The instruction on each field says which one it takes. It also says what to do with a window such as "between 8 and 12". The reason dates are read this way is under Dates.

Loading metres, pallets, weight, container and temperature​

Loading metres, the number and type of pallets, the weight, the container type, the temperature and similar values are fields of your order model. Each field has its own instruction. Hyperfox takes the figure the document gives. It does not calculate loading metres from pallets, a weight from the goods, or a temperature from the kind of transport.

An empty field usually means that the document did not state the value in a way the instruction describes. A general rule belongs in the instruction on that field. Examples are how many loading metres one pallet takes, or which words mean a refrigerated load. The instruction then tells Hyperfox to calculate the value that way. You check the result on the first orders. The instruction also covers a figure that the document states differently from what you expect, for example half the loading metres. The instruction says which figure Hyperfox takes when the document gives more than one.

Hyperfox reads a field only with the AI mapping of the route the e-mail was sent to. An e-mail can arrive through a different address or route from usual. The AI mapping of that route can describe the field differently, or not at all. Routes are covered under Choose a route.

Flags and types: refrigerated, tail lift, transport type, container and pallet type​

A refrigerated load, a tail lift, the transport type, the container type and the pallet type are fields of your order model. Each field has its own instruction, like the loading metres. Such a field is a yes/no field, a text field or a field linked to a reference data list. An example of such a list is a list of pallet types. Which kind it is depends on how Hyperfox set up your order model.

Hyperfox fills such a field only from what the document says, in the way the instruction on that field describes. Its own instructions say to take values as written. It writes nothing in a field it finds no value for. So a document that says "frigovracht" while the instruction only names "frigo" leaves the field empty or cleared. The same happens when a document names no transport type at all. A flag that is selected where the load does not need it comes from the same place. Its source is a word in the document that the instruction counts as a sign of that flag.

The rule belongs in the instruction. The instruction says which words mean a refrigerated load and which do not, and which wording means a tail lift. It also says which transport type to choose when the document names none. Such a rule for one customer only goes under "Special cases:", as Defaults per customer describes.

A field linked to a reference data list works like an address. Hyperfox reads the words in the document and searches the list for the record that fits, the same way it matches customers and delivery addresses. If the document names no pallet or container type, Hyperfox has nothing to search. The field then stays empty, even when your list holds a single type. A type that applies to every order of a customer, such as one pallet format, is a default in the instruction. If you choose a record in such a field that Hyperfox left empty, Codex records nothing. Codex records only a record you chose instead of the one Hyperfox matched. Which corrections count is set out in Which corrections become an entry.

Prices, surcharges and totals​

A price, a tariff or a surcharge is on the order only if your order model has a field for it. The instruction on such a field says what Hyperfox reads into it. An example is the unit price and not the total amount of a row. Hyperfox calculates no price, no surcharge and no order total itself. The totals under the lines are the sum of the lines as they are. A transport order shows no accuracy.

Defaults per customer​

An empty field means the document did not show the value, unless the instruction on that field gives a default. A default can apply to one customer or one kind of order. An example is your own depot as the loading address when the document names none. Such a default goes in the instruction, under "Special cases:", with the customer's name as it is in your reference data. How to write such a default is in Write an instruction that works. A default address must exist in your address list, because Hyperfox still has to find the record.

What your TMS adds after Hyperfox sends​

Hyperfox sends the order as it is stored when you validate it: its fields, its lines and the records they point to. The contents are listed in What is in the message. Hyperfox does not send a line or a value you deleted in Hyperfox.

Your transport management system (TMS) can still fill or change the order after it arrives. For example, its own template for that customer, a model file, can add a tariff line, a pallet format, dates or addresses. If a tariff line you deleted in Hyperfox appears again in your TMS, your TMS added it, not Hyperfox. The same goes for a value in your TMS that differs from the validated order in Hyperfox.

What your TMS adds changes only in its template for that customer, in your TMS. If your TMS fills a field, the instruction on that field can tell Hyperfox to leave it empty.

What you can change​

When you correct a value on the order and validate, that order is right. When you choose a different loading or unloading address from the one Hyperfox matched, it records that correction in Codex. It does the same for any other field that links to your reference data. Codex does not learn a typed reference, an hour, a figure or a price. The full rule is in Which corrections become an entry.

If the same field is wrong or empty again and again, the lever is the instruction on that field. Your admin changes it under Admin settings > Mappings, following Steer how the AI reads a field. Operators give their admin the field, the sender and an example order. If the field you need is not on the order at all, support adds it to the order model and the AI mapping together. The split of tasks is set out in What you can configure, and what Hyperfox configures.

See also​

Dernière mise à jour le