M.i.v. deze Releasenote is de afhandeling van het afdrukken + scannen van een Barcode drastisch veranderd.
Het betreft een meer interne aanpassing met een totaal andere opzet, die er voor moet zorgen dat de verschillende kombinaties die op kunnen treden nog enigzins te behapstukken zijn.
Zo is het enerzijds uitermate handig dat er Application Identifiers (AI) in een Barcode zitten die bijv. aangeven waar de EAN Code begint, waar het Chargenummer begint of welk gegeven dan ook. Bij het afdrukken van een Barcode zal de Printer danwel het gebruikte font kunnen afdwingen dat er een bepaald character moet worden gebruikt ter identifikatie van een nieuwe AI.
Bij bijv. een Etiket op een Zebra Printer is dit een kode '>8' terwijl dit bij de Morovia Font set een CHR(199) betreft (en wellicht zijn er nog meer printers die alsnog weer kompleet anders aangestuurd moeten worden).
Zo blijkt ook dat de ene Scanner wel een Character scant als teken voor een nieuwe AI, terwijl een andere dat niet doet. Dit zal ongetwijfeld afhankelijk zijn van de Scanner, en mogelijk zelfs een instelling betreffen.
Los van of het wel of niet instelbaar is, en dat het herkennen van een nieuwe AI handig is bij het teruglezen, is er ook een keerzijde van de medaille: immers, als we alleen maar zouden toestaan dat er Barcodes gelezen kunnen worden waarbij een nieuwe Application identifier herkenbaar is door een bepaald character (afhankelijk dus van de printer), zou ook gelden dat de Gebruiker deze moet intypen als de Barcode niet gescanned kan worden.
Je kunt niet van de Gebruiker verlangen dat als ze de Human Readable Code intypt (een tekst die meestal onder een Barcode wordt afgedrukt, en die de waarde van die Barcode afdrukt als voor mensen leesbare tekst) ze bij aankomst van een Application Identifier (01 = EAN, 10 = Chargenummer) wel even "Alt+199" (of i.d.) intypt op de scanner ter identifikatie dat er een nieuwe AI begint.
Derhalve anticiperen we erop dat we na het lezen van de Barcode één reeks data terugkrijgen, waar weliswaar een AI(01) of AI(10) in voorkomt, maar niet 'vanzelfsprekend herkenbaar'.
Zo zou een etiket een Barcode kunnen bevatten:
(01)8792804001735(10)13340703(240)5.000In bovenstaand Human Readable formaat herkennen we eenvoudig
AI(01) = EAN Code = 8792804001735 AI(10) = Chargenr = 13340703 AI(240) = Extra info zoals W-Inhoud = 5.000
Echter, de string komt niet binnen zoals bovenstaand, maar zonder haakjes, dus als:
01879280400173510133407032405.000Tsja... en dat is het dus maar de vraag "wat is precies wat in deze string", zeker als je er rekening mee houdt dat bijv. een Chargenummer een variabele lengte kent, maar er van EAN codes inmiddels ook meerdere varianten in omloop zijn (13 cijferig, of 14 cijferig met een voorloopnul).
M.i.v. deze Releasenote wordt een Barcode altijd in zijn geheel behandeld en uitgeplozen, waarbij rekening wordt gehouden met zaken als "als 2405.000 bij de W-Inhoud hoort, dan zal dit niet meer bij het Chargenummer kunnen horen".
Hoewel dit alleen een intern andere afhandeling betreft van het lezen en verwerken van de Barcodes, geldt toch dat e.e.a. drastisch gewijzigd is. Als U gebruik maakt van de Scanfunktionaliteit, wees dan een beetje op Uw hoede bij de eerst volgende Upgrade.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOBCCD | Omschrijving (nog) niet bekend | 19-04-2006 | 11-05-2010 |
| LOBCLZ | Omschrijving (nog) niet bekend | 13-04-2010 | 11-05-2010 |
| LOLVGNAV | Omschrijving (nog) niet bekend | 31-03-2010 | 29-04-2010 |
