Stock take issue

[olesko]

We have encountered a problem while sending our stock take results back to Visma and need some advice on how to handle it.

Our WMS system keeps the stock balance per InventoryNo, WarehouseId and BinNumber. In case a user reports a stock discrepancy on a bin, we are calculating a total stock balance per InventoryNo and WarehouseId in our WMS and comparing it to stock balance in Visma using InventorySummary

endpoint, and we are sending eventual difference back to Visma via InventoryReceipt or InventoryIssue endpoint depending on if it's a positive or negative difference.

All this works fine except for one scenario, when user report let's say -10 pieces on bin A and +10 pieces on bin B. This results in two internal transactions in our system that are reported back to Visma within a very short period of time, which we believe causes the following issue.

Stock balance in Visma: 10

Transacton 1:

Get balance from Visma: 10

WMS balance: 0

Difference: -10

Call to Visma:  InventoryIssue 10

Transacton 2:

Get balance from Visma: 10

WMS balance: 10

Difference: 0

No calls are made to Visma

From what I understand, it takes time for Visma to process the first transaction and thus, we are still getting the "old" stock balance of 10 during our second transaction. If the second transaction is processed in say 10 seconds or so, we will send an InventoryReceipt for 10 pcs to Visma and stock balance between our systems will be in sync.

Can you give us any advice on how to tackle this problem?

Oleg

[Yıldırım]

1) "Available" or "OnHand" : The quantity of the stock items available at the specific warehouse and location. 
I think first you can fetch this value from the Inventory Summary to compare WMS <> Visma ERP. 

2) Then, based on ERP company flow, (Either Receipt or Issue) you can check, InIssues & InReceipts. 
Considering,ERP Company released the documents, put some delay such as up to 5 seconds (This may vary depending on the size of the document so that how long the initial document release operation takes in the system)

3) After getting the value, update your WMS accordingly.

Note: You can also check new https://salesorder.visma.net/swagger/index.html (Inventory Endpoint) for the same operation to see if that endpoint provides more parameters. Performance wise, the new endpoint should be better than the current endpoint. 

---------------------------------------------------------------------------------------------------------

onHand:
The quantity of the stock item available on hand at the specified warehouse and location.

inIssues: 

The quantity of the stock item included in the inventory issue documents that have not yet been released.

This quantity affects the available quantity only if the Deduct qty. on issues option is selected for the item class in the Item classes (IN201000) window.

inReceipts:

The quantity of the stock item included in the inventory receipt documents that have not yet been released.

This quantity affects the available quantity only if the Include qty. on receipts option is selected for the item class in the Item classes (IN201000) window.

inTransit:

The quantity of the stock item included as in-transit quantities in the inventory transfer documents that have not yet been released.

This quantity affects the available quantity only if the Include qty. in transit option is selected for the item class in the Item classes (IN201000) window.

---------------------------------------------------------------------------------------------------------

[olesko]

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

[Yıldırım]

Hei Oleg, I see your point, then could you also share your requests with urls and possibly payloads for POSTs, so that maybe we can figure out something else. Thanks ! 

(It'd be great If you could specify the transaction order & flow )

[olesko]

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

[olesko]

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

[Yıldırım]

Hei Oleg, sounds like a plan, but first I'd like to establish a such flow in our test company and have a couple of test runs before confirming that It'd serve the purpose. 

I'll get back to you soon.

[Yıldırım]

Hello, sorry for the late reply, could you please send your request details to developer@visma.com ? 

-Request Flow with Operation URLs & Payloads

-Ipp-company-id
-API ClientID 

Thanks.