When you change the address on the order page, the amount of the Payment block also changes. #34751

Activity

1. AudaceV

   added

   BugType: BugType: Bug

   NewNew issue not yet processed by QANew issue not yet processed by QA

   on Dec 1, 2023
2. AudaceV commented on Dec 1, 2023

   

   AudaceV

   on Dec 1, 2023

   Author

   More actions

   I'm forgot... The order must be "payment accepted"...Obviously :) (before to change another address)
3. AudaceV

   closed this as not plannedon Dec 1, 2023
4. AudaceV

   reopened this on Dec 1, 2023
5. ShaiMagal commented on Dec 3, 2023

   

   ShaiMagal

   on Dec 3, 2023

   Contributor

   More actions

   @AudaceV New (changed) address is from same country/state or different?

   If different, maybe it's this settings:
   "Shop Parameters" - "Order Settings" - "Recalculate shipping costs after editing the order"
6. AudaceV commented on Dec 4, 2023

   

   AudaceV

   on Dec 4, 2023

   Author

   More actions

   Hi,

   thanks for your response!
   The country/state is the same.
7. florine2623 commented on Dec 4, 2023

   

   florine2623

   on Dec 4, 2023

   Contributor

   More actions

   Hello @AudaceV ,

   I can't reproduce your issue using the same order as you.

   Screen.Recording.2023-12-04.at.10.18.59.mov

   I'm closing te issue to avoid clogging the backlog.
   Thanks!
8. florine2623

   closed this as completedon Dec 4, 2023
9. florine2623

   added

   InvalidResolution: issue closed because invalidResolution: issue closed because invalid

   and removed

   NewNew issue not yet processed by QANew issue not yet processed by QA

   on Dec 4, 2023
10. AudaceV commented on Dec 4, 2023

    

    AudaceV

    on Dec 4, 2023

    Author

    More actions

    Hi @florine2623,

    like wrote before: The order must be "payment accepted"...Obviously :) (before to change another address)
    Please, check again!
11. AudaceV commented on Dec 4, 2023

    

    AudaceV

    on Dec 4, 2023

    Author

    More actions

    Hi @florine2623,

    NOT SOLVED!

    like wrote before: The order must be "payment accepted"...Obviously :) (before to change another address)
    Please, check again!
12. MatShir commented on Dec 4, 2023

    

    MatShir

    on Dec 4, 2023

    Last edited by MatShir

    Contributor

    More actions

    So once the order is paid we should not update price :/
    I'm wondering if it is a new behaivor or just an old bug
13. MatShir

    reopened this on Dec 4, 2023
14. 15 remaining items

    Load more
15. florine2623

    added

    9.0.xBranchBranch

    ReadyStatus: Issue is ready to be worked onStatus: Issue is ready to be worked on

    and removed

    9.0.xBranchBranch

    on Dec 7, 2023
16. MatShir commented on Dec 7, 2023

    

    MatShir

    on Dec 7, 2023

    Contributor

    More actions

    If it concerns only demo product, I'm putting the severity to trivial. But if a member of the community can reproduce it for new orders we could increase the severity

    👍React with 👍1Reacted by florine2623
17. MatShir

    added

    TrivialSeverity: trivial bug > https://build.prestashop.com/news/severity-classificationSeverity: trivial bug > https://build.prestashop.com/news/severity-classification

    and removed

    MinorSeverity: minor bug > https://build.prestashop.com/news/severity-classificationSeverity: minor bug > https://build.prestashop.com/news/severity-classification

    on Dec 7, 2023
18. github-actions commented on Mar 23, 2026

    

    github-actionsBot

    on Mar 23, 2026 – with GitHub Actions

    Contributor

    More actions

    👋 Hi there,

    Thank you for opening this issue. We've noticed that this issue has been open for more than 547 days with no recent activity. We want to keep our issue tracker focused and up to date.

    Is this issue still relevant to you?

    • If yes, please leave a short comment below (you or anyone else) to confirm that it's still relevant. We'll then remove the "stale" label and keep the issue open.
    • If we don't hear back, we'll assume the issue is no longer needed. A grace period of 30 days will apply from this message. After that, the issue will be automatically closed.

    We appreciate your contribution and understanding. 🙏
19. github-actions

    added

    Stale

    on Mar 23, 2026
20. github-actions commented on Apr 23, 2026

    

    github-actionsBot

    on Apr 23, 2026 – with GitHub Actions

    Contributor

    More actions

    🔒 This issue has been automatically closed because there was no response or activity after it was marked as stale and the 30-day grace period has ended.

    If you believe this issue is still relevant, please feel free to reopen it and add a comment explaining why. We're happy to take another look.

    Thank you for your participation in this repository.
21. github-actions

    added

    Stale Action Closed

    on Apr 23, 2026
22. github-actions

    closed this as not plannedon Apr 23, 2026
23. Hlavtox

    reopened this on Apr 29, 2026
24. github-actions

    removed

    Stale Action Closed

    Stale

    on Apr 30, 2026
25. boo-code commented on Sep 2, 2026

    

    boo-code

    on Sep 2, 2026

    Contributor

    More actions

    @AureRita's observation — reproduces on the preregistered orders but not on new ones — has a concrete cause: four of the five demo orders ship with a total_paid that contradicts the rest of their own row.

    From install-dev/fixtures/fashion/data/orders.xml, checking each order against its own siblings:

    id          products_wt  ship_incl  disc_incl   expected  total_paid  paid_incl   ok?
    orders_1          59.80       8.40       0.00      68.20       61.80      68.20   MISMATCH
    orders_2         169.90       0.00       0.00     169.90      169.90     169.90   OK
    orders_3          12.90       8.40       0.00      21.30       14.90      21.30   MISMATCH
    orders_4          12.90       8.40       0.00      21.30       14.90      21.30   MISMATCH
    orders_5          18.90       8.40       0.00      27.30       20.90      27.30   MISMATCH
    

    The gap is exactly total_shipping_tax_incl - 2.00 every time, and orders_2 — the only order with no shipping — is the only consistent one. The same query against a shop installed from these fixtures returns the same numbers, so it is the data, not the installer.

    Editing the order then runs OrderAmountUpdater::updateOrderTotals(), which recomputes total_paid from the cart and stores the consistent value. Nothing about the address needs to change for the figure to move — the stored value was simply never equal to what the order adds up to. Orders created through the front office or the back office are consistent from birth, which is why they do not reproduce it.

    Worth knowing for whoever fixes it: PrestaShop/ui-testing-library's src/data/demo/orders.ts encodes the same wrong figures, and 02_filterOrders.ts:121 filters the orders grid by dataOrders.order_4.totalPaid, so the fixture and the library have to change together. That file also says 69.90 for OHSATSERP where the fixture has always said 169.90.