Developer forum

Hi Adrian, 

I have reproduced this and created bug number 34125. It awaits priority.

Kind regards,
Merethe

Not sure this is a bug.... You have X configurations of Y items in the cart. It is probably not a good idea to change how this works.

Hi Nicolai,

I believe what any user will expect is that a quantity increase or a Configured product will also increase the quantity of each part in the combination.

The reason for that is the stock should be affected for every order.

That's why I think this is a bug or at least an undesired behavior.

Thanks,

Adrian

Hi Adrian

Yes, except no users expected this yet - and it has been sitting there for 12 years :-). If you want to display the total qty of items in the cart, simply multiply the numbers in the template.

I am pretty sure that if you order 2 BOM products, each bom item will be deducted 2xqty per item in the BOM. If that is not the case, that will be an issue.

BR Nicolai

Hi Nicolai,

The problem is not in the template. It is in the order moved over via integration. The parts are individual codes that need to be added to picking list and subtracted from stock.

I am almost sure I have seen this problem before and it was solved at some point. I might be incredibly wrong though. You definitely know it better, but I don't see how a user will expect this behavior.

Thanks,

Adrian

Hi Nicolai, Just to be clear what I mean, here are some dumps. Order details from the interface and from the database directly. You will see that the BOM product has a quantity of 2 while the orderlines related with it have a quantity of 1.

I hope this clarifies it.

Thanks,

Adrian

I understand what you mean. And it is by purpose....

You could have a bom that is 2 of item Y and 1 of item X or you could have the same BOM item with different amounts of the same items. It is not a bug.

You have to deal with it in the integration instead. Or do a notification subscriber after ordercomplete that does the math.

Hi Nicolai,

I have to admit that we are in disagreement.

If I define a BOM product to use different products that are also sold as individual items, I would expect that every order for a BOM product to affect the inventory of each BOM Item accordingly.

I will give you an example from another project that will be affected by the above logic mentioned by you.

We have a customer selling lingerie. They can have a BOM product formed of a Bra and a Bikini with different sizes. The BOM Items, are also sold separately.

If a customer will order 2 sets (BOM Products) with the same BOM Items, I would expect the inventories of the individual BOM Items to be decreased with 2 units, not just with 1 unit.

Would you say that the current solution would honor the above scenario?

Thanks,

Adrian

Hi Adrian,

Do the price calculations work correctly in that case? Are you using the BOM line for the price, or is the price already included in the main product?

As long as price and stock are still accounted for in the Dynamicweb platform itself, then I agree with Nicolai that this method works. What Nicolai is saying is that X sets of the product have been ordered, and each set has Y items in it. I suspect that it also makes other calculations easier by just raising and lowering the main product without having to adjust the calculations on the BOM lines each time. 

This is assuming that the price and stock is calculated correctly in the platform, which I assume that it is.

Scott

Hi Scott,

The price seems to be correctly calculated when you multiply the BOM product. The orderline details of the BOm product itself are correctly calulated and incremented but the indivisul orderlines of the BOM Items are frozen to a quantity of 1 no matter how many units of the BOM Product you add.

On CRS I could not check if the stock is decreased correctly because the stock is retrived from NAV. But the individual quantities sent for each BOM Item to NAV are 1. I would have not noticed that if Ryan and James wouldn't have noticed that the order that arrives in NAV is inconsistently calculated in terms of quantity.

I agree that if the calculations for stock and price are correct in DW, I should not care what quantity is stored in the orderline of the individual BOM Items.

Adrian

Hi Adrian,

In that case, it sounds like it's workable. The BOM quantity could have been done one of two ways, but since it was done this way and we know the rules now, we just need to accommodate for that. 

We do need to get the total quantity for the BOM items for the ERPs though since it does it the other way. That can be done in the live integration before sending to the ERP, or in the CodeUnit (NAV).

As for stock, that's harder to test. For this project, we don't reserve stock in the ERP for ecom carts. So it's not too big of a deal. If we were curious to know for sure, we could test this in a standalone site to confirm stock quantities.

Scott