Here's the sequence of calls with partial relevant payloads using scenario similar to original post but with quantity of 20.   1. Get balance from Visma: GET /inventorysummary/1007   [{ "inventory": { "number": "1007"}, "warehouse": {"id": "1 "}, "location": {"id": 147}, "available": 20, "availableForShipment": 20, "onHand": 20, "baseUnit": "STYCK", }]    2. Decrease balance in Visma to zero: POST /InventoryIssue   { "date": {"value": "2023-08-28T06:41:04.5923895+00:00"}, "hold": {"value": false}, "description": {"value": "Stock take"}, "externalReference": {"value": "Stock take"}, "issueLines": [ { "warehouseId": {"value": "1"}, "unitCost": {"value": 0}, "tranType": "Issue", "operation": "Insert", "lineNumber": {"value": 1}, "inventoryNumber": {"value": "1007"}, "locationId": {"value": "1"}, "quantity": {"value": 20}, "reasonCode": {}, "description": {"value": "Stock take"} } ] }   Response: { "totalAmount": 360, "controlAmount": 360, "issueLines": [ { "transactionType": "Issue", "warehouse": { "id": "1 ", "description": "Huvudlager" }, "unitCost": 0, "extCost": 0, "unitPrice": 18, "extPrice": 360, "project": { "id": "X", "description": "Non-Project Code." }, "lotSerialNumber": "", "allocations": [ { "lineNbr": 2, "location": { "id": "1", "name": "Standard" }, "lotSerialNumber": "", "quantity": 20, "uom": "STYCK" } ], "lineNumber": 1, "inventoryItem": { "number": "1007", "description": "Item 1007, Green" }, "location": { "id": "1", "name": "Standard" }, "quantity": 20, "uom": "STYCK", "description": "Stock take", "branchNumber": { "number": "1", "name": "Bitlog Nordic AB TEST" } } ], "referenceNumber": "1800055", "status": "Balanced", "hold": false, "date": "2023-08-28T00:00:00", "postPeriod": "202308", "externalReference": "Stock take", "description": "Stock take", "totalQuantity": 20, "controlQuantity": 20, "lastModifiedDateTime": "2023-08-28T08:41:06.587", "branchNumber": { "number": "1", "name": "Bitlog Nordic AB TEST" }, "metadata": { "totalCount": 1, "maxPageSize": 1000 } }    3.  Releasing: POST /InventoryIssue/1800055/Action/Release   Response: {"actionId":"2f8eef46-2d12-420c-a078-5f6c09611c21","actionResult":"InProcess"}    This is where processing of our first transaction completes and the second transaction gets processed short after.   4. Get balance from Visma: GET /inventorysummary/1007   [{ "inventory": { "number": "1007"}, "warehouse": {"id": "1 "}, "location": {"id": 147}, "available": 0, "inIssues": 20, "onHand": 20, "baseUnit": "STYCK", }]    Note that OnHand is still 20 and this is what we compare our balance to and adjusting it in Visma if needed.   There is no difference between out two systems (20 vs 20), so we don't perform any actions. Had we made the same call in a couple of seconds, Visma would release the issue and OnHand would be zero. Thus my suggestion was to include InIssues in calculating the balance. The only problem I've encountered with that is that sometimes I've seen issues not being released if they were incorrect, thus balance will still get out of sync.   Cheers, Oleg                 ... View more

Thanks Yıldırım,   One important note. We consider WMS to be the Master of stock balance, not the ERP, so we never adjust our balance, we adjust balance in Visma. This is done for the obvious reasons, coz we have people on the floor and they've just counted what is on stock, and we are just reporting it back to Visma.   Otherwise, I had the same idea of putting some breaks for a couple of seconds before sending the second transaction, but this will require us to change our business logic, and that is costly and might be difficult to implement.   I'll share your response with my team and see if we can accept it as a solution.   Best regards, Oleg & Bitlog ... View more

Hi Yıldırım,   I believe we could share some thoughts on the subject before starting to look into any specific client/payload. I have looked into the Swagger documentation and responses we are getting and I believe I can see solution to our problem, I just need you to confirm that our thoughts are pointing us into the right direction.   What we are looking to when comparing stock balance in our (WMS) and your (ERP) systems is the onHold value from the Inventory Summary endpoint, but I think we have to consider even inIssues, inReceipts as well as inTransit values. As your documentation says on for example the inIssues value is:    "The quantity of the stock items included in the inventory issue documents that have not yet been released"   This value increases when we post the first transaction to ERP and if our second transaction is sent shortly after, the balance we have to consider should be:   onHold + inIssues + inReceipts + inTransit   Please confirm my theory. I can send you all the calls and payloads if we have to dig deeper.   Cheers, Oleg ... View more

Additional info: It doesn't work on my MacBook, not in Chrome nor in Safari. Calling it from Postman gives the following error:   You need to enable JavaScript to run this app   JavaScript is enabled in my Chrome.       ... View more

Actual call and result:   https://integration.visma.net/API/controller/api/v1/KitSpecifications?kitInventoryID=10256&revisionID=01 { "pageNumber": 1, "pageSize": 5000, "totalCount": 1, "records": [ { "kitInventoryID": "10256 ", "revision": "01", "description": "test", "isActive": true, "allowComponentAddition": false, "isNonStock": true, "stockComponentLines": [ { "lineNbr": 1, "componentID": "10 ", "componentQty": 2.0, "uom": "STYCK", "allowComponentQtyVariance": false, "disassemblyCoeff": 1.0, "allowComponentSubstitution": false, "description": "Komponent 1" }, { "lineNbr": 2, "componentID": "11 ", "componentQty": 3.0, "uom": "STYCK", "allowComponentQtyVariance": false, "disassemblyCoeff": 1.0, "allowComponentSubstitution": false, "description": "Komponent 2" } ]}]}   I've even noticed that we are getting the tag kitInventoryID instead of kitItemID as defined in the Swagger documentation. ... View more

As I said in my initial post, we are getting this strange response in our customer's company. Company ID: 2951933   In our own company this is working fine. The call is made from a C# client. ... View more