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
Dit duurt echter lang; een kwartier voor 500.000 regels is gebruikelijk.
Vanaf release 24.0.182 kan dit in enkele honderden milliseconden via een query op RowCounts zoals:
select count(*)
from rowcounts@eol
where table_name = 'SyncTransactionLines'
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 (vanaf release 24.0.182)
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.
Het snelste alternatief is een query op RowCounts zoals beschreven in Sneller schatten aantal rijen op Exact Online met de tabel "RowCounts".
Een administratie met 15 miljoen regels kan dan binnen enkele seconden geteld worden.
Als tellen niet lukt (voor release 24.0.182)
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. Gesplitst per boekjaar wordt het dan bijvoorbeeld:
select ReportingYear
, sum(count) count
from ReportingBalance
group
by ReportingYear
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
, fail_on_error
)
select url
, orig_system_group
--
-- Vervang door false als je niet overal rechten op hebt en true
-- als je dat wel zeker hebt.
-- Tabellen waar de huidige Exact Online gebruiker geen rechten
-- op heeft worden bij false stilletjes overgeslagen.
--
, false
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>