Hello,  we'll look into it and get back to you. ... View more

Hello,  We'd like to clarify some operation details of how CashTransaction works in the Financials ERP before drill down into the API operation and the reported issue. 1) Offset Account and Offset Subaccount fields are mandatory in the ERP. So, CT documents can not be registered without assigning any value to those fields. 2) There are two ways of these values would automatically be fetched to the CT document in the Financials ERP.  A) Through selected  "Entry Type" Defaults B) Through selected "Inventory:  Default GL Accounts" - Inventory>salesAccount = CashTransactionLine>offsetAccount - Inventory>salesSubAccount = CashTransactionLine>offsetSubAccount In the UI, those values can not be automatically fetched into the Cash Transaction Line if the aforementioned both module's defaults are missing and, therefore, they should be manually filled. When it comes to your point,   @Florian Haase wrote: no problem to register this in the UI. It seems that the API does not axcept to registrer cashaccount - transaction with Inventory number instead of offsetAccount, but thats no problem in the user-interface. Could you confirm before I start to make a lot of workarounds? As it mentioned in the operation clarification part above, bypassing Offset & OffsetSubAccount value is not possible in the UI either. In your case most likely, these values have automatically been fetched from the Inventory Card's default as soon as you enter the InventoryID. Consequently, after conducting some testing, we're seeing that CashTransaction Endpoint does not automatically inherit the default  Inventory GL : "Sales" & "Sales subAccount" to "Offset" & "OffsetSubAccount" values of the desired inventory to the Cash Transaction Document when only "InventoryNumber" included in the payload.  So that, it returns         "message": "Error: Inserting 'Cash management transaction details' record raised at least one error. Please review the errors.\r\nError: 'Offset account' cannot be empty."       This case has been escalated to the development team.  Relevant status updates will be shared under this thread. We appreciate your reporting this issue to us.   Workaround:   OffsetAccount & OffsetSubAccount can be specified in the POST operation "offsetAccount": { "value": "string" }, "offsetSubaccount": [ { "segmentId": 0, "segmentValue": "string" }   ... View more

Hello Florian,  we'll look into it and get back to you. ... View more

This is the information that we received from the infrastructure team about how that specific exception is built. If there are inconsistencies in the scenarios of when the exception thrown, please inform us on the followed steps before you've received the response so that we can check this out in detail. ... View more

Hello Frank,   Details haven't been emerged yet, therefore, we're unable to share a specific version information at the moment, but this has been prioritized. V1 Endpoint won't be disabled before the issue is resolved in the V2. Thanks. ... View more

Hello,  we confirm the issue which is occurring when the "startDate" and "endDate" used in the POST Customer Invoice V2 Endpoint payload either in the Invoice Lines Array or Document Body level.   "startDate": { "value": "2021-03-08T16:23:24.691Z" }, "endDate": { "value": "2021-03-08T16:23:24.691Z" }, ERP UI > Customer Invoice > Financials Details > Invoice Period Dates (API Payload : Document Level) ERP UI > Customer Invoice > Document Details (API Payload: InvoiceLines) The same payload works as expected in POST Customer Invoice V1 Endpoint so that we recommend using V1 for this operation until the issue has been sorted out. Thank you for reporting this to us. ... View more

In the system, there is no difference between API and UI Transaction and this is also valid for the exceptions / errors. API represents a regular ERP user as it is registered with the Financial roles.  Therefore, if the same condition such as read, write, update allocation occurs then the same exception can be triggered and returned to the API. ... View more

Hello Kjetil,  To our knowledge, this kind of errors usually appear when the user has a related document open in the UI session and during that time the related document have been updated by other users or transactions. Afterward the system returns this error when the user is trying to update/delete the document without refreshing the page / session. Make sure that document is not kept open or altered during the Delete operation. Retry the operation after eliminating the aforementioned possible causes. We'd be able to investigate further if you could inform us on the exact steps / setup followed when you receive the error message.  Thanks. ... View more

Thanks. Also, what is the service plan ?  ... View more

Hello,  can you please inform us about your Outgoing IPs and Azure Region ?   ... View more

Hello Thomas,  we also encourage you to use our Ideas Section to raise your improvement requests, thus, the idea would be visible to the development team for the sprint planning and can be prioritized based on demand rate. Thanks. ... View more

Please let us know if other not exposed fields that can be found under "Credit Verification Rules" should also be reviewed. Thanks 🙂👍  ... View more

Hello thank you for your input. We'd like to clarify the desired field below so that this could help when the case is prioritized.   Reference for the Development: Customer Card "ScreenID:AR303000"  >  Credit Verification Rules  Expose following field via GET Customer Endpoint <CustomerDto> -Remaining Credit Limit ... View more

Hello Andre, as Magnus mentioned, recommended way would be dividing your request into chunks, such as 250 - 500 Line per request. [Initial POST then PUT (Insert Invoice Lines) ] Can you also please send your CompanyID & Name and  the API Client ID used in your integration ? In this way we can check our logs to see if there is anything related to the servers. Thanks. <developersupport@visma.com> ... View more

The correct definitions of the key-value pairs are represented in the Swagger Documentation for Visma.net ERP API that can be found at https://integration.visma.net/API-index/ You need to open the link  > find Sales Order POST endpoint and check Example Value information to find out correct syntax. As we've stated above, Location can not be sent in this format.  "location": { "id": "22", "name": "Fredrikstad" },   Correct format is  "location": { "value": "string" },  where you have to replace "string" with desired "LOCATION ID"  ... View more