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.