COD fee not calculated directly

[zolthan]

If cash on delivery is the only payment method, the fee is not calculated until I have agreed the AGB and reload the page (or click on the payment method title).

The order is calculated and saved correctly. But the order preview in the checkout is wrong.

[PHOENIX-MEDIA]

Do you use some kind of custom checkout? I was not able to reproduce the problem with the core Magento checkout process.

[stalica]

I also have the same problem, although I have three other methods of payment, so it is not their number that is a problem. When changing the method of payment, the payment sometimes does not appear (you can see 0.00), or does not want to disappear from the summary when choosing, for example, a bank transfer. Magento 2.1.10, original checkout.

[josecoelho509]

Have you checked your log files yet?

With me it has worked perfectly I am using Magento 2.2.3 and I use Checkout Mageplaza. And to complicate I have a blockage of this payment for other postal codes and it has always worked perfectly

[zolthan]

We have no customizations in the checkout. As long as we have the conditions active, we have to agree to the conditions and then click on the payment method. Afterwards the fee is displayed. If no condition is active, we also have to click on the payment method.

Which kind of logs do you need?

[PHOENIX-MEDIA]

Can you look at your JavaScript network console and look for a call to the cart totals (for logged in users it is going to the cart/mine/totals REST API)? There should be one with the correct values returned.

[zolthan]

Now I have some more payment methods. It is not reproduceable when the fee is not calculated. Sometimes the AJAX call to totals returns the correct value, sometimes 0. The only thing I do is changing the payment method to force the ajax call.

Working example (date | Tue, 10 Apr 2018 15:08:54 GMT) {"grand_total":65.44,"base_grand_total":79.34,"subtotal":53.61,"base_subtotal":53.61,"discount_amount":0,"base_discount_amount":0,"subtotal_with_discount":53.61,"base_subtotal_with_discount":53.61,"shipping_amount":6.83,"base_shipping_amount":6.83,"shipping_discount_amount":0,"base_shipping_discount_amount":0,"tax_amount":13.9,"base_tax_amount":13.9,"weee_tax_applied_amount":null,"shipping_tax_amount":1.57,"base_shipping_tax_amount":1.57,"subtotal_incl_tax":65.94,"shipping_incl_tax":8.4,"base_shipping_incl_tax":8.4,"base_currency_code":"PLN","quote_currency_code":"PLN","items_qty":2,"items":[{"item_id":339,"price":26.81,"base_price":26.81,"qty":2,"row_total":53.61,"base_row_total":53.61,"row_total_with_discount":0,"tax_amount":12.33,"base_tax_amount":12.33,"tax_percent":23,"discount_amount":0,"base_discount_amount":0,"discount_percent":0,"price_incl_tax":32.97,"base_price_incl_tax":32.97,"row_total_incl_tax":65.94,"base_row_total_incl_tax":65.94,"options":"[]","weee_tax_applied_amount":null,"weee_tax_applied":null,"name":"Produkt 15 kg"}],"total_segments":[{"code":"subtotal","title":"Suma cz\u0119\u015bciowa","value":65.94},{"code":"shipping","title":"Wysy\u0142ka i obs\u0142uga (DHL - GoGreen)","value":6.83},{"code":"cashondelivery","title":"Op\u0142ata za p\u0142atno\u015b\u0107 przy odbiorze (bez podatku)","value":5},{"code":"cashondelivery_incl_tax","title":"Op\u0142ata za p\u0142atno\u015b\u0107 przy odbiorze (z podatkiem)","value":5},{"code":"tax","title":"Podatek","value":13.9,"extension_attributes":{"tax_grandtotal_details":[{"amount":13.9,"rates":[{"percent":"23","title":"PL - 23%"}],"group_id":1}]}},{"code":"grand_total","title":"\u0141\u0105cznie","value":79.34,"area":"footer"}]}

The next call is not working (date | Tue, 10 Apr 2018 15:09:00 GMT) {"grand_total":60.44,"base_grand_total":74.34,"subtotal":53.61,"base_subtotal":53.61,"discount_amount":0,"base_discount_amount":0,"subtotal_with_discount":53.61,"base_subtotal_with_discount":53.61,"shipping_amount":6.83,"base_shipping_amount":6.83,"shipping_discount_amount":0,"base_shipping_discount_amount":0,"tax_amount":13.9,"base_tax_amount":13.9,"weee_tax_applied_amount":null,"shipping_tax_amount":1.57,"base_shipping_tax_amount":1.57,"subtotal_incl_tax":65.94,"shipping_incl_tax":8.4,"base_shipping_incl_tax":8.4,"base_currency_code":"PLN","quote_currency_code":"PLN","items_qty":2,"items":[{"item_id":339,"price":26.81,"base_price":26.81,"qty":2,"row_total":53.61,"base_row_total":53.61,"row_total_with_discount":0,"tax_amount":12.33,"base_tax_amount":12.33,"tax_percent":23,"discount_amount":0,"base_discount_amount":0,"discount_percent":0,"price_incl_tax":32.97,"base_price_incl_tax":32.97,"row_total_incl_tax":65.94,"base_row_total_incl_tax":65.94,"options":"[]","weee_tax_applied_amount":null,"weee_tax_applied":null,"name":"Produkt 15 kg"}],"total_segments":[{"code":"subtotal","title":"Suma cz\u0119\u015bciowa","value":65.94},{"code":"shipping","title":"Wysy\u0142ka i obs\u0142uga (DHL - GoGreen)","value":6.83},{"code":"cashondelivery","title":"Op\u0142ata za p\u0142atno\u015b\u0107 przy odbiorze (bez podatku)","value":0},{"code":"cashondelivery_incl_tax","title":"Op\u0142ata za p\u0142atno\u015b\u0107 przy odbiorze (z podatkiem)","value":0},{"code":"tax","title":"Podatek","value":13.9,"extension_attributes":{"tax_grandtotal_details":[{"amount":13.9,"rates":[{"percent":"23","title":"PL - 23%"}],"group_id":1}]}},{"code":"grand_total","title":"\u0141\u0105cznie","value":74.34,"area":"footer"}]}

I tested it 8 times between Tue, 10 Apr 2018 15:08:31 GMT and Tue, 10 Apr 2018 15:09:00 GMT. The calls 5 and 8 didn't work. The rest gave me the correct result of 5 PLN.

Sorry for the polish example ;-)

This issue seems to be related to the beginning of issue #10 (before it turned being a question for HTML rendering).

[PHOENIX-MEDIA]

Polish is not the problem. I am not fluent in Unicode, though. ;)

Anyway, can you check the payment method associated with the order when the calculation is done? The payment method setting is its own call, maybe this does not work properly.

[zolthan]

URL: https://test-live-pl.example.de/rest/example_pl_pl/V1/guest-carts/4f8bab3d969583f384d0b35dccf20e49/set-payment-information

POST Data {"cartId":"4f8bab3d969583f384d0b35dccf20e49","email":"sakjdlhg@asdh.de","paymentMethod":{"method":"phoenix_cashondelivery","po_number":null,"additional_data":null},"billingAddress":{"countryId":"PL","region":"","street":["sadkljh"],"company":"","telephone":"1290873","postcode":"12-345","city":"sadkjlh","firstname":"askdjh","lastname":"askldj","prefix":"Pan","extensionAttributes":{"checkoutFields":{}},"saveInAddressBook":null}}

RESPONSE true

What exactly do you need? The calls are exactly the same. Sometimes the fee is just not returned in the totals call and thus not displayed. In the quote table the correct value is in the columns for COD.

Now I avoided the unicode :D

[zolthan]

Anything new here?

[zolthan]

@PHOENIX-MEDIA could you have a look into it?

[tcubukcu]

Is there anyone there?

[zolthan]

Yes, I am here and still waiting for a bugfix...

[juliankoehn]

Having the same issue but i am using the iways paypal plus extension with the default checkout

[sonline]

For me .. this resolved my/this problem

https://github.com/PHOENIX-MEDIA/Magento2-CashOnDelivery/pull/16

[zolthan]

Hi @PHOENIX-MEDIA , is there any news about the issue?

[ayusun]

hi @PHOENIX-MEDIA any update on this. In my case querying /totals results in null as COD value. Attaching the image

[mklooss]

It quiet does not make sense, but the issues is persistent.

It looks like it depends on the "Checkout Agreements". When i checked no Agreements the Value is "0" (also in the JSON result), when you check the Checkboxes (Yes "Checkout Agreements")

The Values will be calculated o.O

DE: Die Berechnung findet nur statt wenn die "AGB" bestätigt wurden.

[ahentea]

Hi,

The issue is cause from what I gather because of the set-payment-information post method is completed after the get totals method, so what happens is that the totals will bring the values for the previously selected payment method. Magento2 using a asynchronous module definition both request will be made almost simultaneously and sometimes (or on slow systems always) the get will be completed faster than the set as you can notice in the first image underneath: Wrong:

Right

For me as a temporary solution for now I did the following: Overwritten the core /module-checkout/view/frontend/web/js/action/get-totals.js with my own /Magento_Checkout/web/js/action/get-totals.js Why this file? Here the get total request for the values is made. And the temporary solution that i came up with is delaying this request for a really short time in order for the set method to have more time for completion.

define([
    'jquery',
    '../model/quote',
    'Magento_Checkout/js/model/resource-url-manager',
    'Magento_Checkout/js/model/error-processor',
    'mage/storage',
    'Magento_Checkout/js/model/totals'
], function ($, quote, resourceUrlManager, errorProcessor, storage, totals) {
    'use strict';

    return function (callbacks, deferred) {
        deferred = deferred || $.Deferred();
        totals.isLoading(true);
       //The bigger the value , the fewer chances of getting the issue
        var checkDelay = 50;

        setTimeout(function () {

            return storage.get(
                resourceUrlManager.getUrlForCartTotals(quote),
                false
            ).done(function (response) {
                var proceed = true;

                totals.isLoading(false);

                if (callbacks.length > 0) {
                    $.each(callbacks, function (index, callback) {
                        proceed = proceed && callback();
                    });
                }

                if (proceed) {
                    quote.setTotals(response);
                    deferred.resolve();
                }
            }).error(function (response) {
                totals.isLoading(false);
                deferred.reject();
                errorProcessor.process(response);
            }).always(function () {
                totals.isLoading(false);
            });

        }, checkDelay);

    };
});

This will reduce the chances of having wrong total values but it will not eliminate this possibility. As a proper method of solving this issue will be to make the getting of the values dependent on the completion of the setting of the selected payment method For the @PHOENIX-MEDIA , the issue resides here phoenix/module-cashondelivery/view/frontend/web/js/view/payment/method-renderer/phoenix_cashondelivery.js More exactly:

setPaymentInformation(null, paymentMethod); getTotals([]);

The second function should be called depending on the first one

P.S. Since the totals are used only for the aside order summary, this issue will not affect the submitted order values.

[Adr79]

Any news about this issue? We are experiencing the same and do not know what to do... Can ahentea provide a step by step workaround guide to fix the issue?

[hdk]

as mklooss commented [on 28 Sep 2018] it depends on all checkout agreements (the ones beeing defined in stores->terms and conditions) beeing checked. The CoD fee will only be added if the agreements of CoD payment method are checked, and even worse: the fee will not be removed if one selects a different payment method afterwards. Leaving the checkout page will then on return crash the shop (2.2.7) in the Klarna extension with "Order line totals do not total order_amount" making the checkout unavailable until you get rid of the active quote. (the CoD fee will then be added on return before one can select a payment method ..)