Op zich lijkt me dit heel valide.
Echter zou het dan eigenlijk op een "hoger niveau" voor alle prijzen bijgehouden moeten worden (even de accountant versie erop loslaten...
)
Dat betekent dat je een redelijk uitgebreide tabel krijgt, en de vraag is hoe je die opbouwd.
Als je bv kijkt naar hoe het edit register artikelen werkt is dat niet ideaal opgebouwd. een systeem op basis van record welke naar bv excel kunnen op basis van een paar parameters (bv periode, user of verzin maar wat) is dan ideaal voor verslaglegging.
Maar dat geldt eigenlijk voor alle primaire stambestanden:
- artikel
- relatie
- debiteur
- crediteur
- prijzen
- ...
De vraag is hoe ver je wilt gaan met het loggen van dit soort zaken.
Een accountant zal n.l. altijd zeggen 100%
Het gevolg is echter wel dat als je nu in de database kijkt de 2 kernbestanden van Heart LOVM en ADBO zijn.
Deze groeien zeer snel t.o.v. de andere bestanden omdat dat de logistieke en financiele flow registratie is. Door allemaal mutatiebestanden toe te voegen word Heart wel steeds veeleisender mbt de hoeveelheid data.
(Dat is trouwens sinds de inzet van computers alleen maar een trend die zichzelf versterkt)
Bij AD zit er zo'n 1,3 GB aan data in de ADPF directory (1999 tot nu) waarvan ADBO 0.5 GB inneemt.
Als je dus ook op veel van de "logistieke" tabellen mutatiebestanden aan gaat maken zal Heart dus veel sneller groeien en moet je daar ook rekening mee houden mbt de inzet van data opslag en backup.
Daarnaast natuurlijk nog het financiele plaatje dat Heart voor al die functies mutatiebestanden moet maken en de programmatuur moet aanpassen.