Developer forum

Hi Chris,
I can not reproduce that. Could you check if you do not have any other extensions installed that can override the default Dynamicweb app in BC?
Are you using new prices feature ON in BC or OFF(default)? Is it when OrderCreate in the request is true or false or in both cases? Can you try with request with just one order line in it?
BR, Dmitrij

Hi Dmitrij

There shouldn't be any custom extensions, that should override default behavious on orders.

New prices feature is "ON" on this client.

This case only happens when "CreateOrder" is false. If "CreateOrder" is true we get the correct response.

The same issue occurs when there's only 1 order line in the cart.

BR Chris

Hi Chris,
I still can not get it produced. I've used BC 18.0.27224.29496 + Application 18.3.27240.27381 version on cloud sandbox
and docker image with BC Platform 18.0.22295.0 + Application 18.0.22371.0.
Have you tried different products/customers? Maybe stock/inventory amount can somehow imact this or something else.
What is your exact BC version?
BR, Dmitrij

Hi Dmitrij

BC version is NAV18.0.27224.29496 so same as yours.

I have tried with different customers and different products. Also I tried the stock/inventory angle to test if this was happening on products with low stock, but it doesn't seem that there's a connection to that. Funny thing I noticed is that it still counts the order totals correctly. I have this example with a product, where I put 10 in the cart, and I get this request:

Response from BC is this:

So order line total is correct because there's the product line and the discount line (514,7 - 76,69) gives 438,01 returning the expected total price for the order line. But the order line quantity seems to always be 1 here.

I have also tried to send a unitID on the order line to see if this should cause the issue, but that does not seem to have any impact as well. Any ideas?

BR Chris 

Hi Chris,
it looks like the OrderLineUnitPriceWithoutVat is also not as expected, since it should be 10 times lower.
So it looks like BC has applied some its own mess on the sales line when it was calculated by it. Maybe you have some specific option activated in it?
Can you try to test just on a new sandbox with default properties? Have you tried different Currency, remove any other units and keep just default?
Can you send full request and a screens of your customer/product and Sales & Receivables Setup pages (make a video/etc)?
I still can not get it reproduced.
BR, Dmitrij

Hi Dmitrij

You are right, it seems that unit price is also messed up. Funny thing is that this only happens when calculating order/sales line, but not when creating the order in BC. Also the issue started to occur after upgrading to 1.2.0.17.

We are testing on a customer sandbox, which I don't have access to, so can't set up a new sandbox with this specific version.

Problem seems to be the same on different currencies and also on products with only one unit price.

I will send you the screenshots when I get them from the client, you'll receive them on mail, as they contain business specific information.

BR Chris

Hi Chris,
this issue is connected with the "Sales & Receivables Setup" 
"Default Item Quantity"  option. Can you set it to OFF and check?

BR, Dmitrij

Hi Dmitrij

I can confirm that it works when this option is set to OFF. Nice found.

The customer uses this field to optimize manual creation of sales orders in BC, so we can disable it while using the sandbox but not on live. Any idea on how to overcome this issue or is there a planned fix?

BR Chris

Hi Chris,
yes, it will be fixed in the next version, but I am not sure when it will be released. It can probably be on the end of next week or in two weeks.
If you can install some custom extension for a temporary fix then I can provide you some AL code that can solve this issue by putting this Option to ON/OFF during
the CalculateOrder requests.
BR, Dmitrij

Hi Dmitrij

We already have extensions implemented in code, so if you have the EventSubscriber to use and some code, we can implement this temporary fix for our clients.

BR Chris

Hi Chris,
then this is the code that should help you:
Use the 
OrdersPublisher: Codeunit DynamicwebOrdersPublisher;
and subscribe to:
CalculateOrderOnBeforeSetSalesLines
and
OnAfterCalculateOrder
events.

In CalculateOrderOnBeforeSetSalesLines:
var
SalesSetup: Record "Sales & Receivables Setup";
begin
        SalesSetup.Get();
        if SalesSetup."Default Item Quantity" then begin
            SalesSetup."Default Item Quantity" := false;
            SalesSetup.Modify();
        end;
end;

In OnAfterCalculateOrder
var
SalesSetup: Record "Sales & Receivables Setup";
begin
        SalesSetup.Get();
        if not SalesSetup."Default Item Quantity" then begin
            SalesSetup."Default Item Quantity" := true;
            SalesSetup.Modify();
        end;
end;

BR, Dmitrij

Thank you for this. We will work with this until next version of code unit

Hi Dmitrij, 

Do you know the timeline for this fix? :) 

Hi Mads,
the next release is planned after the 19.0 version of BC is released (which is scheduled on the 1st of October), so it should be available in a week after the 4th of October.
BR, Dmitrij

Hi Mads,
the new version of the app 1.2.0.18 is now available on the MS AppSource so you can try it.
BR, Dmitrij

Hi Dmitrij, 

Seems like the client is unable to install code unit version 1.2.0.18 - can you confirm this is ready for use? 

Hi Mads,
it is for BC19 version.
I've tried the setup on the BC cloud sandbox: if I've the BC version 18.* I can only install the 1.2.0.17 app, after I installed the BC 19.* I can install 1.2.0.18 version from the MS app source.
What is your BC version and its type cloud/on-prem? How are you installing from app source or by downloading the app from the doc site?
Also there should be an information about your app install found in Extensions->Manage->Deployment status window:

BR, Dmitrij

Hi Dmitrij, 

The client is running on BC18 cloud - and the client says BC19 is only available for on-prem. But from what I can understand from your comment, you have been able to upgrade to BC19 cloud and afterwards upgrading code unit to .18 version? If yes, please let me know the steps and I can sent it directly to the client. 

br, Mads 

Hi Mads,
no, I have to delete mine old sandbox environment and create a new instead since the update is not available. Maybe the update feature from BC will come soon, but I don't know for sure.  I've found this article about the updates so it should probably be available at Octoer 15 or so.
BR, Dmitrij

Hi Dmitriy, 

After the code unit upgrade, the functionality is now working for the calculate cart - however, when an order is submitted to BC the order is created by multiplying the quantity

So cart calculate unitprice * sales unit --> 2,24 * 500 = 1120 DKK (this is correct)

But when the order is created, the sales order becomes (2,24*500)*500 = 560.000 DKK

It is the same solution as Chris and I have mentioned in the above example. 

Please prioritize this as it is very critical. 

(please send me you email if you would like to test on the solution)

Hi Mads,
I can not get it reproduced. Maybe you have some other custom subscribers/extensions that can break the order creation?
Maybe you have some specific settings ON?
Can you also check by make a new Sales order inside D365BC and insert the same order lines and compare the output of the order calculation in BC and Dynamicweb extension?

Can you try to test it on a clean cloud sanbox environment using this sample request?
<?xml version="1.0" encoding="utf-16"?>
<tables version="1.2.0.20_NAV18.0.29486.31726">
  <table tableName="EcomOrderLines">
    <item table="EcomOrderLines">
      <column columnName="OrderLineProductNumber"><![CDATA[1896-S]]></column>
      <column columnName="OrderLineProductVariantId"><![CDATA[]]></column>
      <column columnName="OrderLineId"><![CDATA[10000]]></column>
      <column columnName="OrderLineQuantity"><![CDATA[10]]></column>
      <column columnName="OrderLineType"><![CDATA[0]]></column>
      <column columnName="OrderLinePriceWithoutVat"><![CDATA[25,976]]></column>
      <column columnName="OrderLineUnitPriceWithoutVat"><![CDATA[2,597.60]]></column>
      <column columnName="OrderLinePriceWithVat"><![CDATA[31,171.2]]></column>
      <column columnName="OrderLineUnitPriceWithVat"><![CDATA[3,117.12]]></column>
      <column columnName="OrderLinePriceVat"><![CDATA[5,195.2]]></column>
      <column columnName="OrderLineUnitPriceVat"><![CDATA[519.52]]></column>
      <column columnName="OrderLinePriceVatPercent"><![CDATA[20]]></column>
      <column columnName="OrderLineUnitPriceVatPercent"><![CDATA[20]]></column>
    </item>
    <item table="EcomOrderLines">
      <column columnName="OrderLineProductNumber"><![CDATA[]]></column>
      <column columnName="OrderLineProductVariantId"><![CDATA[]]></column>
      <column columnName="OrderLineId"><![CDATA[]]></column>
      <column columnName="OrderLineQuantity"><![CDATA[1]]></column>
      <column columnName="OrderLineType"><![CDATA[1]]></column>
      <column columnName="OrderLinePriceWithoutVat"><![CDATA[12,988]]></column>
      <column columnName="OrderLineUnitPriceWithoutVat"><![CDATA[12,988]]></column>
      <column columnName="OrderLinePriceWithVat"><![CDATA[15,585.6]]></column>
      <column columnName="OrderLineUnitPriceWithVat"><![CDATA[15,585.6]]></column>
      <column columnName="OrderLinePriceVat"><![CDATA[2,597.6]]></column>
      <column columnName="OrderLineUnitPriceVat"><![CDATA[2,597.6]]></column>
      <column columnName="OrderLinePriceVatPercent"><![CDATA[20]]></column>
      <column columnName="OrderLineUnitPriceVatPercent"><![CDATA[20]]></column>
    </item>
  </table>
  <table tableName="EcomOrders">
    <item table="EcomOrders">
      <column columnName="OrderShippingMethodName"><![CDATA[]]></column>
      <column columnName="OrderCreated"><![CDATA[TRUE]]></column>
      <column columnName="OrderId"><![CDATA[101046]]></column>
      <column columnName="OrderCurrencyCode"><![CDATA[]]></column>
      <column columnName="OrderDate"><![CDATA[11/05/21]]></column>
      <column columnName="OrderPaymentMethodName"><![CDATA[BANK]]></column>
      <column columnName="OrderCustomerName"><![CDATA[Trey Research]]></column>
      <column columnName="OrderCustomerAddress"><![CDATA[Parkvej 44]]></column>
      <column columnName="OrderCustomerAddress2"><![CDATA[]]></column>
      <column columnName="OrderCustomerCity"><![CDATA[Atlanta]]></column>
      <column columnName="OrderCustomerCountryCode"><![CDATA[DK]]></column>
      <column columnName="OrderCustomerEmail"><![CDATA[]]></column>
      <column columnName="OrderCustomerFax"><![CDATA[]]></column>
      <column columnName="OrderCustomerPhone"><![CDATA[]]></column>
      <column columnName="OrderCustomerZip"><![CDATA[]]></column>
      <column columnName="OrderDeliveryName"><![CDATA[Hr. Nicolaj Karlsen]]></column>
      <column columnName="OrderDeliveryAddress"><![CDATA[]]></column>
      <column columnName="OrderDeliveryAddress2"><![CDATA[]]></column>
      <column columnName="OrderDeliveryCity"><![CDATA[]]></column>
      <column columnName="OrderDeliveryCountryCode"><![CDATA[DK]]></column>
      <column columnName="OrderDeliveryEmail"><![CDATA[]]></column>
      <column columnName="OrderDeliveryFax"><![CDATA[]]></column>
      <column columnName="OrderDeliveryPhone"><![CDATA[]]></column>
      <column columnName="OrderDeliveryZip"><![CDATA[]]></column>
      <column columnName="OrderPriceWithVat"><![CDATA[15,585.6]]></column>
      <column columnName="OrderPriceWithoutVat"><![CDATA[12,988]]></column>
      <column columnName="OrderPriceVat"><![CDATA[2,597.6]]></column>
      <column columnName="OrderSalesDiscount"><![CDATA[0]]></column>
    </item>
  </table>
</tables>
BR, Dmitrij

Hi Dmitrij, 

Thanks for quick response - I can see that you are also running code unit 1.2.0.20 while we are running 1.2.0.19. 

I´ll turn back in case it is still an issue.

Hi Mads,
that is because 1.2.0.20 is not yet released, it is mine local latest version, but it doesn't have any changes regarding CreateOrder procedure.
So it works the same as 1.2.0.19
BR, Dmitrij

Hi Dmitrij

We have talked with the client, and comparing the way that orders are created in their BC with the problem we have with code unit, I think we found a way to replicate this.

The problem occurs when a product in BC has a base unit and Default Sales Unit that is different. So for example, if a product base unit is "PC" but the default sales unit is "PACKET" and a packet is the equivalent to 500 base units (pieces). At the same time the setting "Default Item Quantity" is set to "ON". 

In newer code unit (v. 1.2.0.17 and up) if XML reguest from DW has an empty "UnitId", then code unit will not return the XMLNode for "UnitId". I believe this is a logic tied to the fact that there was some issues with previous versions, where the integration would cause duplicate order lines (this forum post https://doc.dynamicweb.com/forum/integration/integration/live-integration-issue-when).

This would mean, that unless we specifically include the "UnitId" field in the XML, then there would be no "UnitId" returned from code unit. This works as intended on calculate. Problem occurs if we send an empty "UnitId" to BC on a product like described above (different base and sales quantity), then BC would create the order with the default sales quantity, resulting in the case described in previous post. This is where we send Quantity=500 in XML with no UnitId meaning 500 base units. BC will interpret it as 500 default sales units, which would then give 25000 base units, with the example described above.

We have found a work around in code ourselfes combining different notification subscribers, so the problem is fixed for this client, but we wanted to share the information found on this.

BR Chris

Hi Chris,
Thank you for the feedback, we will look to get it fixed.
BR, Dmitrij