Hoe moeten journaal balans verschillen in de kasverantwoording worden behandeld?

Vanwege een fout in RetailVista kan of kon het voorkomen dat een journaal dat gegenereerd wordt niet in balans is. Journalen hebben een debit en een credit kant, de totalen daarvan moeten altijd gelijk zijn. Als dat niet het geval is, dan is er inconsistentie in RetailVista ontstaan.

De achtergrond daarvan is een lastig te vinden storing die heel zelden optreedt en niet reproduceerbaar is. Er worden wat veiligheiden ingebouwd die dit probleem moeten voorkomen, uiteindelijk zal de storing zelf een keer gevonden wordt. Deel van de beveiliging is de controle bij het exporteren van een journaal naar de financiele administratie. Op dat moment wordt nu een controle gedaan of het journaal in balans is. Mocht dat niet zo zijn, dan wordt het journaal niet aangeboden aan de financiële administratie.

De achtergrond van dit probleem zijn verkeerde koppelingen in de kasverantwoording attributen tabel (CashDeclarationAttributes). Deze zullen door een ontwikkelaar handmatig gecontroleerd moeten worden. Elk attribuut record is door middel van het veld ParentCashDeclarationAttributeId gekoppeld aan de vorige kasverantwoording van diezelfde gebruiker of POS terminal (hangt af van instellingen hoe er gewerkt wordt met de kasverantwoording).

In RetailVista zelf is snel zichtbaar vanaf welke kasverantwoording de koppelingen fout gaan. De eindkas van de ene kasverantwoording sluit dan niet aan op de weergegeven beginkas van de volgende dag. Door die beide kolommen te selecteren in het kasverantwoording zoekscherm is dat goed zichtbaar.

Door de CashDeclarationAttribute records te sorteren per UserId of PosTerminalId is vrij snel visual zichtbaar in SQL Management Studio welke koppelingen verkeerd liggen. De te gebruiken query is de volgende:

select * From CashDeclarations where DeclarationNumber in (475,476)

select PosTerminalId, * From CashDeclarationAttributes where CashDeclarationId in(501,502)

order by 1,cashdeclarationid

In bovenstaande query worden eerst twee kasverantwoordingen gezocht waartussen een probleem geconstateerd is in de eindkas van de oudste kasverantwoording en de beginkas van de nieuwe kasverantwoording. Daarna worden van die kasverantwoording de records opgevraagd waarbij er gesorteerd wordt op PosTerminalId (of eventueel PosUserId in geval van kasverantwoording per gebruiker). Check nu de ParentCashDeclarationAttributeValue van kasverantwoording Id 502 met de ItemId van de vorige regel. Die moeten telkens gelijk zijn. Wanneer dat niet het geval is, update dan die regel. Voorbeeld:

update CashDeclarationAttributes set ParentCashDeclarationAttributeId=3949 where ItemId=3939

Als alle defecte links hersteld zijn moeten van de oudste kasverantwoording alle attributen een keer geopend en opgeslagen worden. Dan worden alle achterliggende kasverantwoordingen recursief doorgerekend en moeten alle saldi weer op elkaar aansluiten. Vanaf dat moment kan een nieuw journaal gegenereerd worden.