Duplicate and missing rows in financial periods API.

[guidol]

See https://forums.invantive.com/t/retrieving-financial-periods-from-visma-net/2849

When retrieving the financial periods through https://integration.visma.net/API/controller/api/v1/financialPeriod?numberToRead=1&skipRecords=0, we see an inconsistent behavior. Irrespective of the value of skipRecords, always the same period is returned.

When retrieving pages of 100 rows, some rows (periods) are occur twice, one time per page, and some rows (period) occur never.

Sample:

https://integration.visma.net/API/controller/api/v1/financialPeriod?numberToRead=1&skipRecords=0

yields:

[
{
"year":2022,
"period":"202202",
"startDate":"2022-02-01T00:00:00",
"endDate":"2022-02-28T00:00:00",
"description":"februari",
"active":true,
"closedInSupplierLedger":false,
"closedInCustomerLedger":false,
"closedInInventoryManagement":false,
"closedInGeneralLedger":false,
"closedInCashManagement":false,
"closedInFixedAssets":false
}
]

but with skipRecords = 1, the outcome is 100% identical.

It seems isolated to the financial periods API. There are no complaints on other Visma.net APIs at the moment.

It am sorry, but it is unclear since when this problem occurs. We will be adding an automatic consistency check on duplicate rows for this API in a next release of Invantive SQL.

[Yıldırım · Accepted solution]

Hello, 

Currently, Pagination is not available in the Financials Period endpoint and NumberToRead - SkipRecords have been marked as obsolete and will be deprecated, therefore we don't recommend using those filters at the moment.   We'll also inform the team to review when Pagination can be implemented to this endpoint. 

[guidol]

Thank you for the clarity!

Is there an upper bound on the page-size using numberToRead that can be used and still works returning the requested number of rows instead of truncating the result set?

We have tested with 250, which in worst case scenario of 50 periods per year would allow for five years.

In the use case, the customer has more than 100 rows in the periods list for one company, with 100 being the default page size.

In the market there is a rumor that Visma.net new developments have been stalled for accounting for the 12-24 months. Are there any plans to extend this API?

[Yıldırım · Accepted solution]

Hello, 

unfortunately, we don't have information about the current status of the numberToRead at the moment since it's marked obsolete, we'll check this out and get back to you. Regarding the comment about Accounting module, development is continuing and there is no suspension of any development in that area. 

[guidol]

Is there any news on numberToRead or is the formal specification NOT to use it despite swagger contents and will it then retrieve ALL financial periods (maybe hundreds)?

[Yıldırım · Accepted solution]

Hello,

after consulting this with the team, the recommendation is not using the numberToRead & SkipNumber parameters as it's stated. We're currently working on implementation of Pagination for this endpoint. 

[guidol]

Thank you for the clarity! We will disable pagination on this endpoint for now.

[guidol]

Hello Yildirim, thanks, I will await.

Thanks for update on Accounting module. An accounting firm informed that maintenance was being stopped for some time, but that probably was some communication error.

[guidol]

Sample from output of API call on company 4239953. Please note that it requires 100+ periods to be present with page size of 100 to show the issue. It seems that specifically this API allows a page size of at least 250 which might alleviate the issue for most purposes, but there are users with more history and/or more periods per calendar year.