#42 Voorloopnullen in grootboeknummers worden inconsistent behandeld

[Wytze van der Raay]

Als je grootboeknummers gebruikt die verward kunnen worden met een verdichtingsnummer, dan is het de gewoonte om deze grootboeknummers van een of meer voorloopnullen te voorzien. EekBoek realiseert met de volgende hack in lib/EB/Tools/Schema.pm:

my $t = sprintf(" %-4s %-2s %-40.40s %s",
$id < $max_vrd ? (("0" x (length($max_vrd)-length($id)+1)) . $id) : $id,
$flags, $desc, $extra);

Deze code werkt niet altijd goed. Stel dat het grootste gebruikte verdichtingsnummer 84 is, dan worden grootboeknummers als 081, 082 en 083 correct verwerkt -- de voorloopnul blijft gehandhaafd bij export. Maar grootboeknummer 084 wordt verhaspeld tot 84, en dat geeft een fout ("Dubbel: verdichting 84") wanneer je dat schema weer probeert te importeren. Grootboeknummers 085, 086, ..., 099 worden eveneens ontdaan van de voorloopnul bij export, maar dit is vooral een esthetisch probleem en leidt niet tot import problemen.

Een voor de hand liggende oplossing lijkt om $max_vrd in bovenstaande code te vervangen door 99 (of 999 wanneer het grootste verdichtingsnummer >= 100 is). Maar of dat afdoende is, durf ik niet te zeggen. Een beter advies is wellicht om EekBoek gebruikers te adviseren om deze situatie geheel te vermijden, maw te verbieden (of af te raden) om grootboeknummers <100 of zelfs <1000 te gebruiken.

[Johan Vromans]

ALs ik het goed zie, is het probleem enkel dat in de genoemde regel
het < teken een <= zou moeten zijn?