Stel, je hebt de volgende boeking:
memoriaal:17 2014-12-31 "nog te betalen bedragen" \
std 2014-12-31 "1-abc omschrijving" 100.00 1671 \
std 2014-12-31 "1-abc omschrijving" -100.00 4876
Deze wordt probleemloos en correct door EekBoek verwerkt.
Op een later moment exporteer je je administratie.
De hierboven getoonde boeking verschijnt in de exportdata als:
memoriaal:17 2014-12-31 "nog te betalen bedragen" \
std "1-abc omschrijving" 100,00 1671 \
std "1-abc omschrijving" -100,00 4876
Listig heeft EekBoek de datum op de "std" regels weggelaten, omdat deze toch identiek is aan de datum van de boeking zelf.
Maar weer op een later tijdstip probeer je om de geëxporteerde administratie weer te importeren. Dan stuit je op het volgende nare probleem op het moment dat deze boeking wordt geïmporteerd:
?Onherkenbare datum: 1-abc omschrijving
?INTERNAL ERROR: Command failed but did not rollback.
Dit breekt het importproces niet af, maar memoriaal:17 wordt niet geïmporteerd. Kennelijk raakt de EekBoek parser overstuur van de omschrijving waarvan het begin een vage gelijkenis vertoont met een datum (die -- helaas -- door EekBoek zelf in de export-fase weggeoptimaliseerd was ...).
Hoe hier mee om te gaan?
Ook met een aanscherping van de parser vrees ik dat er altijd randgevallen zullen blijven waarbij een omschrijving abusievelijk als een datum o.i.d. geïnterpreteerd wordt. Maar belangrijk lijkt me vooral dat gebruikers bij de eerstmogelijke gelegenheid op een dergelijk probleem gewezen worden.
Als bij het exporteren de data altijd in "standaard" formaat, dus inclusief mogelijk overbodige datumveld(en) weggeschreven wordt, kan dit probleem zich in ieder geval niet op een later en onverwacht moment manifesteren, maar uitsluitend indien de gebruiker zelf kiest voor invoer van de "verkorte" versie van de boeking.
Oplossing: genereer bij export altijd een (volledige) datum conform het geconfigureerde standaard formaat.
Log in to post a comment.
