Unknown identifier 'COMPANY_CODE

Wanneer ik een request in de UniversalSQL-editor uitvoer:

select *
from   VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions
       ( COMPANY_CODE = 'compcode'
       )

krijg ik de volgende foutmelding:

itgensql001
Unknown identifier ‘COMPANY_CODE’.
There are no similar identifiers.

Terwijl de tabel juist om dit onderdeel lijkt te vragen:

select *
from   VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions
       ( :COMPANY_CODE                  -- Partition to retrieve data from.
       , :branch                        -- The branch CD
       , :ledger                        -- Mandatory. The ledger in which you want to view the account balances.
       , :fromPeriod                    -- The financial period that begins the date range of the batches you want to view. Format YYYYPP
       , :toPeriod                      -- The financial period that ends the date range of the batches you want to view. Format YYYYPP
       , :account                       -- The account CD for which you want to view activities in the selected financial period.
       , :subaccountId                  -- The Subaccount
       , :fromDate                      -- The first date of the interval within the period. Format YYYY-MM-DD
       , :toDate                        -- The last date of the interval within the selected period. Format YYYY-MM-DD
       , :includeUnposted               -- Checkmark indicating if unposted batches are included.
       , :includeUnreleased             -- Checkmark indicating if unreleased (balanced) batches are included.
       , :skipRecords                   -- This field has been deprecated and will be removed in future versions. Use pagenumber and pagesize for pagination purposes. Pagenumber and pagesize does not work with NumberToRead and SkipRecords.
       , :numberToRead                  -- This field has been deprecated and will be removed in future versions. Use pagenumber and pagesize for pagination purposes. Pagenumber and pagesize does not work with NumberToRead and SkipRecords.
       , :lastModifiedDateTime          -- This value, generated by the system, indicates the last time the record was modified. Use it to retrieve all records that have been modified since that time, up to the present.  Accepted format: * ```yyyy-MM-dd``` * ```yyyy-MM-dd HH:mm:ss``` * ```yyyy-MM-dd HH:mm:ss.FFF``` * ```yyyy-MM-ddTHH:mm:ss``` * ```yyyy-MM-ddTHH:mm:ss.FFF```  _Note:_ __LastModifiedDateTime__ and __LastModifiedDateTimeCondition__ are __mutually inclusive__.
       , :lastModifiedDateTimeCondition -- This value represents the condition to be applied when retrieving records.  Accepted values (without the single quotes): * '>' for greater than * '<' for less than * '>=' for greater than or equal * '<=' for less than or equal  _Note:_ __LastModifiedDateTime__ and __LastModifiedDateTimeCondition__ are __mutually inclusive__.
       , :expandAccountInfo             -- By default, if no value is provided, False and the account information will include only Number, Description, Type and GlConsolAccountCD. If True, each transaction returned will include extended information about account.
       , :expandBranchInfo              -- By default, if no value is provided, False and branch information will include only branch number. If True, each transaction returned will include extended information about Branch (number and name).
       , :includeTransactionBalance     -- By default, if no value is provided, False and the transactions returned will not include their balances (fields BegBalance, EndingBalance, CurrBegBalance, CurrEndingBalance) If True, each transaction returned will include its balance.
       , :pageNumber                    -- Pagination parameter. Page number.
       , :pageSize                      -- Pagination parameter. Number of items to be collected. Please use a page size lower or equal to the allowed max page size which is returned as part of the metadata information. If requested page size is greater than allowed max page size, request will be limited to max page size.
       , :erp-api-background            -- If a URL value is provided, then API endpoint will be queued and executed in background. When the execution of the background operation is finished, the system will POST the response to the specified URL. The endpoint itself responds in this case with a 202-Accepted status and a reference to a state document for the background operation.
       )

Als ik gebruik maak van unnamed paremeters doet hij het wel maar hiermee kan ik niet bereiken wat ik wil bereiken (oftewel niet alle parameters invullen).

Hoe moet ik het request uitvoeren om wel resultaat te krijgen?

Gebruikt u het oude VNI als verbinding naar Visma.net of Visma Connect?

De settings in mijn container zeggen use-VNI=False dus ik vermoed Visma Connect.

Visma.net is recent overgegaan van VNI (Visma.net Interface) naar Visma Connect. Een van de nadelen is dat nog maar maximaal 1 company benaderd kan worden (zie ook Migrating from Visma.net ERP Integrations (VNI) to Visma Connect for Visma.net).

Het veld COMPANY_CODE is bewust aanwezig gelaten in de rijen, zodat het gemakkelijker mogelijk is om - ondanks de beperkingen - net zoals bij SnelStart meerdere companies te consolideren zoals beschreven in Data uit meerdere SnelStart-administraties real-time consolideren.

Echter, per abuis is het veld COMPANY_CODE bij het gebruik van Visma Connect nog aanwezig gebleven als tabelfunctieparameter. Dit had enkel getoond mogen worden bij een koppeling op basis van VNI.

In de volgende release zal de tabelfunctieparameter COMPANY_CODE verdwenen zijn uit de tabellen. Enkel de uitvoerkolom zal nog aanwezig zijn. De beschikbaarheid van deze release verloopt zoals beschreven in Releasefrequentie Invantive Cloud.

Voor nu is het advies om bij gebruik van tabelfunctieparameters te werken met het doorgeven van waarden op positie zoals beschreven in Wat zijn tabelfuncties en tabelfunctieparameters?. Bijvoorbeeld select ... from NAAM@platform( NAAM => WAARDE ).

Merk tenslotte op dat het opgeven van tabelfunctieparameterwaardes in het algemeen niet nodig is op Visma.net. Een juist gekozen where-clause of filter in Power BI wordt automatisch omgeschreven naar het gebruik van tabelfunctieparameters.

Mocht deze performance-optimalisatie niet conform verwachting werken, gelieve dan het gewenste exacte SQL-statement met tabelfunctieparameters en waardes toe te voegen als antwoord.

In uw antwoord stelt u het volgende

Voor nu is het advies om bij gebruik van tabelfunctieparameters te werken met het doorgeven van waarden op positie zoals beschreven in Wat zijn tabelfuncties en tabelfunctieparameters?. Bijvoorbeeld select ... from NAAM@platform( NAAM => WAARDE ) .

Dit werkt dus niet zoals ik in mijn eerste request liet zien. En ook het volgende werkt niet :

select top 10 *
from VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions@platform
(ledger = ‘WERKELIJK’),

Hierbij krijg ik een foutmelding.

En ook

select top 10 *
from VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions@platform
where ledger = ‘werkelijk’
Geeft een error: A value for the parameter ‘ledger’ is required on table ‘VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions’. itgendid357

waarbij ik @platform vervangen heb door het platform.

Wat voor actie kan nu verder ondernemen om toch de gewenste resultaten te krijgen (het request op een view op generalledgertransactions geeft een timeout omdat er te veel data in zit (ook met een where statement))_

Om het datavolume te beperken kunt u gebruik maken van limit of top. De SQL-engine werkt waar het kan met streaming data, zodat enkel de data opgehaald wordt die nodig is.

Merk op dat de data real-time opgehaald wordt. Als alternatief kan ook gewerkt worden met het doorkopieren naar bijvoorbeeld SQL Server. De persoon die de uitleg heeft gehad kan u hier mogelijk verder bij informeren.

Voor positie op naam is hetnodig om => te gebruiken in plaats van = zoals in:

select top 10 *
from   VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions@vnt
       ( ledger => 'WERKELIJK'
       , fromPeriod => '202010'
       , toPeriod => '202012'
       )

Tenslotte kan ook voor grote administraties in het algemeen gemakkelijker gewerkt worden met de view GeneralLedgerTransactions. Filters hierop worden in het algemeen doorgegeven over de hele keten (“server-side filtering”).

Bedankt, als we de view willen gebruiken met de volgende query (in de online editor):

select top 10 *
from   VismaNet.Views.GeneralLedgerTransactions

krijgen we onderstaand resultaat:

image

itgenttn290
You have provided a parameter with name ‘COMPANY_CODE’, but there is no parameter with that hane in ‘VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions’.
Possible valid alternatives: branch, ledger, fromPeriod, toPeriod, account, subaccountId, fromDate, toDate.

Dank voor het melden. Dit betreft een bug die als gevolgschade volgt uit het verwijderen van de verwarrende COMPANY_CODE als tabelfunctieparameter. In de volgende release zal hiervoor een verbetering doorgevoerd zijn in de volgende vier views:

  • GeneralLedgerBalancesAll
  • GeneralLedgerTransactions
  • JournalTransactionLines
  • JournalTransactions

De ondersteuning van het oude VNI-authenticatieprotocol voor Visma.net vervalt hiermee definitief met versie 24.0.388 en nieuwer.

Advies is om voorlopig de volgende query te hanteren specifiek op Invantive Cloud in plaats van de view GeneralLedgerTransactions (voor Invantive Bridge Online speelt dit niet vanwege het gebruik van een oudere versie):

select lgr.company_code
,      fpd.period
,      lgr.number ledger_number
,      lgr.description ledger_description
,      txn.* except period, ledger_id, ledger_description, company_code
from   VismaNet.Ledger.Ledgers lgr 
join   VismaNet.FinancialPeriod.FinancialPeriods fpd
join   VismaNet.GeneralLedgerTransactions.GeneralLedgerTransactions(ledger => lgr.number, fromPeriod => fpd.period, toPeriod => fpd.Period) txn
limit 100 /* Kies gewenst aantal. Voeg eventueel filter toe voor periode. */