Barcode Identity
A nomenclature says "this code is an item, and its key is 4006381333931". An identity line says where an item with that key is found. One line is one resolver: a kind of thing, a table, and the column to match on.
What it is for
After a code is parsed, the engine knows the kind of thing and the key. It must still find the record. It looks in two places, in this order.
- The register. If Businessflo generated this exact code itself, or the code was linked to a record, the register already knows which record it belongs to. That answer is final and the resolvers are not asked. A code linked to an item is answered as that item, as if the item's own code had been scanned. See Barcode Register.
- The resolvers on this screen. Only when the register has nothing. The engine takes the active resolvers whose Entity Type equals the one the nomenclature rule gave, in Sequence order, and asks each one for a record whose Key Column equals the key.
The match is always exact. A code never matches a record that merely starts with it or contains it.
The result is one of three:
one- a single record. The scan goes on to the action lines of Barcode Assignment.many- more than one record carries that key. The system does not guess. It opens the Help Object so the user picks.none- nothing carries that key. The scan is answered with nothing matched, unless the process line allows unknown codes.
Every field, in plain words
| Field | What it means | What to put in it | Notes |
|---|---|---|---|
| Identifier | The code of this resolver | ITEM01, LOT01 | Required. Must be unique |
| Entity Type | The kind of thing it finds | ITEM, EMPLOYEE, LOT, LOCATION | Required. Must equal the Entity Type on the nomenclature rule, letter for letter |
| Identifier Description | What this resolver does | Item by barcode | |
| Sequence | The order resolvers of the same Entity Type are tried in | 1, 2, 3 | Lowest first |
| Table Name | The table the record is in | iteminlegalentity | Required. A plain table name only |
| Key Column | The column compared with the scanned key | barcode, itemno | Required. A plain column name only |
| Display Column | The column shown to the user as the name of what was found | itemstxt | |
| Entity Column | The column whose value is handed to the action as the key of the record | itemno | This is what an Add Grid Line action writes into the grid |
| Opens Screen | The screen that owns this kind of record | PIPL, EPEB | Used by actions that open the record |
| Help Object | The lookup shown when the match is not a single record | HLP_ITEM | Without it, a code matching many records cannot be chosen from |
| Match Mode | Whether to stop at this resolver once it answers | exact or exactthenfallback | See below |
| Active | The resolver is tried | Tick it |
Match Mode
exact- if this resolver finds anything, the search stops here. Later resolvers of the same Entity Type are not asked.exactthenfallback- this resolver's records are kept and the next resolver is asked as well. Use it when the same key may legitimately live in two places and you want the user to see both.
Both modes compare for equality. Neither does a partial match.
What is delivered
| Identifier | Entity Type | Sequence | Looks in | Matches on | Opens |
|---|---|---|---|---|---|
ITEM01 | ITEM | 1 | iteminlegalentity | barcode | PIPL |
ITEM02 | ITEM | 2 | iteminlegalentity | itemno | PIPL |
EMPLOYEE01 | EMPLOYEE | 1 | employeebasic | employeeno | EPEB |
So a scanned item code is first compared with the barcode stored on the item, and only if no item has that barcode is it compared with the item number. All three skip deleted records.
No resolver is delivered for LOT, LOCATION, PACKAGE or SERIAL. A screen that handles such a scan itself, as Picking List Registration does for a batch, does not need one.
How to configure it
- Decide the kind of thing. Check that a nomenclature rule produces that Entity Type.
- Create the resolver. Give it the same Entity Type, the table, and the column that holds what is printed in the barcode.
- Set Entity Column to the record's own code, and Display Column to its name.
- Set Help Object, so that a key matching several records can be chosen from.
- If a second column can also carry the key, add a second resolver with the next Sequence.
- Tick Active and save.
Scenarios
Items carry the supplier's barcode and our own item number
Nothing to do. ITEM01 finds the item by its stored barcode and ITEM02 by its item number, in that order.
Staff badges carry the employee number
Nothing to do. EMPLOYEE01 matches the badge against the employee number. The nomenclature rule that reads the badge must give Entity Type EMPLOYEE.
The same barcode is on two items
The resolver returns both, the result is many, and the Help Object opens for the user to pick. This is deliberate. A wrong item added silently is worse than one extra click.
What it is connected to
- Barcode Nomenclature produces the Entity Type and the key this screen matches on.
- Barcode Register is asked first and overrides every resolver.
- Barcode Assignment receives the result: its action lines are chosen by Scanned Entity Type.
If something looks wrong
- "nothing matched" followed by the code - the register does not have it and no active resolver of that Entity Type found a record. Check the Entity Type spelling on both screens, then check the value really is in Key Column.
- "The item is found by item number but not by its barcode" - the barcode on the item is not exactly what is printed. Leading zeros and spaces count.
- "A list opens instead of the item being added" - more than one record matched. That is the
manyresult. - "My new resolver is never used" - an earlier resolver with Match Mode
exactalready answered, or the resolver is not Active. - "A code Businessflo printed resolves to the wrong record" - the register answers before any resolver. Open the Barcode Register and see which record the code is registered against.