Welke gebruiker dat is kom je niet achter...
In topic
http://ha1.heartprofit.nl/profit/index.php?topic=23271.0 heb ik al eens een poging gedaan dit uit te leggen, maar dat was voor niet iedereen helemaal duidelijk, derhalve misschien nog een, beetje technisch verhaal:
Kwa locking (ervoor zorgen dat niet 2 gebruikers tegelijk hetzelfde gegeven kunnen muteren) hebben we intern 3 mogelijkheden:
a. recordlocking
b. filelocking
c. multi-recordlocking
Binnen Profit gebruiken we standaard methode a. en voor enkele grote zaken (Reorganiseren, Jaarafsluiting, opschonen bestanden e.d.) ook methode b. Filelocking zorgt er echter voor dat er maar één Gebruiker tegelijk in een tabel kan zitten. Dat is natuurlijk nooit handig voor "Doorboeken Batchboekingen", immers, terwijl jij aan het doorboeken bent, kan geen enkele andere Gebruiker nieuwe Batchboekingen beschikbaarstellen.
Technisch gezien bestaat er nog de 3e mogelijkheid, en wel "multi-recordlocking". Daarmee ben je in staat om in één tabel meerdere records tegelijkertijd te locken. De funktionaliteit heet "Doorboeken Batchboekingen", maar eigenlijk is hetgeen je daar ziet "Batchboekingsregels". Een Journaalpost kan al snel uit 5 regels bestaan, en "multi recordlocking" stelt ons in staat om deze 5 records tegelijkertijd gelockt te houden (om ze vervolgens te kunnen doorboeken, en daarna weer te verwijderen).
Iedere lock die jij doet, kost "performance". Niet alleen van jouw werkstation, maar ook op de Server. Op Novell Servers diende je ook instellingen te doen inzake het "Maximum Recordlocks per Connection" maar ook v.w.b. het maximum totaal aantal recordlocks over alle gebruikers heen. De eerste stond normaliter ingesteld op 500 recordlocks per Connection (en met 50 Gebruikers zat het totaal ergens rond de 25.000).
Maar ja... nu ga je Batchboekingen doorboeken, en je hebt er een hele waslijst met 20.000 boekingen van de hele maand staan. Doen we dan aan multi recordlocking, dan heeft één gebruiker al 20.000 records gelockt. Nee, eigenlijk nog veel meer, immers, multi recordlocking gaat over alle tabellen heen, en ook alles wat in andere tabellen (Boekingen, Grootboekrekeningen, Journaalpostdefinitieregels) gelockt zal worden blijft gelockt). Niet te moeilijk doen... het doorboeken van 20.000 Batchboekingen zou er al voor zorgen dat je Server over zijn nek gaat.
Derhalve passen wij een kombinatie toe. Daarbij wordt o.a. de Identifikatie van de Journaalpost opgenomen als "wordt doorgeboekt door een andere Gebruiker" zodra deze wordt doorgeboekt. Hoewel er volgens mij sowieso ergens in een helptekst vermeldt staat dat je niet met meerdere personen tegelijk Batchboekingen (in bulk) moet gaan doorboeken, is het ervoor gemaakt dat als een 2e gebruiker een Batchboeking gaat doorboeken en de sleutelgegevens van die Journaalpost al als "doorgeboekt" bekend zijn, deze boeking als vanzelf wordt overgeslagen. Bedoeld dus om te voorkomen dat een boeking door 2 gebruikers tegelijk wordt doorbelast, en dubbel in het grootboek terecht komt).
Het gaat echter "fout" als iemand Batchboekingen gaat doorboeken, de betreffende Journaalpost als "wordt doorgeboekt" wordt geregistreerd, en vervolgens de gebruiker om e.o.a. reden zijn proces niet kan afmaken. Dat kan al bijv. liggen aan jullie netwerkproblemen. Hoe dan ook, hij-/zij kilt zijn sessie, start opnieuw op, wil de boeking opnieuw doorboeken, maar helaas... die sleutelgegevens van die boeking staan al geregistreerd als zijnde doorgeboekt, en dus krijgt ze deze melding.
In het andere topic is er op zich niet zo'n fout opgetreden maar gaat het fout omdat eerst een boeking met bepaalde gegevens wordt geďmporteerd, deze wordt doorgeboekt naar het grootboek (sleutelgegevens van die boeking worden geregistreerd als zijnde doorgeboekt), na het doorboeken wordt de Batchboeking netjes verwijderd, en vervolgens gaan we die boeking nóg een keer importeren met precies dezelfde gegevens (datum-/tijd). Ook dan zal tijdens het doorboeken worden gekonstateerd dat er al een boeking is doorbelast met deze gegevens, en blokkeert het systeem.
Wat moet je nu doen?
1. Bepaal om welke Batchboeking (Journaalpost) het gaat (zie de data in je ADBOTV5 scherm, waarbij zoals in je schermprint alle rubrieken gevuld moeten zijn om je ervan te vergewissen dat er maar één Batchboeking wordt doorgeboekt).
2. Er zál iets fout zijn gegaan (anders had je deze situatie niet), maar, het kan fout zijn gelopen tijdens het aanmaken van de boekingen in het grootboek (zodat die nu half af zijn), het kan ook fout zijn gelopen nádat alle boekingsregels waren doorgeboekt, en tijdens het verwijderen van de (inmiddels) doorgeboekte Batchboekingen. Afhankelijk van die situatie zul je andere aktie moeten ondernemen.
Bekijk-/beoordeel dus de Batchboekingsregels die je bij Raadplegen Batchboekingen ziet, maar kontroleer ook of je in het Grootboek (Raadplegen Boekingen op datum-/tijd) deze Journaalpost tegenkomt (en of ze volledig is).
3. Afhankelijk van het resultaat van 2 zul je moeten beoordelen welke oplossing makkelijker is. Als bijv. de boeking al goed in het grootboek staat, kun je beter volstaan om niets opnieuw door te boeken, maar zelf de Batchboekingsregels handmatig te verwijderen (zie helptekst ADBOBBRA). Staat de boeking half of helemaal niet in het Grootboek, verwijder dan (indien van toepassing) die boeking en daarna zullen we de Batchboeking alsnog opnieuw moeten doorboeken.
4. In menu Hmenu-7-1-2-8-5 vind je een tool waarmee je aan alle nog openstaande Batchboekingsregels een status kunt toekennen "boek toch maar door" kunt toekennen. Nadat je die run hebt uitgevoerd, kun je de Batchboeking alsnog opnieuw doorboeken (maar, dus wel eerst ervoor zorgen er niets van een vorige doorboeking staat (zie #3) anders heb je je boeking alsnog dubbel in het grootboek staan).
