Schatten omvang Exact Online administratie

Go to English version

Met het geleidelijk verlagen van het aantal API-calls per dag naar 5.000 per Exact Online administratie per applicatie is het vaak handig om een grove schatting te maken van de omvang van een administratie.

Met deze schatting kunnen applicaties optimaal afgestemd worden tegen zo laag mogelijke (consultancy) kosten. Ook voor koppelingen met Exact Online blijven de kosten laag terwijl het beslag op de Exact Online API zo klein mogelijk gehouden wordt. Het daadwerkelijke gebruik kan gemeten worden zoals beschreven in Analyseer Exact Online API gebruik met `RateLimits` of `SystemPartitions`.

Een goede indicator voor omvang is het aantal boekstukregels. Op Exact Online is het niet ongebruikelijk dat een administratie 5.000 boekstukregels heeft, maar ook niet raar als het er 10 miljoen zijn in een administratie. De architectuur van Exact Online is dusdanig dat zelfs enorme administraties vlot toegankelijk zijn. Hoogstens de toegang via de webschermen en de API’s kan moeizaam zijn afhankelijk in hoeverre die geoptimaliseerd zijn voor grote hoeveelheden transacties.

Alle hieronder beschreven technieken voor het schatten van de omvang van een Exact Online omgeving werken zoals voor Exact Online Accountancy, Exact Online Boekhouden als de Exact Online ERP-modules zoals handel en productie. De technieken kunnen gebruikt worden met een willekeurige Exact Online add-on van Invantive met SQL-ondersteuning. De cijfers kunnen net zo makkelijk voor meerdere administraties geteld worden als per individuele administratie. Gebruik het use SQL-statement of de administratiekiezer in het menu om meerdere administraties te selecteren.

De omvang kan gebruikt worden in combinatie met de leeftijd van een administratie om een voorspelling te maken van de omvang in de toekomst. Eventueel kan hierbij de huidige omvang nog gecorrigeerd worden voor het initieel geladen aantal rijen uit een conversie. Rijen uit een conversie is vaak te herkennen aan een groot aantal rijen met een aanmaakdatum binnen de bijvoorbeeld eerste drie maanden na de aanmaakdatum van de administratie.

Met vragen naar een eerste schatting

Een eerste startpunt voor de bepaling of een administratie veel boekingen heeft gaat via het stellen van vragen:

  • Is het een interne administratie onder een Exact Online accountancy abonnement? Zo ja, dan klein.
  • Is het een werkmaatschappij? Zo nee, dan klein.
  • Is de jaaromzet meer of minder dan 3 miljoen Euro?
  • Is het een bedrijf dat kapitaalgoederen levert met omzet of vooral aan andere bedrijven? Zo ja, dan klein tot middelgroot, afhankelijk van de jaaromzet.
  • Is het een bedrijf dat consumptieartikelen levert of vooral aan consumenten? Zo ja, dan middelgroot tot groot, afhankelijk van de jaaromzet.

In de praktijk blijken vooral webshops met grote volumes goedkope consumentenproducten en veel Exact Online gebruikers een erg grote administratie te hebben. Veel webshops zijn sinds de start van Corona enorm gegroeid. En de omzet en betalingen worden vaak met een app niet-geconsolideerd doorgeboekt, waardoor elke bestelling van een paar euro al leidt tot pakweg 10 boekingsregels.

De Exact Online sync API’s bieden mogelijkheden om de belasting aan de Exact Online-zijde pro-rato te relateren aan de dagomzet, terwijl de traditionele API’s qua snelheid veelal pro-rato zijn aan de cumulatieve omzet over de jaren.

Verregaand versimpeld dus:

  • bij een verdubbeling van de jaaromzet, verdubbelt het aantal calls voor sync API’s,
  • bij de traditionele Exact Online API’s verdubbelt het aantal call bij een verdubbeling van de levensduur van de administratie.

De *Incremental-tabellen van de Invantive SQL Exact Online driver bieden een betrouwbare en vlotte manier om te werken met complete en actuele cijfers, en toch de belasting op de beschikbare Exact Online API-capaciteit laag te houden.

Alles tellen

Een accurate benadering voor het bepalen van de omvang is het tellen van de rijen. Aangezien Exact Online een gemengd grootboek heeft, is een telling op TransactionLinesIncremental een goede indicator:

select count(*)
from   TransactionLinesIncremental

We rekenen meestal met een opslagcapaciteit van 2 KB per boekstukregel. Deze query kan ook nog eenvoudig uitgesplitst worden op soort boeking, zoals “Verkoop” door te groeperen op soort boeking.

Soms is het nodig om ook specifiek de omvang van het artikelbestand te tellen omdat men veel slapende artikelen heeft die wel meegesleept worden of de documenten te tellen omdat men Exact vooral gebruikt als DMS:

select count(*)
from   ItemsIncremental

en

select count(*)
from   DocumentsIncremental

Als tellen niet lukt

Soms is er geen API-ruimte meer om de aantallen te tellen doordat Exact Online nog maar 5.000 API-calls toestaat per dag. Een nieuwe boekhouding met 15 miljoen regels kan gewoon niet in 1 dag geteld worden.

Er zijn echter goede alternatieven om de omvang sneller af te schatten.

Omvang Exact Online schatten met ReportingBalance

Als er weinig gewerkt wordt met kostenplaatsen en kostendrager, dan kan de tabel ReportingBalance gebruikt worden om vlot een schatting te maken van de aantallen boekingen. Normaliter raden we het gebruik van ReportingBalance af ten gunste van BalanceLinesPerPeriod omdat hij erg langzaam is en veel API-calls vraagt, vooral als er gewerkt wordt met kostenplaatsen en kostendragers. Maar ReportingBalance laat wel de aantallen boekingen in een combinatie van grootboeknummer, boekingssoort, periode en administratie zien.

De volgende SQL-query laat een vrij nauwkeurige indicatie zien van het aantal boekstukregels in de Exact Online geselecteerde administraties:

select divisionlabel
,      sum(Count)
from   reportingbalance@eol
group
by     divisionlabel

Het is niet vlot gelukt om een exacte match te vinden met het aantal rijen in TransactionLinesIncremental (ook rekening houdend met speciale regelnummers), maar de afwijking is kleiner dan 1%.

Deze query kan ook nog eenvoudig uitgesplitst worden op soort boeking, zoals “Verkoop” door te groeperen op soort boeking.

Supersnel omvang schatten via $count

Het is ook mogelijk om in enkele seconden voor veel tabellen de omvang op te vragen door gebruik te maken van de $count optie in de OData3-standaard die Exact Online grotendeels ondersteunt.

Het gebruik van $count hiervan is niet mogelijk op een aantal API’s en kan niet gecombineerd worden met filters onder versie 3 van OData, maar het is wel supersnel.

Met de onderstaande SQL op Exact kan meestal binnen een minuut de omvang bepaald worden:

--
-- Combinatie van alle administraties en (in dit voorbeeld) alle
-- Sync API tabellen van Exact Online.
--
create or replace table countqueries@inmemorystorage
as
select ste.name
,      sdn.label
,      sdn.code
,      replace(ODATA_SERVICE_URL_FOR_SELECT, '{division}', sdn.code) || '/$count'
       url
,      ste.name || ' @ ' || sdn.label
       orig_system_group
from   SystemDivisions@eol sdn
join   SYSTEMTABLES@DataDictionary ste
on     ste.PROVIDER_NAME = 'ExactOnlineAll'
and    ste.CATALOG       = 'ExactOnlineREST'
and    ste.schema        = 'Sync'

--
-- Stuur de API-verzoeken zonder verdere interpretatie door als een
-- "Native Scalar Request". De resultaten worden vastgelegd in
-- dezelfde tabel "NativePlatformScalarRequest".
--
-- Er wordt gebruik gemaakt van XML-output. JSON wordt verkregen
-- door Content-Type in te stellen.
--
insert into exactonlinerest..nativeplatformscalarrequests@eol
( url
, orig_system_group
)
select url
,      orig_system_group
from   COUNTQUERIES@InMemoryStorage

--
-- Per tabel en administratie het aantal rijen.
--
select orig_system_group
,      RESULT_TEXT
from   exactonlinerest..NATIVEPLATFORMSCALARREQUESTS@eol
where  SUCCESSFUL = 'Y'
and    orig_system_group is not null

Het komt ook voor dat beheerders geen rechten uitdelen aan gebruikers. Deze zijn te herkennen aan een Forbidden / 403 error als resultaat van de query:

select orig_system_group
,      RESULT_TEXT
from   exactonlinerest..NATIVEPLATFORMSCALARREQUESTS@eol
where  SUCCESSFUL = 'N'
and    orig_system_group is not null

zoals:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> 
  <code></code>
  <message xml:lang="">Forbidden</message>
</error>