Sinds het begin van Profit-Fin is er een mogelijkheid om bij een Financiële Interface aan te geven dat Batchboekingen voor deze Interface gecomprimeerd moeten worden. Het voor ogen liggende doel van die funktionaliteit, was dat als we in één maand 1000 Produktieorders hebben, waarbij ieder afgeboekt kilogrammetje leidt tot een financiële mutatie, dit er wel eens heel erg veel konden worden. Comprimeren zou dit moeten samenvoegen tot één boeking met daarin het totaalsaldo van alle Batchboekingen die in een run worden doorgeboekt.
Uiteindelijk wordt die funktionaliteit niet veel gebruikt, omdat ze funktioneel in de meeste gevallen niet gebruikt kan worden.
Neem bijv. als voorbeeld het Genereren van een Uitgaande Faktuur. O.b.v. de Verkooporders, Raaplijsten, Geleverde Charges, kortingen, DKK's, Emballage etc. wordt een Faktuur samengesteld, welke uiteindelijk ook in de financiële administratie terecht zal komen. Echter, we kunnen ook een Faktuur laten vervallen. Deze zet de Verkooporderregels weer terug in een stand 'moet nog gefaktureerd worden'. Als de Faktuur geen bestaansrecht meer heeft, dan de boeking ook niet. Deze wordt derhalve verwijderd! Zouden de Batchboekingen van de Faktuurrun nu gecomprimeerd zijn, dan bestaat de afzonderlijke boeking van die ene Faktuur niet meer, en kunnen we die er ook niet uitgooien.
Het alternatief voor het verwijderen van de boeking, zou "het genereren van een nieuwe boeking zijn", dit zou echter een nieuwe financiële interface vereisen met aansturende koding. Gezien het prijskaartje is daar niet voor gekozen.
Inmiddels bevat het pakket her en der veel meer mogelijkheden om iets wat geboekt is weer ongedaan te kunnen maken. Een Goederen Ontvangst die onterecht geboekt is, kan weer verwijderd wordt. Een levering kan ongedaan gemaakt worden etc.
Alvorens op Interface niveau te kiezen voor "Comprimeren" dient U zichzelf goed te vergewissen dat alle korrekties op eerdere boekingen niet deze eerder gemaakte boekingen willen verwijderen. Zo toch, dan is het advies niet te comprimeren.
Overigens zal comprimeren op Interfaceniveau de gelijke boekingen tijdens Doorboeken Batchboekingen comprimeren. En, omwille van Record Lock redenen, worden er maximaal een paar honderd Batchboekingen tegelijk doorgeboekt. Comprimeren leidt dat ook niet tot één boeking per maand, maar één boeking per set per hoeveel Batchboekingen er tegelijk in behandeling worden genomen tijdens doorboeken.
Toch is inmiddels een situatie ontstaan bij een klant dat 80% van het boekingenbestand uit boekingen bestaat van één Journaalpostdefinitie én tevens die tabel zijn systeemgrenzen bereikt heeft.
Het verwijderen van boekingen uit Afgesloten Perioden mag dan wel een optie zijn als we het over administraties hebben die meer dan 5 jaar oud zijn, maar het zou niet handig zijn als we meer recente data 'historisch' moeten gaan maken en niet meer direkt beschikbaar hebben.
Via een nieuw ontwikkelde run is het nu mogelijk om achteraf (bijv. in Afgesloten Perioden) alle boekingen van een op te geven Journaalpostdefinitie te comprimeren. De afzonderlijke mutaties worden overgeheveld naar een historisch bestand in de directory FOXADADPFCOMPRIMADBOxxxx en worden per gebruiker gecomprimeerd tot één boeking per periode.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| ADBHOI | Omschrijving (nog) niet bekend | 14-10-2009 | 10-11-2009 |
| ADBOOS | Omschrijving (nog) niet bekend | 09-11-2009 | 10-11-2009 |
| ADJH | Journaalpost Definities | 26-10-2005 | 09-11-2009 |
| ADJHBOCP | Omschrijving (nog) niet bekend | - - | 09-11-2009 |
| ADOBOS | Omschrijving (nog) niet bekend | 09-11-2009 | 10-11-2009 |
| LOFROS | Omschrijving (nog) niet bekend | 17-09-2009 | 10-11-2009 |
