b2be451c7ce6184d54a3e1f74781dc24e37cf1a2
Use case specifically for round globally, but the justifications hold anyway Have a session with one tax, multiple partners, and returns of freight (negative amounts) When validating a pos.session, the computation of amls was a bit out of logic, Namely, we grouped tax lines by : 1. their tax id (correct) 2. their partner_id (not wrong but limited) 3. their balance > 0 (wrong) The justification for point 2 and 3 is two fold: - Ultimately, the order is level of granularity that really makes sense It's the order that is paid and therefore that has both legal and business meaning and on which the amounts are retrieved anyway - On the order, we litterally make the sum of tax amounts of each line, aggregating credit and debit under the same variable It is only logic to do the same for grouping the taxes at validation time This commit only corrects the behavior for the rounding method 'globally' OPW 1865700 closes #26203
…
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, Purchase Management, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
Then follow the developer tutorials
Languages
Python
49.6%
JavaScript
47.8%
SCSS
2%
CSS
0.3%
HTML
0.2%