GL Transactions Endpoint - "Balance" Fields [Feedback Required]

[Yıldırım]

Hello everyone, 

we're currently working on the "GL Transactions Endpoint" to improve its performance, therefore, we need your input about GL Transactions Endpoint usage, especially with "Balance" specific fields and their roles in your integration flow. 

We've discovered that the following fields have huge negative impact on the endpoint's performance while requesting the data.

GET <GeneralLedgerTransactionDetailsDto>

"begBalance": 0,
"endingBalance": 0, 
"currBegBalance":  0
"currEndingBalance": 0,

Since we have another endpoint where General Ledger Balances can be fetched via (api/v2/generalledgerbalance), we're planning to remove those "Balance" fields from the "GL Transactions Endpoint" to eliminate unnecessary "Joins" which is affecting the query performance in the application level.

Our initial plan is introducing a new set of parameters / flags for "GL Transactions Endpoint" to keep backward compatibility. In this way, we'll also be able to monitor the performance wise effectiveness of the implementation before we go for total removal of the aforementioned fields. (with notice period in advance)

Following parameters have been planned to be implemented in version 8.60.0 (August 2021)
(Has been implemented > [Release Notes] - Visma.Net API 8.60.0 - 10.08.2021 )

• IncludeTransactionBalance
  By default, if no value is provided, True and each transaction returned will include its balance.
  If False, the transactions returned will not include their balances (fields BegBalance, EndingBalance, CurrBegBalance, CurrEndingBalance)

• ExpandAccountInfo:
  By default, if no value is provided, True and each transaction returned will include extended information about the accounts.
  If False, the account information will include only Number, Description, Type and GlConsolAccountCD.
  
  
• ExpandBranchInfo:
  By default, if no value is provided, True and each transaction returned will include extended information about Branch (number and name).
  If False, the branch information will include only the branch number.

Please rest assured that there will be no removal before we confirm that those fields are irrelevant and has no value for the integrations those are calling the GL Transactions Endpoint. 

Your feedback would be very helpful for us, thanks in advance.

Update:

Due dates of Breaking change on GeneralLedgerTransactions: (Nov 16,2021)

[Trygve Storrønningen1]

It might not be super relevant in this case, but in general you might consider implementing variants of the endpoint for different use cases with and addition in url. Some times one use case' need for info can kill performance for other use cases.

So instead of giving only once end point api/v2/generalledgerbalance as one-size-fits-all, you could generalize in 

api/v2/generalledgerbalance

and then create special versions in 

  api/v2/generalledgerbalance/financial  for users with financial users

and

  api/v2/generalledgerbalance/logistics for use cases from logistics view 

or 

  api/v2/generalledgerbalance/auditor if this could be another use case

I think focus on which use case the end point is going to serve will give a better result than new parameteres introduced as-you-go to fix issues that appears...

[Yıldırım]

Results from some of our internal testing,

1) GL Transactions Endpoint Performance Comparison 

2) GL Transactions - Current Version / 6.96 MB took 5.06s

3) New implementation, not using the new Parameters / Flags (  6.96 MB took 3.68s )

4) New implementation, using the new Parameters / Flags ( 5.5 MB took 1717 MS )