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?

Hallo @wil_peters,

Sorry voor late reactie.

Wij gebruiken een aantal van de *Incremental tabellen, onder andere TransactionlinesIncremental, SalesInvoiceLinesIncremental, SalesOrderLinesIncremental en AccountsIncremental . De ervaringen zijn wisselend; ene moment heb ik het gevoel dat het echt sneller gaat, andere moment duurt een download overdreven lang.

Wat ik jammer vind is dat het nog regelmatig voorkomt dat downloads na een aantal dagen goed draaien ineens een foutmelding geven. Zijn elke keer andere errors, maar daardoor kunnen we er nooit echt op vertrouwen dat een download weken achter elkaar elke nacht goed loopt.

Waar je wel rekening mee moet houden zijn wat inhoudelijke aanpassingen. Zo zal je wat meer tabellen aan elkaar moeten joinen omdat bepaalde velden niet meer beschikbaar zijn in de TransactionLinesIncremental die wel in de eerdere TransactionLines zaten (en zo nog een paar voorbeelden).

Over de juistheid van de data ben ik positief: de gegevens komen uiteraard wel overeen met wat er in Exact Online staat.

Daarnaast gebruiken wij ItemsIncremental niet meer omdat de voorraad van een artikel niet wordt meegegeven in die tabel, en die hebben we juist wel nodig, dus daarvoor was het advies weer over te schakelen naar ItemsBulk.

Wat voor mij het allerbelangrijkste (en vereiste) is, is dat de incremental tabellen een oplossing bieden voor de limieten die Exact gaat invoeren (vanaf 1 juli). Het moet natuurlijk gewoon mogelijk blijven zonder problemen elke nacht de gegevens te verversen voor een administratie met verkoopfacturen, wins&verlies gegevens en orders bijvoorbeeld.

Wellicht kunnen we wat kennis delen en/of elkaar ondersteunen. Uiteindelijk zitten we allemaal in hetzelfde ‘schuitje’ en willen we een betrouwbare en snelle download vanuit Exact Online kunnen draaien.

Fijne dag toegewenst!

Hallo @mvink,

Dank voor je uitgebreide antwoord. Ik herken de ervaringen die jullie hebben helemaal.

Wij doen niks met queries. Het gaat ons enkel om een dagelijkse update van een 15-tal tabellen in Exact Online, waaronder onder meer de tabellen die jij in jouw antwoord ook noemde. We verwerken deze data verder in ons eigen data-platform en voeden daarmee onze webapplicatie.

Ik moet helaas bekennen dat het dagelijks updaten van de betreffende tabellen in de afgelopen 3 jaar nooit voor een langere periode probleemloos is verlopen. Soms ging het enkele maanden goed, vervolgens ontstond er weer een onverwacht probleem waar we zonder hulp van Guido niet uitkwamen (vage foutmeldingen). Het aantal keren dat we ondersteuning hebben gevraagd, opnieuw een update hebben moeten installeren, etc. kan ik inmiddels niet meer tellen. De relatie met Guido is overigens prima, de ondersteuning is goed en ik gun hem het allerbeste, maar in termen van leverbetrouwbaarheid baart dit mijn organisatie ernstige zorgen.

We zijn onze oplossing afgelopen maanden aan het opschalen en worden vervolgens met deze “change” geconfronteerd. Een change die ons ertoe dwingt dat we deels weer terug moeten naar de tekentafel. We zullen dat andermaal voor lief (moeten) nemen, het punt is dat we het gevoel hebben dat daarmee de kous niet af is. Kortom, wat wij wensen is een (enigszins) stabiele situatie waarin dit onderdeel van onze oplossing gewoon draait zonder veel problemen.

Ik ga graag in op jouw aanbod om ervaringen te delen en elkaar te ondersteunen. Maar terwijl ik dit doe, voel ik ook enige frustratie dat dit op “ons gebruikers” wordt afgewenteld. Eigenlijk vind ik dat ook Invantive hier verantwoordelijkheid moet nemen. Je geeft aan dat bijvoorbeeld een aantal nieuwe joins moeten worden gedefinieerd. Waarom pakt Invantive dit niet op en maakt zij daarvoor niet een nieuwe view? Ik heb begin mei een ondersteuningssessie gepland met Guido en zal dit dan ook met hem bespreken.

Nogmaals, jouw reikende hand neem ik in dank aan. Voor persoonlijk contact kun je me altijd via bijv. LinkedIn contacteren: https://www.linkedin.com/in/wtbpeters/https://www.linkedin.com/in/wtbpeters/

Hartelijke groet,
Wil.

Fijn dat er onderling contact opgebouwd is. Dat kan ook via de Chat (het roeptoeter-ikoon) aan de linkerzijde.

De frustraties herken ik bij meer gebruikers van vooral Data Hub en Data Replicator met honderden of duizenden administraties.

Helaas worden 1 a 2 keer per jaar breaking changes doorgevoerd zonder vooraankondiging of terugkoppeling. Gezien het grote aantal installaties van Invantive producten on-premise en niet altijd zinvolle support kunnen we deze pijn niet volledig wegnemen. Na enkele maanden lost de Invantive SQL engine de meeste problemen weer onder water op als duidelijk geworden is wat er veranderd is. Dat oplossen kan niet altijd; de Exact Online servers geven vaak problemen niet altijd even duidelijk terug en foutcodes zijn afwezig.

Structurele verbeteringen in dit proces van herhalende issues op de Exact Online API’s worden niet verwacht. De kracht van Exact zit hem ook meer in de flexibiliteit van de organisatie en dat soms ook via creatieve wegen oplossingen gerealiseerd kunnen worden. Dat is weer anders dan bijvoorbeeld een SAP.

De huidige policy vanuit Exact is dat voor prioriteit op bugs nodig is aan te tonen dat een gebruiker afscheid zal nemen van Exact (“churn”). Dit is voor ons als bedrijf gezien onze beperkte marge en vrijwel nul omzet uit consultancy vaak niet zinvol. Helaas moeten we daarom ook de keuze maken zaken op zijn beloop te laten, waarbij vooral onze OEM-partners begin dit jaar veel problemen hebben ervaren. Dit probleem speelt bij alle ISV’s. Ik hoop dat t.z.t. weer een partner management proces op gang zal komen.

Er zijn bewust geen views in Invantive SQL gemaakt op de Exact sync API’s omdat het datamodel nu genormaliseerd is. Voor veel gebruikers is dit een goed moment om normalisatie te leren toepassen in Power BI en het voorkomt fouten in de uitkomsten. Technisch zijn er ook niet voor alle gerelateerde mastertabellen efficiënte manieren om de gegevens op te halen.

Ik hoop dat jullie onderling contact helpt bij het verdere en efficient gebruik. En blijf s.v.p. issues melden via de forums; we zullen blijven proberen waar mogelijk issues onder de motorkap glad te strijken.