Verzoek finetunen incremental tabellen Exact Online

Goedemorgen,

Wij zijn inmiddels bezig met het implementeren van de *incremental tabellen bij de Exact Online loads. Daarbij komen we wat merkwaardigheden tegen, en zaken die bij het gebruik van de reguliere tabellen wel goed gingen. Wellicht handig om van op de hoogte te zijn, ook om nog efficiënter te maken in volgende versies.

  • ItemsIncremental: hier ontbreekt ItemGroupCode en ItemGroupDescription. Hierdoor is alsnog join met ItemsRead nodig.
  • AccountsIncremental: hier ontbreekt de naam van de accountmanager, de naam van de provincie en de naam van het land. Deze velden zaten wel in de reguliere AccountsBulk.
  • TransactionlinesIncremental: De JournalDescription (dagboek) ontbreekt. Zat wel in de reguliere TransactionLinesBulk.
  • TransactionlinesIncremental: Het kenmerk AccountBalanceType is hier verdwenen wat aangeeft of het een resultaat- of een balansrekening is.
  • GLAccountsIncremental: Het veld TypesDescription is hier verdwenen. Zat wel in de reguliere GLAccountsBulk.

Kom nog wel meer tegen maar zal dat dan hier aanvullen.

Zijn overigens tot nu toe geen onoplosbare problemen want met joins kun je veel informatie alsnog boven tafel krijgen, alleen AccountManager moet ik nog zoeken.

Gr, Mike Vink

Ontbrekende (afgeleide) velden in Exact Online Incremental/Sync tabellen

Een terechte vraag en ook eentje die terugkomt zoals blijkt uit Kolom CostCenterDescription kan niet worden gevonden in TransactionLinesIncremental.

Er zijn geen plannen om deze kolommen toe te voegen aan de tabellen. Ze zijn bewust verwijderd, ook al staan ze om onduidelijke redenen wel bij de Sync API’s opgevoerd.

De oplossing is inderdaad om de benodigde veldwaardes te vinden door een join te leggen vanuit bijvoorbeeld ItemID in een transactietabel naar ItemsIncremental, en voor de artikelgroep vanuit ItemsIncremental naar ItemGroups. De laatste kent geen *Incremental versie, maar is dusdanig klein en statisch dat hij rustig 1x per dag volledig bijgewerkt kan worden.

Waarom afgeleide velden achterwege laten

De structuur van Exact Online is dat er een aantal servers met SQL Server zijn met daarop de tabellen. Er liggen relaties tussen tabellen, zoals bijvoorbeeld tussen artikelen en artikelgroepen.

De inhoud van de tabellen is logisch gepartitioneerd per divisie en een ondernemer staat op dezelfde server als zijn accountant zoals blijkt uit het veld DivisionMoveDate.

De *Incremental tabellen zijn gebaseerd op de Sync API’s en de Deleted API van Exact Online en verbergen veel logica onder de motorkap zoals bijvoorbeeld rekening houden met het omhangen van ondernemers naar een andere accountant, mogelijk op een andere SQL Server.

De Sync API’s vormen een 1-op-1 reflectie van de inhoud van de achterliggende tabel en - ongelukkigerwijze - ook met de dan geldende waarde van velden uit andere tabellen door foreign key relaties af te lopen. De sync API tabellen kunnen alleen gefilterd op oplopende Timestamp waarde opgevraagd worden.

Indien een gebruiker of een proces gegevens muteert in een tabel (toevoegen, veranderen of verwijderen), dan wordt (blijkbaar) in de tabel een veld gezet met de waarde van een monotoon stijgende teller, de Timestamp. Deze teller nummert per SQL Server onafhankelijk op.

De waarde van Timestamp geeft dus aan wanneer 1 of meerdere van de velden in de tabel gewijzigd zijn. Als de omschrijving van een artikel wijzigt, dan wijzigt ook de waarde van de Timestamp.

De waarde van de Timestamp in de tabel en de Sync API verandert niet als een waarde van een veld in een ander tabel verandert. Als bijvoorbeeld de omschrijving van een artikelgroep wijzigt, dan wijzigt niet de waarde van de Timestamp in de artikelentabel.

Daarom is het essentieel om de waardes van afgeleide velden uit de Sync API tabellen achterwege te laten. Anders hangt het van het gebruikte filter op Timestamp, het ophaalmoment en eventuele mutatiemomenten in de gerelateerde tabellen af welke waardes terugkomen voor afgeleide velden en zichtbaar worden in de cumulatie van wijzigingen in een *Incremental tabel.

De theoretische achtergrond van dit probleem wordt uitgebreid behandeld in de verzamelingenleer en meer specifiek in het proces van databasenormalisatie.

Dit is een van de reden waarom wij niet meteen op het gebruik van de *incremental zijn overgestapt. Hoewel het uiteindelijk wel zal moeten, gezien de problemen die we nu ondervinden. Mag ik vragen wat de ervaringen zijn met het gebruik van de *incremental tabellen? Loopt dit goed in termen van juistheid, tijdigheid en volledigheid?