use 123456
set use-http-disk-cache false
set use-http-memory-cache false
select /*+ ods(false) */ *
from salesinvoicelinesbulk
where invoiceid = 'd89e0e6d-bb28-41e6-b368-2643545523c9'
select /*+ ods(false) */ *
from salesinvoicelinesincremental
where invoiceid = 'd89e0e6d-bb28-41e6-b368-2643545523c9'
De eerste query levert 1 record op met bedrag AmountDC zeg 500 en LineNumber 1.
De tweede query levert drie records op met bedragen, respectievelijk, zeg 600, -500 en -100 bij regelnummers 0, 1 en 9999.
Bij de tweede query zijn de timestamps drie opeenvolgende nummers: 11386558735, 11386558736, 11386558737, dus de drie records zijn direct na elkaar aangemaakt. Ook de waarde in Created is bij alle drie gelijk (het veld Created bestaat niet in SalesInvoiceLinesBulk).
Waarom levert de incrementale tabel (op basis van de Sync API) drie regels op en de bulk API maar één? De Exact sync API is toch er op gebaseerd dat hij op slimmere wijze dezelfde informatie teruggeeft?
Het idee van de Exact Online sync API’s is inderdaad dat ze exact dezelfde informatie teruggeven als de er aan gerelateerde API’s, maar dan met veel minder API calls.
Momenteel zitten er in de sync API’s van Exact nog een aantal ontwerp- en/of documentatiefouten. Om die reden is het niet altijd mogelijk om de oorspronkelijke API’s 1-op-1 te vervangen door de *Incremental tabellen gebaseerd op de Sync API’s.
In dit voorbeeld worden twee bijzonderheden aangehaald die naar verwachting alleen optreden bij SalesInvoiceLinesIncremental. Het lijkt er op dat stukjes informatie over verschillen tussen de Sales Invoices API en de Sync API van Sales Invoices niet gedocumenteerd zijn.
De reguliere API’s voor verkoopfactuurregels onderdrukken blijkbaar de speciale regels. Bij het gebruik van de incrementele tabellen op Exact Online administraties dient de SQL query die zelf te onderdrukken of juist te gebruiken indien dat beter is.
Verkeerd Teken bij Bedragen
Het teken van de bedragen staat andersom als bij de oorspronkelijke tabel. Hierdoor krijgt omzet hetzelfde teken als bij TransactionLinesBulk met het flauw grapje: “omzet is vies” makkelijk te onthouden. Mogelijk dat men in de oorspronkelijke tabel bij elke sales invoice het teken omdraaide om het logischer te maken, terwijl het intern bij Exact wel als een negatief bedrag geregistreerd werd.
Deze vraag is automatisch gesloten na 2 weken inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.
Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.