Monday, May 4, 2026
4 changes · saas-18.3
Resolved issues and error corrections
This update ensures correct processing of invoices from KSeF (a Polish tax system) by requiring vendors to use the Polish NIP number instead of VAT numbers. This is a regulatory requirement for foreign companies with a Polish presence, and the change corrects a previous system error that was incorrectly searching for VAT numbers. This ensures compliance and accurate invoice import.
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039 Forward-Port-Of: odoo/odoo#261964
This update resolves an issue where the EC Sales Report exported to KVR (a key reporting tool) displayed decimal values instead of the required integer format for Swedish tax reporting. The fix ensures that all sales report values are rounded to integers before export, complying with Swedish reporting regulations. This prevents data discrepancies and ensures accurate reporting.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115459 Forward-Port-Of: odoo/enterprise#114292
This update resolves an issue where Amazon's stock synchronization was failing due to incorrect fulfillment channel data. The system now uses a new API field to accurately determine available stock by channel, defaulting to FBM when multiple channels are present. This ensures reliable stock updates for Amazon listings.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#114473
This update resolves an issue where referenced refunds in Viva.com were incorrectly reversing payments. A recent update mistakenly removed a key data field, causing this problem. This fix restores the necessary data, ensuring refunds work as intended and preventing payment reversals.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr