We halen via Invantive Cloud de Twinfield-view GeneralLedgerDetailsV3 op. Hier zit een kolom in met costcenter_id en costcenter_name. Deze zijn allebei leeg.
De klant geeft aan wel degelijk kostenplaatsen te vullen in Twinfield.
Kijken we naar het verkeerde veld? Of zijn deze in de view van Invantive gewoon niet gevuld?
Is het mogelijk om een (geanonimiseerde) schermafdruk toe te voegen van het gehele Twinfield-scherm waarin de kostenplaats zichtbaar is, inclusief kop/regels?
En dan de identificerende kolommen, de genoemde velden (vermoedelijk wordt costcenter bedoeld i.p.v. costcenter_id) en alle dimensiekolommen zoals die via GeneralLedgerDetailsV3 naar voren komen voor de desbetreffende transactie, en het bijbehorende gebruikte SQL-statement met where-clause?
Na onderzoek hebben we achterhaald wat er gebeurd. Ik ken Twinfield van de voorkant niet voldoende om het qua werkproces te verklaren, maar aan de achterkant zit het als volgt:
Voor deze klant worden de kostenplaatsen niet gevuld in het veld costcenter, maar in het veld fin_trs_line_dim2.
Die is in de tabellen wel gevuld en komen overeen met wat de klant als kostenplaats vult.
Daarmee is ons probleem opgelost. Maar begrijp ik het nog niet helemaal. Wellicht is er een Twinfield kenner of iemand met meer boekhoudkundige kennis dan ik die kan verklaren waarom een klant er van overtuigd is kostenplaatsen in te voeren maar dit in een ander (vrij?) veld terecht komt.
Twinfield heeft ooit bedacht dat ze net zoals Oracle Apps of CODA werken met dimensies. Een of een paar van de dimensies is/zijn dan “balancing segment(s)”, en de rest detailleringen. Zo uit hoofd is dim1 op Twinfield het grootboekrekeningnummer en de andere dimensies zijn voor zover ik weet meestal hetzelfde per sub. Alhoewel de basis flexibel bedacht is, is de flexibiliteit van dimensies op Twinfield beperkt. Op andere pakketten kun je via dimensies veel zaken instellen, zoals welke combinaties zijn geldig, welke dimensie bevat wat (klant, project, kostenplaats, kostendrager, regio, product), etc.
Voor Twinfield is meer informatie te vinden in:
De verwarring over de twee velden vindt mogelijk haar oorzaak doordat de API-documentatie van Twinfield nogal wat flexibiliteit bevat, die in de praktijk niet of maar incidenteel gebruikt wordt. Dit is vergelijkbaar met de Exact Online XML-API’s die in dezelfde periode geconstitueerd zijn; ook hier bestaan veldcombinaties volgens de metadata die in de praktijk nooit met een waarde voorkomen.
In het kader van volledigheid wordt er bij Invantive-drivers er altijd voor gekozen om de theoretische mogelijkheid te volgen. Dit betekent alle enigszins betrouwbare API’s, ook al is doel onduidelijk, en alle velden, ook al is onduidelijk wat ze betekenen. Enkel om redenen zoals herleidbaarheid, volledigheid, betrouwbaarheid e.d. worden soms velden achterwege gelaten. Een goed voorbeeld is de recente verwijdering van IsMainContact uit de *Incremental-tabellen; zie PowerBI - EOL: ContactsIncremental: DataFormat.Error: We expected a property 'IsMainContact', but the OData service omitted it from the response data.
Dit topic is 7 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.