Bij het gebruik van formules met saldo-informatie zoals I_EOL_BAL_PDE zie ik soms in het scherm Sessie I/O’s dat er meer Exact Online-administraties uitgelezen worden qua tabel GLSchemes dan gebruikt in de Excel-formules.
Dit probleem treedt op sinds de overgang van versie 22.0.341 naar 22.0.612.
Dit heeft impact op de facturatie en de prestaties.
Hoe kan dit gecorrigeerd worden?
Er is een analyse uitgevoerd. Het blijkt dat als alle administraties geselecteerd zijn (kies “Alle” in het pie chart menu in het Invantive Control-lint), de volgende formules naar verwachting alle administraties benaderen ook al moeten ze maar 1 Exact Online-administratie uitlezen:
I_EOL_GL_SCHEME_CODEI_EOL_GL_SCHEME_DESCRIPTIONI_EOL_GL_SCHEME_IS_MAINI_EOL_TXN_AMOUNT_DCI_EOL_TXN_AMOUNT_FCI_EOL_TXN_QUANTITYAchterliggende oorzaak is het gebruik van een query zoals:
select *
from ExactOnlineREST..GLSchemes
where division = 123456
De tabellen die te vaak benaderd kunnen worden zijn:
ExactOnlineREST..GLSchemesExactOnlineREST..TransactionLinesExactOnlineREST..TransactionLinesBulkDeze query zelf zal alleen de administratie met divisiecode 123456 benaderen zoals beschreven in Betere prestaties op Power BI voor Exact Online accountants.
Voor performancedoeleinden wordt in Invantive Control for Excel de interpretatie door de SQL-engine overgeslagen en direct met zogenaamde QueryObjects gewerkt. In versies tot 22.0.690 werd hierbij qua casing een andere schrijfwijze van division gehanteerd dan dat de optimalisatie verwachtte. De SQL-engine herschrijft automatisch naar de juiste schrijfwijze, maar de optimalisatieverbetering via alleen QueryObject-benadering doet dit niet. Aangezien de Exact Online-SQL driver werkt met niet-hoofdlettergevoelige objectnamen is deze matching hoofdletterongevoelig gemaakt.
Het gedrag van versies voor 22.0.690 heeft niet geleidt tot foute uitkomsten omdat de filtering op divisiecode ook plaatsvindt aan de client-side.
Het gedrag van versies voor 22.0.690 leidt echter wel voor uitsluitend de genoemde formules tot soms significant slechtere performance (in de oorspronkelijke casus koste het circa 30 seconden extra per verversing na aanmelden omdat circa 800 administraties te veel uitgelezen werden). De prestatieverslechtering zal vooral merkbaar zijn bij het gebruik van de I_EOL_TXN...-formules, die veel informatie verwerken. De genoemde 30 seconden blijken in de praktijk binnen de frustratietolerantiedrempel van gebruikers te liggen. De snelheid van andere (meest intensief gebruikte) formules zoals I_BAL_PDE... is niet veranderd door dit gedrag.
Daarnaast leidt dit gedrag tot onterechte hoge facturen.
Er zal een analyse gemaakt worden welke facturen op welke wijze bijgesteld moeten worden en een creditering hiervoor volgt. Dit speelt uitsluitend bij accountancy-abonnementen. Ondernemers-abonnementen hebben een hoge limiet van 100 administraties inbegrepen in de prijs en weinig ondernemers hebben meer dan 100 administraties in combinatie met Invantive Control for Excel.
Alle accountants die een verkeerde versie van Invantive Control gebruiken zullen gevraagd worden te upgraden.
Bovengenoemd probleem speelt uitsluitend voor Invantive Control for Excel, aangezien het probleem in code zat specifiek voor Invantive Control-formules. Andere producten zoals de Exact Online Power BI-connector of Get My Report gebruiken deze logica niet.