to get a personalized navigation.
to get a personalized navigation.
This thread will be updated regularly up until the point of version-release.
If you have any questions & comments, please go to the case specific thread or post a new one to inform us about your inquiry in detail. You can also contact us via developersupport@visma.com
*8.25 Release (08.09.2020) -POSTPONED- Information: https://status.visma.com/incidents/22f0crhg5wg0
Update:
*New release date for 8.25 version has been planned as 15th of September.
Release plan & date may vary. We will keep you informed of any changes. (https://status.visma.com/incidents/hnyxw0fmm166)
The following cases have been planned to be implemented in the upcoming 8.25 Release.
Release Notes | Documentation |
---|---|
Increase of data transferred through GeneralLedgerBalance endpoint
|
Previously, the table containing balances did not have the LastModifiedDateTime column. To implement filtering by LastModifiedDateTime on GeneralLedgerBalance endpoint, the column from the Transactions table was used. However, this implementation might cause some issues. Now there is the LastModifiedDateTime column in the Balances table and it is used in the API endpoint implementation. This is not a breaking change. However, the integrators should expect an increase of transferred data first time they call the endpoint after release. This behavior is determined by the new column. For the existing entries, the newly introduced column will be filled in with the current date and time. There is no way to find out exactly when a balance was changed last time, so this approach is the only solution to ensure data integrity. For example, the newly introduced column will be added during the upgrade on 15th of September 2020. For all lines the last modified date time will be set to '2020.09.08 hh:mm:ss'. Supposing an integrator had it's last synchronization on '2020.09.07 22:00:00', on next synchronization, after '2020.09.08 hh:mm:ss', the '2020.09.07 22:00:00' will be set as last modified date and time. Then there will be fetched all lines from database. This will happen only on first synchronization after upgrade. On the next ones there will be set a last modified date and time greater than '2020.09.08 hh:mm:ss' and only really changed balances will be fetched |
Pagination metadata in projectTransactions endpoint |
To the ProjectTransaction endpoint has been added the Metadata total count field so that third party integrators and partners can now implement pagination on this endpoint. |
Forced pagination added on several endpoints |
The Employee, Payment, SupplierPayment and ProjectBasic endpoints now include the Metadata total count field. There is also enforced pagination with the maximum page size 500, so that third party integrators and partners can now implement pagination on these endpoints. |
Pagination forced in PurchaseOrder endpoint |
Pagination is now forced in the PurchaseOrder endpoint: * If no pagination is specified, only 500 records will be returned * If pagination is used but the maximum page size is more than 500, then only 500 records will be returned * The maxPagesize info has been added as metadata in response |
Forced pagination and max. page size on several endpoints |
Now, there is forced pagination in the Country, VatZone, DeferralCode, purchaseOrderBasic, customerSalesPrice, inventoryAdjustment, inventoryIssue, generalLedgerTransactions, inventoryTransfer, salesOrderType, CashSale, CustomerCreditNote, customerCreditWriteOff, customerOverdueCharge, and location/{baccountId} endpoints: - If no pagination is specified, only the maxPagesize will be returned - If pagination is used but the page size is greater than the maxPagesize, then only the maxPagesize records will be returned - The maxPagesize info has been added as metadata in response The maxPagesize variable should not be hardcoded as it can be changed without notifcation, based on our monitoring. |
Internal ID added to API response for Customer and Inventory endpoints |
There is a new field "vnfinternalid" in the response message on the Post operation on Customer and Inventory endpoints. It can be used by third party integrators to make the connection to a unique identifier of the customer and stock item |
Override number series for POST Customer |
You are now able to override the number series of a customer by specifying the field overrideNumberSeries=true when creating a customer. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer customer number when using overrideNumberSeries than what is specified in segment keys for customer |
Override number series for POST CustomerDebitNote V2 |
You are now able to override the number series of a customer debit note by specifying the field overrideNumberSeries=true when creating a customer debit note. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer customer debit note when using overrideNumberSeries than what is specified in number series for customer debit note. This option is only available for V2 of the Customerdebitnote endpoint. |
Override number series for POST SalesOrder |
You are now able to override the number series of a sales order by specifying the field overrideNumberSeries=true when creating a salesorder. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer salesorder number when using overrideNumberSeries than what is specified in number series for salesorder |
Override number series for POST Supplier |
You are now able to override the number series of supplier by specifying the field overrideNumberSeries=true when creating a supplier . This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer supplier number when using overrideNumberSeries than what is specified in segment keys for supplier |
Override the number series of journal transactions V2 |
You are now able to override the number series of journal transactions by specifying the field overrideNumberSeries=true when creating a journal transaction. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. |
Override number series for POST PurchaseOrder |
You are now able to override the number series of a purchase order by specifying the field overrideNumberSeries=true when creating a purchase order. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer purchase order number when using overrideNumberSeries than what is specified in number series for purchase order. |
Override the number series of supplier invoices |
You are now able to override the number series of supplier invoices by specifying the field overrideNumberSeries=true when creating a supplier invoice. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. |
Override number series for POST CustomerCreditNote V2 |
You are now able to override the number series of a customer credit note by specifying the field overrideNumberSeries=true when creating a customer credit note . This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer customer credit note when using overrideNumberSeries than what is specified in number series for customer credit note. This option is only available for V2 of the customercreditnote endpoint. |
Override number series for POST CustomerInvoice V2 |
You are now able to override the number series of a customer invoice by specifying the field overrideNumberSeries=true when creating a customer invoice. This functionality has to be enabled in the Number series (CS201010) window by selecting option Allow manual numbering on imports. You also can specify a longer customer invoice number when using overrideNumberSeries than what is specified in number series for customer invoice. This option is only available for V2 of the customer invoice endpoint. |
Get the salespersons for customer |
You are now able to fetch salespersons for a given customer. See the swagger documentation for more information. |
Start date and End date added to SupplierInvoice endpoint |
You are now able to GET/POST/PUT the fields "Term start date" and "Term end date" via the SupplierInvoice endpoint. See the swagger documentation for more info. |
AlternateID available via the Shipment endpoint |
The field AlternateID is now available via the Shipment endpoint. See the swagger documentation for more information. |
Fetch barcodes for different documents via the Inventory endpoint |
You are now able to fetch barcodes for different documents via the Inventory endpoint. Following routes are now available: /controller/api/v1/inventory/barcode/stocktake/{referenceNumber} /controller/api/v1/inventory/barcode/purchasereceipt/{receiptNbr} /controller/api/v1/inventory/barcode/shipment/{shipmentNbr} /controller/api/v1/inventory/barcode/salesorder/{orderNbr} See the swagger documentation for more information. |
PUT/POST/DELETE discount via API |
You are now able to PUT/POST/DELETE a discount via API. See the swagger documentation for more information. |
Wrongfully logged REST API errors fixed |
AccountController Endpoints: The BadRequest Error thrown by API validators were wrapped by InternalServer Error before. This is now removed. PUT - "api/v1/account/{accountCd}" - Updating of Account object will give HTTP BadRequest - 400 error if the input is invalid. POST - "api/v1/account" - Creating of Account object will give HTTP BadRequest - 400 error if the input is invalid. CashSaleController Endpoints: The BadRequest Error thrown by API validators were wrapped by InternalServer Error before. This is now removed. POST - "api/v1/cashsale" Creating of CashSale object will give HTTP BadRequest - 400 error if the input is invalid. CashTransactionController Endpoints: The BadRequest Error thrown by API validators were wrapped by InternalServer Error before. This is now removed. POST - "api/v1/cashTransaction" - Creating of CashTransaction object will give HTTP BadRequest - 400 error if the input is invalid. action/reverse - "api/v1/cashTransaction/{referenceNbr}/action/release" Reversing a cash transaction will give HTTP BadRequest - 400 error if the input is invalid. FinancialPeriodController Endpoints: FinancialPeriodNotSetup error thrown by system was not caught properly earlier. This is now handled. GETALL - "api/v1/financialPeriod" - If financial periods are not set up during FirstTimeStartup - HttpStatusCode.NotFound is thrown with proper error message GET by Id - "api/v1/financialPeriod/{financialPeriodId}" - If financial periods are not set up during FirstTimeStartup - HttpStatusCode.NotFound is thrown with proper error message |
New endpoint for Attributes |
New API-methods for handling attributes are now available. See the Attributes window (CS205000) for reference. |
New Project task endpoint with four operations |
A new Project task endpoint has been created with 4 operations: Get Project Task, Get Project Task (Internal ID), Put Project task (internal ID), Post Project task (internalProjectId) that third party integrators can use to identify, create and update project tasks by the internalID (a unique identifier of the project task) |
"Don't email" and "Don't print" added to CustomerDebitNote and CustomerCreditNote endpoints |
The fields "Don't email" and "Don't print" have now been added to the CustomerDebitNote and CustomerCreditNote endpoints. |
New fields added to CustomerInvoice endpoint |
There are new fields in the CustomerInvoice endpoint: - Start date - End date - Accounting cost ref. - Originator document ref. - Contract document ref. |
POST and PUT exchange rates via Currency endpoint |
You are now able to POST and PUT exchange rates via the Currency endpoint. See the swagger documentation for more information. |
New endpoint ProjectAccountGroup |
A new endpoint ProjectAccountGroup has been implemented and it can be used by third party integrators to identify all account groups or a specific account group. |
Three new endpoints for updating and retrieving data in Stock items window |
There are three new endpoints (POST, PUT and GET) regarding inventory and crossReference. The endpoints are for updating and retriveing data in the Stock items (IN2025000) window, on the Cross-reference tab. |
New fields available via GET/POST/PUT in InventoryIssue endpoint |
The following fields are now available via GET/POST/PUT in the InventoryIssue endpoint. - Allocations - Lot/Serial number - Expiration date See the swagger documentation for more information. |
Pagination not working with Account endpoint |
The error in the Account endpoint documentation has been fixed. Now, pagination is not implemented on this endpoint and the numberToRead and skipRecords are deprecated fields. |
Maximum page size increased to 500 for all endpoints |
The maximum page size has been increased to 500 for all endpoints on 10.07.2020 |
Return response code 400 instead of 500 when invalid parameter is given for POST KitSpecification endpoint |
Earlier, we returned response code 500 when wrong parameter was used for the POST KitSpecification API endpoint. This has now been corrected, and we now return response code 400 instead. |
The customer number field returns trailing spaces when using the "CustomerInvoice" endpoint |
Earlier, on the CustomerInvoice endpoint, the object for customer did not remove spaces before and after the customer number. This has now been fixed. |
Return response status 400 instead of 500 when invalid parameter is given in the GET KitSpecification endpoint |
Earlier, we returned response code 500 when invalid parameter was given for the GET KitSpecification endpoint. This has now been corrected, and we now return response code 400 instead. We have also added support for GET all. |
Return response code 400 instead of 500 when invalid parameter is given for the PUT KitSpecification endpoint |
Earlier, we returned response code 500 when invalid parameter was given for the PUT KitSpecification endpoint. This has now been corrected, and we now return response code 400 instead. |
GET operation on inventory with alternateID using $batch endpoint not returning correct data |
Earlier, the GET operation on inventory with alternateID using the $batch endpoint was not returning correct data. This has now been fixed. |
The parameters "createdDateTime" and "createdDateTimeCondition" are not working in the GET Inventory endpoint |
Earlier, the parameters "createdDateTime" and "createdDateTimeCondition" were not working correctly in the GET Inventory endpoint. This has now been fixed. |
Error handling for purchase invoices improved |
Error handling when using OverrideNumberSerie=true together with the manual numbering option has been improved. |
Return order type on webhook response for sales order |
Earlier, the webhook for Sales orders did not return the sales order type in the response. This has now been fixed. |
Use CashTransaction endpoint with a transaction date in a closed period |
In the previous version, it was not possible to use the CashTransaction endpoint with a transaction date in a closed period, even when the finanacial period was in an open period. This issue has now been fixed. |
Inventory endpoint POST allows creating items with length higher than segment key |
The Inventory endpoint's POST operation allowed creating items with length higher than the UI segment key. Now, this has been fixed. If you send through API a length higher than set on the segment key, an error will be returned. |
Convert lower case letters to capital letters when creating an invoice in API with lower case letters |
In earlier versions, when manual numbering was activated for the sales invoices Ref.nbr/Invoice no. and you imported an invoice with an invoice number containing lower case letters, the data was not saved correctly. This led to not being able to match an incoming payment in the Process incoming payments (AR305000) window to the invoice. This has now been fixed. |
API: Posting a customer with the same customer ID that a previously deleted customer had, returns an error |
Earlier, when a customer was created through API with a specific customer ID and then was deleted from the UI, an error occurred when you tried to recreate the same customer with the same customer ID. This has now been fixed. |
Copyright © 2022 Visma.com. All rights reserved.