Developer forum

Sure.

You can crate a StockLevelProvider: 

https://doc.dynamicweb.com/apix/api/Dynamicweb.Ecommerce.Stocks.StockLevelProvider.html#Dynamicweb_Ecommerce_Stocks_StockLevelProvider_FindStockLevel_Dynamicweb_Ecommerce_Products_Product_System_String_Dynamicweb_Ecommerce_Stocks_StockLocation_

The current live integration project has a StockLevelProvider - but does not support units or stocklocations. We are currently adding unit support - but locations are not taken into consideration.

You should consider not running live - but batching this.

Hi Nicolai,

Thank you for the info.

In our case, the stock location information is sensitive and should be received in the LiveProce request.

Your concerns are related to including this information in the LivePrice response or with the processing of the data into the StockMatrix?

One way or the other, we need to (at least) display this info in ProductList and ProductDetail. We can either process the data with a StockLevelProvider or map the data to a custom field and process it in the template for display purposes.

What do you think?

Thank you,
Adrian

For performance considerations - stock levels are always important, but can also cause issues - due to performance, and other stuff that gets complicated. So it is up to the gains and the losses of this. I.e. what is the consequence on conversion rates if the sites slows by ,5-1 sec because of this? Or if BC goes down? Or if BC is slow? And having live stock on solutions with some amount of traffic will not prevent 2 users from trying to purchase a product. If you update your inventory every 15 mins in batch, that would probably already be the time products sits in a cart by users. So I am arguing that you will get zero-very little better precission on stocklevels by going live compared to frequent batches of updates - but the consequence for the UX and performance will be larger of the benefit.

Most webshops in retail here in DK have things like "2 in stock in XYZ location - updated 12 mins ago". Consider a scenario where you have 30 products with 10 variants each in 5 different locations and you need to show stock level on the product list page - that would give you 30*10*5 = 1500 stock lookups for one page alone. Just the request and response sizes in that scenario would be quite large.

BR Nicolai

Hi Adrian,

I agree with Nicolai, and would like to add that Live Stock is also "an illusion" :)

Here is why:

• You'd hardly want to have orders synced immediately to the ERP once completed
  • It may be too disruptive
  • If the connection is slow, the order confirmation page is held hostage
• You also need to handle for orders that are not synced
  • Which then need to be in batch
• This means that you might as well have orders by synced just in batch - let's say every 5min for argument sake
• What this means is that the ERP itself is delayed by 5min to know their true stock
  • But DW would not because it would have been able to depleat the stock accurately once an order has been placed
  • But if Live Integration is forcing the user to see the "5min outdated stock", then you also have a problem
• Live Stock also does not allow filtering for "out of stock" products, which some customers want

So, as much as we still have customers asking for it, it's really not a good practice. I know where you're coming from, so you may be able to convince some customers out of it, but some you will not.

Hope this helps as well.

Nuno Aguiar

Hi Nuno,

Thank you very much for all the details.

I agree with both of you and I, myself, am not a huge fan of abusing LiveCalls.

This was the request I received from the customer and I wanted to know if there's some scenario for handling it decently before I go back to the customer with a suggestion.

It's clear now that we should suggest to the customer that this information should be retrieved in batch sync.

Thank you very much,
Adrian 

Hi Adrian,

In a project in DK we needed almost-live inventory numbers, but we're not doing live integration for the reasons mentioned by Nuno and Nicolai. Instead, we planned 5 minutes scheduled task with the URL Builder that first sends new orders to bc and then updates the inventory numbers in DW, both using OData (the scheduling was actually changed, I believe, but someone else on this forum can elaborate on that :) ). Then, it is disconnected from the user context, an while the synchronization is waiting to run, Dynamicweb balances its own inventory as orders arrive.

We were able to do this with the Items page as an webservice, because we just need the "Inventory on Hand" minus "Qty on Sales Orders", and OData is blazingly fast to serve the information. In your scenario, however, it is a bit more complicated, because the inventory in a specific locations is the result of a calculation and not a number that we can just pick from BC. It should probably also exlude the units that are reserved for orders to avoid overselling. So, you need someone to extend the codeunit or provide an alternative endpoint for you to fetch the information. In the specification for that you might want to include a delta possibility to only update the inventory numbers that have changed since last sync to have a lighweight sync after the order sync, and a full sync possibility to get all the inventory numbers to run a couple of times a day or whatever you see fit.

In our scenario, DynamicWeb is (usually) the only outlet, so the inventory in BC and DW should be pretty close all the time. If that is not the case in your scenario, you might condsider looking into webhooks to have the inventory updated in Dynamicweb, when an update is recorded in BC.

Br.
Lars

>> the scheduling was actually changed, I believe, but someone else on this forum can elaborate on that

Indeed. While every 5 minutes sounded nice, we ran into some timing issues where DW would have wrong stock. Consider a URL builder that does this:

1. Send open DW orders to the ERP
2. Download stock

If an order completes between step 1 and 2 you have a problem. The order wasn't completed at step 1 and is therefore not sent to the ERP. When it completes, it then subtracts the stock from the available stock in DW.

Then step 2 runs and gets the stock level. The new order is not in the ERP so you get back the previous stock level. This would then allow a customer to order a quantity that is not available anymore. The stock is wrong for 5 minutes until the job runs that sends the orders and gets the latest stock. 

We found that decreasing the frequency instead of increasing it solved the issue. The less frequent the stock import runs, the less risk of missing an order that just completed.

Imar

Hi Lars, Imar,

Thank you very much for all these details. They are very useful!

We must balance the decisions based on what the customer sees as "critical" information. At this point, we are only trying to weigh in on the options.

@Lars you have mentioned webhooks. Do we have something built in Dynamicweb or do we need to build it?

Thank you,
Adrian

Hi Adrian,

No, unfortunately not. You'll have to create the subscriber yourself and the service that accepts the notifications from Business Central. Also, there is not buit-in entity in BC for warehouse inventory, so this needs to be a built as a custom API. Here are a couple of links:

For the subscriber part: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/dynamics-subscriptions
For the custom API: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-develop-custom-api
Also, I found this article on custom APIs to be very helpful: https://businesscentralgeek.com/how-to-create-custom-apis-in-business-central

I'd encourage you to verirfy with the BC developer/consultant that they can deliver a custom API that gives you the right information before making any final decisions on that approach.

>>We must balance the decisions based on what the customer sees as "critical" information. At this point, we are only trying to weigh in on the options.

Indeed, and sometimes reducing the actual inventory for DynamicWeb by a number or percentage is sufficient, so items are not oversold in Dynamicweb.

Br.
Lars

Hi Lars,

Thank you very much for the info. It is extremely useful, not just for this project but also for future projects.

Thank you very much,
Adrian