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.   Enforcement of pagination on API endpoints and change of maxPagesize   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. ... View more

  More APIs updated with help text in Swagger The following APIs have been updated with help text in Swagger. * Account * CashTransaction * Currency * FinancialPeriod * GeneralLedgerBalance * GeneralLedgerTransaction * Ledger * Vat The column numberToRead integer and skipRecords integer now include information that they will be terminated and replaced later. The Period and Date columns now include information about the format. Forced pagination in Shipment endpoint Now, there is forced pagination in the Shipment endpoint:  - If no pagination is specified, only 100 records will be returned  - If pagination is used but the maxPagesize is more than 100, then only 100 records will be returned  - maxPagesize info has been added as metadata in response Forced pagination in SalesOrderBasic endpoint Now, there is forced pagination in the SalesOrderBasic endpoint:  - If no pagination is specified, only 100 records will be returned  - If pagination is used but the maxPagesize is more than 100, then only 100 records will be returned  - maxPagesize info has been added as metadata in response Improved API error handling for Timecard endpoint We have improved API error handling for the Timecard endpoint so that it now shows the correct messages. Improved API error handling for Subaccount endpoint We have improved API error handling for the Subaccount endpoint so that it now shows the correct messages. New field in the API response message for the Project endpoint In order to improve the connection with third party integrators we included a new field ("VnfInternalID") in the API response message for the Project endpoint. The field represents the unique identifier of the project. JournalTransaction endpoint replaced with JournalTransactionV2 endpoint The 'JournalTransaction' endpoint is deprecated and will be removed in September 2020. A new endpoint was created to replace it. You find the documentation in Swagger under the 'JournalTransactionV2' endpoint. Fetch information on customer and commission history in Salesperson endpoint You are now able to fetch information related to customer and commission history in the Salesperson endpoint. See the swagger documentation for more information. Wrongfully logged API errors fixed API calls to endpoint /api/v1/webhooknotificationfeedback will now return 400 (Bad Request) when the notification passed in does not exist. The endpoint will also return 400 (Bad Request) if the passed in notification dto is not provided or invalid. New improved version of the JournalTransaction endpoint A new version of the JournalTransaction endpoint has been implemented. The main changes consist of performance improvements on the method of getting journal transactions. Mandatory parameters were introduced. You have to provide at least one of the parameters: 'PeriodId' and/or 'LastModifiedDateTime'. 'LastModifiedDateTime' is not allowed to have values less than 6 months back in time. The 'Module' parameter was introduced to facilitate filtering of data for integrators interested only in certain types of transactions. 'LastModifiedDateTimeCondition' was removed since the usage of it affects the purpose of lastModifiedDateTime: it should be used to synchronize data by requesting for changed data only. The 'Released' parameter was renamed to 'ReleasedBatch' and its type was changed to boolean. The default value of 'ExpandAttachments' was changed to false. The following parameters were removed: customerSupplierStart, customerSupplierEnd, greaterThanValue. Pagination is enforced, and the maximum page size is 100. If the page size is not provided or it is greater than 100, then it will be automatically set to 100. If the page number is not provided, then it will be automatically set to 1. Note: The old endpoint will be marked as deprecated and will be removed in three months.   The "Owner" field is left out in POST/PUT via Sales order endpoint Earlier, when owner was added in the API for PUT and POST for Sales order, the Owner field was left blank when the order was created or updated. This has now been fixed so that you can get the user ID of the employee from the Employee endpoint, and use this for setting the owner in the sales order. Response status returning 400 with a longer location ID than allowed The response status is now returning 400 when trying to POST or PUT a location with a location ID longer than the allowed setting in segmented keys. Filtering on sales subaccount improved In the previous version, filtering on sales subaccount was not working . This has now been fixed. General ledger balance v2 was giving HTTP 400 on valid requests  There was an issue on version 2 of the GeneralLedgerBalance endpoint: reading of account external codes was done wrongfully. Because of it, the response of the API was error code 400 - BadRequest. The issue related to reading the external codes is fixed now. Display metadata in Salesperson endpoint Metadata was not displayed in the Salesperson endpoint. This has now been fixed. In addition, base pagination is obsolete and will be removed in August 2020. ... View more

Improved API error handling for Project endpoint The API error handling for the Project endpoint has been improved to show correct messages Improved API error handling for Dimension endpoint The API error handling for the Dimension endpoint has been improved to show correct messages. Improved API error handling for ProjectTransaction endpoint We have improved API error handling for ProjectTransaction endpoint to show correct messages. New filters for visibility settings in ProjectBasic endpoint New filters for visibility settings have been added to the ProjectBasic endpoint, and they are available for integrations Updated documentation For the following endpoints, all parameters have updated documentation: Dimension, Department, Earning type, Employee, ExpenseClaim, ExpenseReceipt, Project, ProjectBasic, ProjectTransaction, Subaccount and TimeCard. Fixed LastmodifiedDate filter in BasicProject endpoint The LastmodifiedDate filter in the BasicProject endpoint was not working in previous versions. This has now been fixed. ... View more

Pagination forced in PurchaseOrder endpoint (Enforcement of pagination on API endpoints step 2 - May 26th release) Pagination is now forced in the PurchaseOrder endpoint: * If no pagination is specified, only 100 records will be returned * If pagination is used but the maximum page size is more than 100, then only 100 records will be returned * The maxPagesize info has been added as metadata in response Pagination forced in Location endpoint (Enforcement of pagination on API endpoints step 2 - May 26th release) Pagination is now forced in the Location endpoint: * If no pagination is specified, only 100 records will be returned * If pagination is used but the maximum page size is more than 100, then only 100 records will be returned * The maxPagesize info has been added as metadata in response Pagination forced in SupplierDocument endpoint (Enforcement of pagination on API endpoints step 2 - May 26th release) Pagination is now forced in the SupplierDocument endpoint: * If no pagination is specified, only 100 records will be returned * If pagination is used but the maximum page size is more than 100, then only 100 records will be returned * The maxPagesize info has been added as metadata in response Update Freight cost and Freight amount fields with shipment allocation lines Earlier, the Freight cost and Freight amount fields were not updated while updating shipment allocation lines. This has now been fixed. Update FreightAmount automatically based on FreightCost in Shipment endpoint Earlier, FreightAmount was not updated automatically based on FreightCost using PUT in the Shipment endpoint. This has now been fixed. Pagination forced in SupplierInvoice endpoint (Enforcement of pagination on API endpoints step 2 - May 26th release) Pagination is now forced in the SupplierInvoice endpoint: * If no pagination is specified, only 100 records will be returned * If pagination is used but the maximum page size is more than 100, then only 100 records will be returned * The maxPagesize info has been added as metadata in response ... View more

Release Notes Documentation Forced pagination in Subaccount endpoint Now, there is forced pagination in the Subaccount endpoint: - If no pagination is specified, only 100 records will be returned - If pagination is used but the max. page size is more than 100, then only 100 records will be returned - maxPagesize info has been added as metadata in response Forced pagination in Inventory endpoint (Postponed due to recently discovered issues) Now, there is forced pagination in the Inventory endpoint: - If no pagination is specified, only 100 records will be returned - If pagination is used but the max. page size is more than 100, then only 100 records will be returned - maxPagesize info has been added as metadata in response Forced pagination in CustomerInvoice endpoint Now, there is forced pagination in the CustomerInvoice endpoint: - If no pagination is specified, only 100 records will be returned - If pagination is used but the max. page size is more than 100, then only 100 records will be returned - maxPagesize info has been added as metadata in response Add forced pagination on customerdocument endpoint Now, there is forced pagination in the SalesOrder endpoint: - If no pagination is specified, only 100 records will be returned - If pagination is used but the max. page size is more than 100, then only 100 records will be returned - maxPagesize info has been added as metadata in response Forced pagination in SalesOrder endpoint Now, there is forced pagination in the SalesOrder endpoint: - If no pagination is specified, only 100 records will be returned - If pagination is used but the max. page size is more than 100, then only 100 records will be returned - maxPagesize info has been added as metadata in response Customers purchase order and purchase order line in EDI process We have added a new field called External link in the Sales orders, Shipment and Customer invoice windows and endpoints. The value in External link is moved between these windows via the actions: From Sales orders to Shipment when the action Create shipment is done, and from Shipment to Customer invoice when Prepare invoice is done. This applies both to UI and API. The field is only editable in the Sales orders window and the SalesOrder endpoint. In other places it is read only. New replacement for the 'GeneralLedgerBalance' endpoint The 'GeneralLedgerBalance' endpoint is deprecated and will be removed in August 2020. A new endpoint was created to replace it. The documentation for it can be found on Swagger under the 'GeneralLedgerBalanceV2' endpoint. Update projects with tasks with restrictedEmployee when using PUT API endpoint You are now able to update projects that have tasks with restrictedEmployee when using the PUT API endpoint: /controller/api/v1/project/{projectId} and /controller/api/v1/project/internal/{internalId} The field Active available via Subaccount endpoint The field Active is now exposed in the Subaccount endpoint. You can also filter on this field. This field will also be visible in all endpoints where SubaccountDTO is linked, for example, to customer invoice and supplier invoice. See the swagger documentation for more information. The field freightCost available via Shipment endpoint You are now able to POST/PUT the field freightCost via the Shipment endpoint. See the swagger documentation for more information. GET only projects and tasks with restrictedEmployee when using GET API endpoint You are now able to GET only the projects and tasks that have restrictedEmployee when using the GET API endpoint: /controller/api/v1/project Create allocations in KitAssembly endpoint You have now the possibility to create and update Kit allocation via the KitAssembly endpoint. See the swagger documentation for more information. Stock item and kit allocation via KitAssembly endpoint Allocations for stock items and kit allocation are now available via the KitAssembly endpoint. See the swagger documentation for more information. Created from available in KitAssembly endpoint The field Created from is now available in the KitAssembly endpoint. It is called SalesOrderLink. See the swagger documentation for more information. POST projects with tasks with restrictedEmployee in POST API endpoint You are now able to POST projects that have tasks with restrictedEmployee when using the POST API endpoint: /controller/api/v1/project. GET only projects and tasks with restrictedEmployee when using GET API endpoint You are now able to GET only the projects and tasks that have restrictedEmployee when using the GET API endpoint: /controller/api/v1/project/tasks GET/POST/PUT notes on header and line in ProjectTransaction endpoint You are now able to GET/POST/PUT notes on header and line in the ProjectTransaction endpoint. See swagger documentation for more information. Get and edit notes in Supplier endpoint You are now able to GET/POST/PUT notes in the Supplier endpoint. See the swagger documentation for more information. GET and POST Project Cost and Revenue Budget via ProjectBudget endpoint (PM309000) You are now able to GET and POST Project Cost Budget via the ProjectBudget endpoint. See swagger documentation for more information. Use internal employee ID to set Project manager on a project through API Now, you can use the internal employee ID to set a project manager on a project through the Project endpoint. GET/POST/PUT salespersons via SalesPerson endpoint You are now able to GET/POST/PUT salespersons via the SalesPerson endpoint. See the swagger documentation for more information. Creating new Customer invoices through API optimised There are new API v2 endpoints for POST: CustomerInvoice, CustomerCreditNote, and CustomerDebitNote have been optimised for performance. Testing with 1920 lines and setting 6 fields for each line gives 7.5 times better performance. Setting more fields for each line will give further improvement of the performance. New fields available via GET/POST/PUT in InventoryTransfer endpoint The following fields are now available via GET/POST/PUT in InventoryTransfer endpoint. - Allocations - Lot/Serial number - Expiration date See swagger documentation for more information. New endpoint for General Ledger Balances created A new version of 'GeneralLedgerBalance' is implemented. The data format is the same as the previous one, but there are some key changes related to how to use the new endpoint. A new parameter is introduced: LastModifiedDateTime It is mandatory to provide at least one of the parameters: LastModifiedDateTime and/or PeriodId. When the LastModifiedDateTime parameter is set, only the balances changed since the provided date and time will be exported. This implementation will improve the performance on the client-side since the amount of data to be fetched is significantly reduced. The consequence of this implementation is that a balance for a combination (of account, subaccount, ledger, branch, period) will not be generated - if the balance on that financial period was not changed and no record is registered for it. If the client still needs the balances for all combinations (of account, subaccount, ledger, branch, period) even though it was not changed in a certain period, there are three options: - If the endpoint exported no balance for a certain financial period, then identify the balance of the closest financial period smaller than the financial period under discussion, and construct your current balance based on that. This is the most appropriate solution for integrations saving the data on their own database. It is a win-win solution for both Visma.net ERP and the integrator. - Use the LastModifiedDateTime parameter on a daily basis. At the beginning of each month; call once the endpoint with the upcoming month as the period parameter, so all balances are generated. This is the second most recommended solution. - Use the endpoint without the LastModifiedDateTime parameter and get balances period by period. This is not recommended since you will never know which data was changed, and you will get all of it each time even though most of it is already on your side. Pagination is enforced, and the maximum page size is 100. If the page size is not provided or it is greater than 100, then it will be automatically set to 100. If the page number is not provided, then it will be automatically set to 1. Note: The old endpoint will be marked as deprecated and will be removed in three months. The field Account group retrieved in Account endpoint In the Account endpoint, the field Account group in the Chart of accounts (GL202500) window was not retrieved at all. This has now been fixed. PayDate is not updated in accordance to the supplier's payment settings In the SupplierInvoice endpoint, sending a dueDate without payDate set dueDate as per request, but incorrectly set payDate according to creditTerms and not leadDays settings on the supplier as intended. This issue has now been fixed. GET ProjectTransaction does not return lastModifiedDateTime The GET API call now returns the lastModifiedDateTime for project transactions for the ProjectTransaction endpoint. O2C endpoints return wrong error as response status code In version 8.20, the O2C endpoints returned error 500 while it should have returned error 400 as the response status code. This has now been fixed. Order By filter in PaymentMethod endpoint removed The Order By filter in the PaymentMethod endpoint was not functional and now it has been removed. Order By filter in Account endpoint removed The Order By filter in the Account endpoint was not functional and now it has been removed. Order By filter in JournalTransaction endpoint removed The Order By filter in the JournalTransaction endpoint was not functional and now it has been removed. Trailing spaces on item IDs in shipment allocation In version 8.20, trailing spaces on item IDs in allocation and trailing spaces in inventory numbers in the ShipmentDetailLines were not working correctly in the Shipment endpoint. This has now been fixed. Order By filter in Ledger endpoint removed The Order By filter in the Ledger endpoint was not functional and now it has been removed. Corrections in API documentation In the API documentation, it was wrongfully documented that filtering on account was mandatory. This has now been corrected. Also, if you specified an invalid account, all the transactions were returned. This has also been fixed so that no records are returned. Wrong window ID in Swagger documentation for SalesCategory Earlier, the Swagger documentation for the endpoint GET SalesCategory was referring to window ID SO301000 (Sales order). This was wrong. This has now been corrected and the documentation is now referring to the correct window ID, which is IN204060 (Item sales categories). Duplicates from paging over "GeneralLedgerTransactions" using "lastModifiedDate" parameter When using the LastModifiedDateTime filter in the GeneralLedgerTransactions endpoint, entries are now sorted by: BatchNbr, Module, LineNbr and LastModifiedDateTime. For all other cases the ordering is done by: TranDate, RefNbr, BatchNbr, Module, LineNbr. This new sorting regime will avoid duplicates from paging and differently sorted results for repeated queries with the same filter settings. ... View more

TotalCount on GET operation with pagination Earlier, the following endpoints did not fetch "totalCount". - Generalledgerbalance - Customercreditnote - Customercreditwriteoff - Customerdebitnote - Customerinvoice - Customerdocument - Inventory - Purchaseorderbasic - Journaltransaction This has now been fixed. GET CustomerInvoice using FT=1 BillContactID missing A faster version of GET CustomerInvoice endpoint is now available as a feature toggle (ft=1). You can use it like this: .../customerinvoice?ft=1 "directDebitLines" field not returned in Get specific/All via Customer endpoint Earlier, the customers' directDebit details were not loaded through GET customers endpoints using the following endpoints: /api/v1/customer/xxxxx /api/v1/customer?expanddirectdebit=true This has now been fixed. Expose Item ID in shipment allocation ItemID on allocation is now available via GET all and get specific in the Shipment endpoint. See the swagger documentation for more information. GET Inventory endpoint does not return InventoryUnits and Metadata:TotalCount Earlier, there was an issue with the GET Inventory endpoint, which did not return "InventoryUnits" and "Metadata:TotalCount". This has now been fixed. Create a get operation for KitAssembly endpoint You are now able to GET/POST/PUT and DELETE a kit assembly via the API. See the swagger documentation for more info. New API endpoint for update of customer number based on internal ID A new API endpoint for Customer has been implemented "...customer/action/changeCustomerCd/{internalId}". This endpoint can be used by third parties to update the CustomerCD based on the System Internal ID. This will improve the synchronization of data between the systems. SupplierTaxZone does not overwrite default value on supplier Earlier, there was an error when posting a purchase invoice with a different VAT zone than set on the supplier, resulting in the VAT zone being ignored. This issue has now been fixed so that the supplier VAT zone defined in the payload for the purchase invoice will overwrite the supplier VAT zone defined on the supplier. There is now a check after posting, and when the VAT region is not correctly set (or not the same as given in the first json) we edit the invoice. Sales order with wrong status and strange sums Earlier, when a sales order was created (POST) through API and the sent JSON file contained fields like ("hold": {"value": true}, completed": { "value": true }, "markForPO": { "value": false } ), the amounts from the Totals tab and the Sales order status were wrong. This has now been fixed. Inventory endpoints with project and task You are now able to GET Project and ProjectTask via the InventoryIssue and InventoryReceipt endpoints. See the swagger documentation for more information. ... View more

Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ Release plan & date may vary, we will keep the thread updated if changes arise. If you have any questions regarding the 8.19 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ If you have any questions regarding the 8.11 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ If you have any questions regarding the 8.12 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ If you have any questions regarding the 8.13 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ If you have any questions regarding the 8.14 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Visma.net ERP 8.15 - 29.06.2019 Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ If you have any questions regarding the 8.15 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Firstly, make sure that Financials Administrator & Financials User roles have been granted to your Visma.Net User.(that user have been used during the authentication process to generate a token for API as well as logging in to the Financials company) Please also invoke "Administrator Role" to your integration user via Financials UI. ScreenId=SM201010 ... View more

Visma.Net API Developer Support Community is a platform for Independent Software Vendors to raise questions, share ideas, experiences or provide feedback and hold discussions about Visma.Net API with other ISVs and enthusiasts, provide tips for using API to the community, get help from other developers and Visma.net API Consultants.  We encourage you to participate in ongoing discussions to help other users by sharing your knowledge or experience regarding the topics that you may have already faced and resolved. New user? If you are a Visma.Net API Certified Developer / Completed the ISV On-boarding but you don't have a username and password to log in, please register a new user with your Name & Surname together and your valid business email address that is provided with company email domain extension. In order to get further information on the user registration process, please contact your Partner Service from your related market. How to participate in the forum Create threads and posts related to the specific Visma.Net API topic that is the focus of that forum. To discuss another Visma product, you can visit that product’s forum. Post your Ideas, Feature Requests under the "Ideas" tab. Create posts that are related to the question or discussion to which you’re responding. Use "Search" to find questions or discussions that are related to your interests. If you are unable to find a related topic, start a new one by clicking New Topic. Create clear and concise topic subjects and posts. Subjects should not be in all capital letters. Include only important URLs. Posts with excessive/unrelated URLs will be removed. Do not include personal information. To ensure your safety, security, and privacy, never post your email address or any personal information you don’t want to share. Visma representatives won't ask for your password. Be cautious if you choose to contact others offline or ask others to contact you. Be respectful of others’ opinions. When disagreeing on an issue, stay polite and assume good intent. By using this community, according to GDPR, you confirm that your input will not contain sensitive or confidential information. Please see Visma Community Terms & Conditions Visma Privacy statement   Guidelines Visma.Net API Developer Forum participants are required to abide by the following guidelines. Breaking these guidelines might result in your post being removed. Severe abuses might lead to harsher penalties including warning or removal of access to the Visma.Net API Developer Support Community. Do not send confidential customer data via threads, posts or chat. Do not send login/token information via threads, posts, chat or tickets Please keep your posts constructive and positive, as name-calling or personal attacks are not welcomed here Only Visma.Net API Certified Developers can post Keep your messages concise and stay on the stated topic Respect copyright and do not post copyrighted information to the forums Search for posts on the same topic before posting a new question Post in the most relevant area for the relevant topic Members are asked only to post in English in our International Forums, as those belong to an English-speaking community The forums are actively moderated, but messages are not screened before they are posted Visma is not responsible for any errors or consequences caused by answers or information in this forum If you have an issue concerning our services, policies or staff, please use a personal contact method such as a private message or email to a staff member   Please also see, Visma.Net API International Support Policy Contacting the Visma.Net ERP Support / Partner Service API incidents - Troubleshooting and reporting Visma.Net Integrations Startup Guide ... View more

Please see attachment specific endpoints at https://integration.visma.net/API-index/ Webclient Class public void postAttachment(string[] files, string <objectID>, string token, string companyId) { using (WebClient client = new WebClient()) { client.Headers.Add("ipp-company-id", "<companyId>"); client.Headers.Add("ipp-application-type", "Visma.net Financials"); client.Headers.Add("Authorization", "bearer<token>"); for (int i = 0; i < files.Length; i++) // Multiple { byte[] responseArray = client.UploadFile(@"https://integration.visma.net/API/controller/api/v1/<Endpoint>/"+<objectID>+"/Attachment", "POST", files[i]); } } } HttpClient Class public void postAttachmentHttpClient() { using (var client = new HttpClient()) { client.DefaultRequestHeaders.Add("ipp-application-type", "Visma.net Financials"); client.DefaultRequestHeaders.Add("ipp-company-id", "<companyID>"); client.DefaultRequestHeaders.Add("Authorization", "Bearer <token>"); HttpResponseMessage response; var content = new MultipartFormDataContent(); var path = Path.Combine(@"<path>"); string fileName = Path.GetFileName(path); FileStream fs = File.OpenRead(path); var sc = new StreamContent(fs); sc.Headers.Add("Content-Type", "application/octet-stream"); sc.Headers.Add("Content-Disposition","form-data; name=\"file\"; filename=\"" + Path.GetFileName(path) + "\""); content.Add(sc, "file", fileName); response = client.PostAsync(@"https://integration.visma.net/API/controller/api/v1/<endpoint>/<objectID>/Attachment", content).Result; } } Disclaimer The sample code on Visma Community > Visma.Net API is provided “AS IS” and any express or implied warranties, including the implied warranties of merchantability and fitness for a particular purpose, are disclaimed. In no event shall Visma or contributors be liable for any direct, indirect, incidental, special, exemplary or consequential damages. ... View more

Hello, Please see attached startup guide & documents for Visma.net Integrations. Following documents & Information will be useful when starting to the integration. Currently, Visma.Net API does not support the "Password" grant type due to security policies. Henceforth, all the new clients are registered only with "OAuth 2.0 Authorization Code Grant" flow.   After completing the testing phase, you should contact your partner service (How to contact), informing them with your Redirect_URI to obtain Live - Production Client   API Request Throttling configuration  Visma.Net Integrations - API Client Types  Here you can find the latest version of the start-up guide for Authorization_Code Flow. 1- Generating Token with OAuth 2.0 Authorization Flow 2- Code Example (C#) Generate Token with The Authorization Code Grant flow Useful links Visma.Net API Endpoint Documentation: Swagger Visma Academy training platform API incidents - How to troubleshoot and report Contacting the Visma.Net ERP Support / Partner Service Background Information on API Client & Token & Visma.net Financials User & Company Visma.net ERP API uses OAuth 2.0 bearer tokens (OAuth 2.0 Authorization Code Grant) to authenticate API calls.  This flow generate a token on behalf of the Visma.Net Financials user. The authenticated user's access rights(Financials Administrator-Financials User) in Visma.net determine that the generated token can be used on which company. (The user to whom the token belongs needs to have the aforementioned roles in that company in order to access via the API.) Supposing that there is X ISV has 2 customers and integration running like 1st Customer: a-b-c companies 2nd customer: d-e-f companies -When token request made from the same API CLIENT ID: Each company should have its own Visma.Net user to generate a token and this token will work as covering the companies based on the authenticated users granted roles on the Visma.Net Financials. The token belongs to visma.net USER and can be used on any company where the user has "Financials User"-"Financials Administrator" role granted. ISV should provide the interface for the client/user to interact with the web browser and each user should be authorized to generate a token by their own credentials. If there are multiple companies, you should ask the user to select/specify which company is the integration made for. This can be a one-time set up at the beginning then once you generate the token you can store it for that user and can be used on the companies which one the user has access to. You can Get the companies available for the used token/Integration user via Context endpoint for mapping user/token = Financials Company https://integration.visma.net/API/ resources/v1/context Currently, Token Life Cycle does not have any specific interval, it's planned to facilitate as never expires. Each consecutively generated token automatically invalidates the recently created one. (Request made from the Same CLIENT ID & the Same Visma.Net Financials user for all integrations/company) ❌ ISV / Integrator should ask their ERP Customer to have a different user for each integration/company. In this way, the integrator will use the same "client_Id" for all the integrations, but the ERP Customer will be using a different user for each company during the authorization. This is the recommended setup for our ISVs for obtaining a token while using the same ClientID for all the integrations. ✔️ In this way, If something goes wrong with one of the integrations (e.g. token gets invalidated), ISV generates a new token, then the other integrations will not be affected thus ISV can continue to use their existing token/s. Auth Code Flow ... View more

Visma.net ERP 8.16 Release, 28.09.2019 Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ If you have any questions regarding the 8.16 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Visma.net ERP 8.17 Release, 09.11.2019 Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/ Release plan & date may vary, we will keep the thread updated if changes arise. If you have any questions regarding the 8.17 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions. ... View more

Visma.net ERP 8.18 Release, 17.12.2019 Please follow the Status page for updates regarding the maintenance window: https://status.visma.com/   Release plan & date may vary, we will keep the thread updated if changes arise. If you have any questions regarding the 8.18 Release, please feel free to contact your partner service or developersupport@visma.com for API related questions.   ... View more

  When you have encountered an issue and it seems related to the ERP UI Configurations or ISV needs to clarify financials company setup, Licence related matters before moving further with the API, the ERP support / Partner Service should be contacted. In this case, please inform your Visma.net Financials customer to contact Financials ERP Support or Partner Service from relevant market to get further information regarding the procedure that should be followed.   Partner service contact details for ISVs Country For ISVs (Partner Service) For ERP users (Visma Partner) 🇩🇰 Denmark erp@visma.dk Find your partner: https://www.visma.dk/software/erp/vismabusiness/find-partner/ ERP Support: https://www.visma.dk/software/erp/support/ 🇳🇱Netherlands partnersnl@visma.com    Find your partner: https://nl.visma.com/erp/partners/ ERP Support: consultancynl@visma.com Community: https://community.visma.com/t5/Visma-net-Financials-Logistics/ct-p/NL_SW_Visma_net 🇳🇴 Norway kundesenteret@visma.no ERP API Integration: https://www.visma.no/erp/api/ Find your partner: https://www.visma.no/erp/finn-din-partner/ ERP Support: Visma.net.support@visma.no Community: https://community.visma.com/t5/Visma-net-ERP/ct-p/NO_SW_Vismanet_ERP 🇸🇪 Sweden vismanetisv@visma.com Find your partner: https://www.visma.se/affarssystem-i-molnet/hitta-partner-se/ Community: https://community.visma.com/t5/Visma-net-ERP/ct-p/SE_SW_Vismanet-ERP-Ekonomi 🇫🇮 Finland sovellustuki@visma.com Find your partner: https://www.visma.fi/vismanet/jalleenmyyjapartnerit/ Community https://community.visma.com/t5/Sovellustuki/bd-p/FI_SW_Visma_net_support ... View more

    In this article, you can find guidelines for how to use Visma.Net API Endpoints connected to the Customer Ledger from Visma.Net Financials. For more information regarding the endpoints, query parameters and other endpoints for all areas, Please read the documentation found here: Swagger - Visma.Net Integrations Documentation   Customer  Common usage example for Customer(ScreenId=AR303000) URL: https://integration.visma.net/API/controller/api/v1/Customer Methods: GET All Customers URL: https://integration.visma.net/API/controller/api/v1/Customer Example of usage with parameters Query parameters: lastModifiedDateTime=YYYY-MM-DD As of today Filtering Parameters does not accept certain characters such as W-Z These are the formats for Filtering *2001-01-01 *2001-01-01 13:13:13 *2001-01-01 13:13:13.133   lastModifiedDateTimeCondition=Operator Supported comparative operators for LastModifiedDateTime Conditions on filtering  > - Greater than < - Less than <= - Less than or equal to >= - Greater than or equal to   Usage example: This query will return customers updated on 2020-01-14 or later. GET https://integration.visma.net/API/controller/api/v1/Customer ?lastModifiedDateTime=2020-01-14 &lastModifiedDateTimeCondition=>= ( Lines are separated for readability) POST Customer URL: https://integration.visma.net/API/controller/api/v1/customer This example shows the minimum fields you should send to be able to post a new Customer, if you are using automatic numbering you can omit the “number” field. JSON Request body {   "name": {     "value": "NewCustomer"   }, "number": {     "value": "10000"   },   "overrideWithClassValues": true,   "customerClassId": {     "value": "1"   },  "mainAddress": {     "value": {       "addressLine1": {         "value": "TestRoad 13"       },       "postalCode": {         "value": "0101"       },       "countryId": {         "value": "NO"       }     }   } }   If sent successfully, the API will return: Status 201 Created POST action/createDunningLetter URL: https://integration.visma.net/API/controller/api/v1/customer /{customerNumber}/action/createDunningLetter This example shows what should be sent to create dunning letters for a specified customer. JSON Request body {   "dunningLetterDate": "2020-01-21T09:39:48.538Z",   "levelFrom": 1,   "levelTo": 2 } If successful the API will return a message as below: Status: 200 OK Response body: {     "actionId": "2ddece9b-a89b-4f5a-a251-2cf14837bb2d",     "actionResult": "Done" } PUT Customer URL: https://integration.visma.net/API/controller/api/v1/customer/{customerNumber} When using PUT, you only send the fields you want to update. In the below example, we update the mainAddress of the customer: URL: PUT https://integration.visma.net/API/controller/api/v1/customer/10000 JSON Request body {     "mainAddress": {         "value": {             "addressLine1": {                 "value": "TestRoad 50"             },             "postalCode": {                 "value": "0101"             },             "countryId": {                 "value": "NO"             }         }     } } If successful, the API will return: Status: 204 No Content Customer CreditNote Common usage example for Endpoint(ScreenId=AR301000) URL: https://integration.visma.net/API/controller/api/v1/CustomerCreditNote Methods: GET All Customer Credit Notes URL: https://integration.visma.net/API/controller/api/v1/CustomerCreditNote Example of usage with parameters Query parameters: financialPeriod=YYYYMM Lets you define what financialPeriod to include in the response   status=string Limits response to CreditNotes with a status   expandAttachments=boolean Lets you decide if you want attachments to be expanded or not.   expandTaxDetails=boolean Lets you decide if you want tax detail lines to be expanded or not. Usage example: This will return Customer CreditNotes in the financial period 01-2020 that have the status “balanced”, and will not expand attachments or tax detail lines. GET https://integration.visma.net/API/controller/api/v1/customerCreditNote ?financialPeriod=202001 &status=balanced &expandAttachments=false &expandTaxDetails=false (Lines are separated for readability) POST CustomerCreditNote URL: https://integration.visma.net/API/controller/api/v1/CustomerCreditNote This example shows the minimum fields you should send to be able to post a new Customer Credit Note, if you are using automatic numbering you can omit the “referenceNumber” field. JSON Request body {   "currencyId": {     "value": "NOK"   },   "externalReference": {     "value": "ExRef"   },   "lines": [     {       "operation": "Insert",       "inventoryNumber": {         "value": "6"       },       "quantity": {         "value": 1       },       "unitPriceInCurrency": {         "value": 1       }     }   ],   "customerNumber": {     "value": "10000"   },  "referenceNumber": {     "value": "25698"   },   "documentDate": {     "value": "2019-12-21"   },    "postPeriod": {     "value": "122019"   },   "financialPeriod": {     "value": "201912"   } }   If sent successfully, the API will return: Status 201 Created PUT CustomerCreditNote URL: https://integration.visma.net/API/controller/api/v1/CustomerCreditNote/{creditNoteNumber} When using PUT, you only send the fields you want to update. In the below example, we update the first line of the Credit Note: URL: PUT https://integration.visma.net/API/controller/api/v1/CustomerCreditNote/25698 JSON Request body {     "lines": [         {             "operation": "Update",             "lineNumber": {                 "value": 1             },             "inventoryNumber": {                 "value": "6"             },             "quantity": {                 "value": 1             },             "unitPriceInCurrency": {                 "value": 1             }         }     ] } If successful, the API will return: Status: 204 No Content Customer DebitNote Common usage example for Customer Debit Note(ScreenId=AR301000) URL: https://integration.visma.net/API/controller/api/v1/CustomerDebitNote Methods: GET All Customer Debit Notes URL: https://integration.visma.net/API/controller/api/v1/CustomerDebitNote Example of usage with parameters Query parameters: Project=String Will limit response to documents with the specified project Usage example: This will return Customer Debit Notes with projectID 20. GET https://integration.visma.net/API/controller/api/v1/customerDebitNote ?project=20 POST CustomerDebitNote URL: https://integration.visma.net/API/controller/api/v1/CustomerDebitNote This example shows the minimum fields you should send to be able to post a new Customer Debit Note, if you are using automatic numbering you can omit the “referenceNumber” field. JSON Request body {   "lines": [     {       "operation": "Insert",       "description": {         "value": "Test"       },       "quantity": {         "value": 2       },       "unitPriceInCurrency": {         "value": 2       },       "uom": {         "value": "STK"       }     }   ],   "customerNumber": {     "value": "10000"   },   "referenceNumber": {     "value": "000050"   },   "documentDate": {     "value": "2020-01-16"   },   "postPeriod": {     "value": "012020"   },   "financialPeriod": {     "value": "202001"   },   "invoiceText": {     "value": "DebitNote"   } }   If sent successfully, the API will return: Status 201 Created PUT CustomerCreditNote URL: https://integration.visma.net/API/controller/api/v1/CustomerDebitNote/{debitNoteNumber} When using PUT, you only send the fields you want to update. In the below example, we update the first line of the Credit Note: URL PUT https://integration.visma.net/API/controller/api/v1/CustomerDebitNote/000050 JSON Request body {     "lines": [         {             "operation": "Insert",             "lineNumber": {                 "value": 1             },             "inventoryNumber": {                 "value": "6"             },             "quantity": {                 "value": 1             },             "unitPriceInCurrency": {                 "value": 1             }         }     ] } If successful, the API will return: Status: 204 No Content Customer Invoice Common usage example for CustomerInvoice(ScreenId=AR301000) URL: https://integration.visma.net/API/controller/api/v1/CustomerInvoice Methods: GET All URL: https://integration.visma.net/API/controller/api/v1/CustomerInvoice Example of usage with parameters Query parameters: lastModifiedDateTime=YYYY-MM-DD As of today Filtering Parameters does not accept certain characters such as W-Z These are the formats for Filtering *2001-01-01 *2001-01-01 13:13:13 *2001-01-01 13:13:13.133   lastModifiedDateTimeCondition=Operator Supported comparative operators for LastModifiedDateTime Conditions on filtering  > - Greater than < - Less than <= - Less than or equal to >= - Greater than or equal to Usage example: This query will return customers updated on 2020-01-14 or later. GET https://integration.visma.net/API/controller/api/v1/CustomerInvoice ?lastModifiedDateTime=2020-01-14 &lastModifiedDateTimeCondition=>= ( Lines are separated for readability) POST CustomerInvoice URL: https://integration.visma.net/API/controller/api/v1/CustomerInvoice This example shows the minimum fields you should send to be able to post a new Customer Invoice, if you are using automatic numbering you can omit the “referenceNumber” field. JSON Request body {   "invoiceLines": [     {       "operation": "Insert",       "inventoryNumber": {         "value": "222"       },       "quantity": {         "value": 500       },       "uom": {         "value": "STK"       }     }   ],   "sendToAutoInvoice": {     "value": true   },   "referenceNumber": {     "value": "156589"   },   "customerNumber": {     "value": "10000"   },   "documentDate": {     "value": "2020-01-27"   },   "invoiceText": {     "value": "Payment for potatoes"   } }   If sent successfully, the API will return: Status 201 Created PUT CustomerInvoice URL: https://integration.visma.net/API/controller/api/v1/CustomerInvocie/{InvoiceNumber} When using PUT, you only send the fields you want to update. In the below example, we update the first line of the Invoice: URL PUT https://integration.visma.net/API/controller/api/v1/CustomerInvoice/003547 JSON Request body {     "lines": [         {             "operation": "Insert",             "lineNumber": {                 "value": 1             },             "inventoryNumber": {                 "value": "6"             },             "quantity": {                 "value": 1             },             "unitPriceInCurrency": {                 "value": 1             }         }     ] } If successful, the API will return: Status: 204 No Content ... View more