Bij de ontwikkeling van de Behoefterun, werden zgn. "Elementaire Behoefte records" bewaard in een tabel op het netwerk (LOBH). Zodra er een nieuwe Inkomende- of Uitgaande Behoefte bij kwam (bijv. omdat er een Verkooporder werd toegevoegd) werd deze bijgewerkt in de tabel. Deze tabel diende als basis voor de Behoefterun.
Maar ja... omdat een Verkooporderregel ook weer verwijdert kan worden, kwam het ook voor dat er ook weer automatisch Behoefterecords uit die tabel moesten worden verwijderd. Ook wijzigen was aan de orde, omdat (weer de Verkooporderregel als voorbeeld nemend) de Leverdatum van een order kon worden gewijzigd, en daarmee het Behoefterecord op een andere datum kwam te staan.
Uitgangspunt was dat zodra zo'n Behoefte moest worden tegengeboekt, er ook daadwerkelijk een Behoefterecord aanwezig was die gekorrigeerd kon worden. Was dat niet het geval, dan leidde dit tot een "Onjuiste Tegenboeking", en wist je eigenlijk per definitie dat de basis voor het opstarten van een Behoefterun fout was.
Dergelijke onjuiste tegenboekingen traden om diverse redenen altijd wel op, waarna een procedure volgde "als je de Behoefterun wilt opstarten, moet je eerst de Elementaire Behoeftebasis opnieuw opbouwen". Middels een speciale run werden eerst alle Elementaire Behoefterecords verwijderd, en daarna weer opnieuw opgebouwd o.b.v. de aktuele stand van de orders.
Ook die werkwijze liep al snel in het honderd. Los van het feit hoe lang dat opbouwen precies duurde, tussen het moment van verwijderen van de Elementaire Behoeftes en het opnieuw opbouwen ervan, zijn er even geen Behoefterecords aanwezig. Als nèt op dat moment een Verkooporderregel werd verwijderd, en de opbouwende run was nog niet toegekomen aan het opnieuw verwerken van dié Verkooporderregel, dan was er geen te korrigeren Behoefterecord, en ontstond er als vanzelf weer een nieuwe Onjuiste Tegenboeking, wat vervolgens wéér impliceerde dat we de Elementaire Behoeftebasis opnieuw moesten opbouwen.
Inmiddels al weer een jaar of 7 geleden is er een nieuwe methode geïntroduceerd, waarbij bovenstaand probleem wordt geëlimineerd door weliswaar de Elementaire Behoeftebasis opnieuw op te bouwen bij het aanvangen van een Behoefterun, doch door dit 'lokaal' te doen, en niet o.b.v. een tabel op het netwerk, welke door andere gebruikers kan worden benaderd. Hierdoor zijn "Onjuiste Tegenboekingen" per definitie niet meer mogelijk.
Echter, nog steeds is het zo dat iedere Behoeftekreëerende of -dekkende funktie, de Elementaire Behoeftebasis op het netwerk bijwerkt, terwijl die data (in het geval dat e.e.a. bij het opstarten van de Behoefterun lokaal wordt opgebouwd) nergens meer door gebruikt wordt. Sterker nog, zodra een Elementaire Behoefterecord niet kan worden tegengeboekt, volgt bovenin het scherm een melding die 1 of 2 seconden blijft staan. Kortom, waar dit niet gebruikt wordt (of hoeft te worden) werkt het enkel vertragend.
Nb: In een praktijk situatie zijn LOBH tabellen aangetroffen met meer dan 1 GB aan data, terwijl die data nooit gebruikt werd.
M.i.v. deze Releasenote is er een Behoefterun Parameter opgenomen, waarmee kan worden ingesteld of de Elementaire Behoefte nog moet worden bijgewerkt op het Netwerk (feitelijk, of de LOBH tabel moet worden bijgewerkt).
Als deze rubriek met "N" wordt gevuld, hoeven er geen behoefterecords meer te worden geregistreerd, waardoor e.e.a. weer een klein stukje sneller wordt.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOBHOB | Omschrijving (nog) niet bekend | 15-12-2008 | 19-06-2009 |
| LOINBE | Initialiseren Bedrijf | 23-01-2009 | 19-06-2009 |
| LOINV | Omschrijving (nog) niet bekend | 05-06-2009 | 19-06-2009 |
| LOPABHWY | Wijzigen Parameters Behoefterun | 26-10-2005 | 19-06-2009 |
| LOPAIN | Initialiseren Parameters. | 18-06-2009 | 19-06-2009 |
