Currently when we have an Analytic Filter applied on an accounting
report, we lose that filter when we click on any amount to audit the
journal items.
This fix makes sure that when auditing, we only view the journal items
filtered by the Analytic Filter.
In order to do that, we extend the search function in the analytic mixin
to allow searching on analytic account ids.
task-3718751
closesodoo/odoo#161873
X-original-commit: 2e3be9726514f74ea8c0c2314c9cdfeb6ed57915
Related: odoo/enterprise#60742
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
In Spain, "Cooperativas" have their own variant of the Spanish chart of
accounts. In order to support these businesses, we add two extra CoA
templates: Cooperatives - SMEs and Cooperatives - Complete.
task-3803050
closesodoo/odoo#159357
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently some VAT examples that contain other terms than only the
number are always displayed in English. This commit makes sure they can
be translated.
closesodoo/odoo#159724
X-original-commit: 504240b8633aac91eee421f3268550a1c04142a2
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
In the beginning of 2024, the default tax of 20% in Estonia was changed
by 22% (with the 20% still supported as a legacy) [1]. With that change,
the tax report was also updated so the line previously containing the
taxable amount at 20% now contains the taxable amount at 22%.
However, the formula computing the tax amount itself was not updated to
reflect this change and was still computing the tax by multiplying the
taxable amount by 0.2.
This fix corrects the tax computation in the report.
[1] ec25405367eaeca6bdd1f54e2a09fe6b93b8a4b6
opw-3815147
closesodoo/odoo#159339
X-original-commit: 6ea02a52b2cedce70572df78ddb7142acb784886
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
After the fw-port of the fix in [1], it seems some references had
changed, breaking the translations again. This commit fixes that.
[1] 9d2f7f312c5d699b937bd5546085fc151a149a8f
closesodoo/odoo#158664
X-original-commit: d28189565f035cf2f84f7cb01137cece2bb90662
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
In the Point of Sale app, some terms were not translatable by our
translators on Transifex. In this commit we make sure that the missing
terms are either made translatable or exported in the related .pot file.
closesodoo/odoo#156929
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Due to a refactor of the code in [1], the string "Save current search"
in the filters dropdown was not translatable anymore.
This commit fixes that, so it is translatable again.
[1] 976491e012closesodoo/odoo#156946
X-original-commit: 5f1d6f26d6bfe1f23f4098eae2e0b32300adefda
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
In [1], we added a rounding of the amounts in the `<PriceAmount>` tags
to avoid floating point rounding errors. However, it seems the
`float_round` function does not guarantee to avoid these errors.
Take the example of `price_subtotal` = 250.80 and `quantity` = 3.
We will compute the PriceAmount as 250.80 / 3 which yields
83.60000000000001. Even when using `float_round(amount, 10)`, it still
results in the same amount with the rounding error.
For that reason we use the built-in `round` method of Python instead.
[1] 58d57bbbaaab32ba0183890a9182e6de09b32ac5
closesodoo/odoo#156555
X-original-commit: 0b21d562fe4d315c01421b3f242e274830c34e79
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Correct the terms in this module and translate them in Italian.
closesodoo/odoo#156502
X-original-commit: 8f4ded8ebb85e996c2fc556efd0ad080095ff82a
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
When listing jobs on the website, we show the number of open positions.
Currently the "open positions" were crafted in the QWeb template in such
a way that the translation mechanism couldn't extract it and thus it
could not be translated.
In this commit we fix that, so that it can be translated again.
opw-3761288
closesodoo/odoo#155974
X-original-commit: d19aa2e13be11cb2ce9d293c453a58f136b03712
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
*de,din5008,din5008_purchase,din5008_repair,din5008_sale,din5008_stock
After 15.0, part of the German localization modules have been moved to
the DIN5008 modules to be shared with other countries.
We migrate the translations here to the correct modules in the versions
after 15.0 and complete missing ones.
opw-3669388
closesodoo/odoo#155035
X-original-commit: 3c97b4aa3ecd0dc6f0208fd0dcdf05217748bfd6
Related: odoo/enterprise#57247
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
When invoicing public administrations, they expect the facturae
electronic invoice to contain the optional `<PaymentDetails>` node that
contains e.g. the bank account number to which they need to issue the
payment. We didn't provide these details.
This commit adds the necessary `<Installment>` nodes in the
`<PaymentDetails>` node for each installment in Odoo according to the
payment terms of the invoice.
Since we are fixing this in stable, we only add the payment details for
inbound payments and fix the `<PaymentMeans>` to `04` (Credit Transfer).
We also removed the stripping of whitespace for the signature, since it
turned out not necessary after introduced in [1]
[1] e5d69a73e2e781d00f67c0590a8fc13b09a06ebf
task-3734341
closesodoo/odoo#153931
X-original-commit: 7f88e41fb6b723c8d240344a50a5b4b8b4aa3f2f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The generated facturae files do not pass the FACe platform checks. The
platform itself didn't give us any useful information.
A feedback from the Spanish government said though:
> We detected inconsistencies with the field `<ds:DigestValue>` from the
tag `<xades: SignaturePolicyIdentifier>`
Although not explicitly mentioned, we should apparently use SHA1 for the
digest value of the Signature Policy instead of SHA256.
opw-3673349
opw-3716276
closesodoo/odoo#152720
X-original-commit: e5d69a73e2e781d00f67c0590a8fc13b09a06ebf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
In order to better analyze profitability, we added an extra measure to
the Invoice Analysis report to show the "Margin" on every invoice line
based on the product cost price.
In order to have a simplified inventory valuation without fully using
the Inventory app, we also added an "Inventory Value" measure that also
uses the product cost price to show the change in inventory value based
on incoming and outgoing accounting documents.
An extra filter "Inventory Valuation" was added as well to show the
"Inventory Value" values per storable product and per month.
task-3708415
closesodoo/odoo#151805
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
When creating a cut-off entry with an account that has a default tax
configured on it, we don't want that tax to be computed on the cut-off
entry again. Reason is both that we don't want to impact the tax report
again with these taxes, and it would also create an auto-balancing line
to balance out the computed tax on a suspense account, which is pretty
confusing to the user.
task-3650271
closesodoo/odoo#150446
X-original-commit: acf21ee79cb97470c014e0897316f0c59e2ee485
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
How to reproduce:
- Open a PoS session
- Create an order, pay it and validate
- In the same session, find the order in `Orders` (filter on Paid) and
make a full refund
- Close the session
- Open a new session and open the "refund" order in Orders
- Click the "Invoice" button to invoice this order
Observed behavior:
- We get a UserError saying the reversal entry is unbalanced, where the
credit side equals 0.00 and the credit note is not generated.
Expected behavior:
- We are able to generate the credit note correctly.
When computing the reversal entry, it seems we inverted the sign of the
quantity field of each order line when reversing a refund. However,
that did not make sense because the actual amounts are already reversed
for a refund.
task-3611296
closesodoo/odoo#147934
X-original-commit: a6b10b65e3a04ce96519edc846801304cc47f40b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Currently it's not possible to send facturae invoices through FACe,
since we did not include administrative centers in the XML.
This commit fixes that by:
- Introducing a new partner type for Administrative Centers, with the
necessary fields
- Adding all Administrative Centers linked to a partner on the facturae
electronic invoice
Since often the three required Administrative Centers (Fiscal, Receiver
and Payer) are the same, we allow the user to specify multiple roles
on an Administrative Center.
Demo data was also added for the Administrative Centers and updated to
pass the facturae validator.
For stable versions, we use a patch module to not break things.
This should be moved to the main module in master.
task-3599447
closesodoo/odoo#146675
X-original-commit: 7c4e846f023f92f48ee465008769848075757a29
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The Belgian localization has been updated to reflect the official Charts
of Accounts.
Users now have the choice between the official CoA for Companies or the
one for Associations and Foundations.
All related terms and translations have been reviewed and corrected in
the 3 official languages (nl, fr, de).
Non-official languages have been removed, since they both don't make
sense and they did not work because of targeting an ancient version of
Odoo.
Finally, the 580000 account has been set as the default Internal
Transfers account, avoiding a second 58 account to be created.
task-3086473
task-3258014
closesodoo/odoo#117480
Related: odoo/enterprise#35771
Related: odoo/upgrade#5291
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently we require the account lines `code` field to be unique across
all reports in a database. Since Reportalypse, this is not required
anymore, since we search by default only in the current report unless
we specify a `cross_report` subformula. Then it will take the first one
it finds.
In this commit, we relax the condition to have unique `code` fields per
report, instead of globally.
Furthermore, we add a test utility to check lines with the same code to
have the same properties. This is useful for localizations that have
multiple versions of the same reports, containing identical lines in
multiple report. This way we can ensure they are always calculated the
same way across reports.
task-3086473
Part-of: odoo/odoo#117480
*l10n_account_edi_ubl_cii_tests,l10n_dk_oioubl,l10n_ro_edi,l10n_sa_edi
Since some localizations use the concept of debit notes (e.g. Peru), we
need to support the DebitNote UBL type in order to make these
localizations inherit their electronic documents from the generic
`account_edi_ubl_cii` module. In order to do so, we also refactored the
current UBL structure to inherit more in order to not make the
templates too complex when adding the debit note type.
task-3415758
closesodoo/odoo#132529
Related: odoo/enterprise#46014
Related: odoo/upgrade#5131
Signed-off-by: Laurent Smet (las) <las@odoo.com>
In the context of branches, you need to be able to select taxes of
an ancestor company on an invoice/bill, even when you don't have access
to the ancestor company.
In order to do that, we relax the restriction when searching with a
`parent_of` or `child_of` on a related field, so that it also includes
ids of related field records you don't have access to. This should not
be a problem, since in the end the search will return records of a
model restricted by its own access rules.
task-3503204
closesodoo/odoo#138942
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
When a user only has access to a branch and not to the parent, he can
not create a new customer invoice or vendor bill, since we need to check
the lock date on all ancestor companies (where the user might not have
access to).
This fix allows the user to create a new customer invoice or vendor bill
again when only having access to a branch.
Furthermore, in the above case we are also unable to assign a partner on
the invoice/bill, since we are checking properties that might belong to
an ancestor company we don't have access to. We also fixed that here, so
a partner can be selected.
task-3503204
Part-of: odoo/odoo#138942
Once a branch company has some data associated with it, it can't be
deleted anymore. Since the branches could only be opened in a dialog,
it was also impossible to archive them.
In order to allow (un)archiving a branch, we added a stat button on the
company form to show the branches in a list view, where people can
(un)archive them.
task-3503204
Part-of: odoo/odoo#138942
Currently, when a user has access to a branch of a company, but not to
the company itself, the branch will not show up in the company switcher.
As a result, the user is not able to switch back to that branch when
logged in to another company.
To fix this, we now show the whole hierarchy of the branches you have
access to, disabling the companies/branches you don't have access to.
task-3503204
Part-of: odoo/odoo#138942
For PEPPOL, the Customer Reference field on invoices is a required
field. In Odoo it can be blank when creating an invoice from scratch.
In order to avoid errors when sending PEPPOL invoices, we want to
set the Customer Reference to the invoice name when no reference was
provided.
task-3499548
closesodoo/odoo#135158
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Currently it is not easily discoverable that users can install the
PEPPOL module. They have to go to the Apps list and search for PEPPOL
there.
In order to make the installation easy and discoverable, we added a
checkbox to the Invoicing/Accounting settings to install the module and
afterwards show the checkbox to enable PEPPOL per company.
The install checkbox is only shown when editing the settings of a
company that is eligible for PEPPOL to avoid confusion. In order to do
that, we created a `PEPPOL_LIST` variable in `account` containing all
countries currently allowed to use PEPPOL. The code in `account_peppol`
formerly using the `EAS_MAPPING` variable of the `account_edi_ubl_cii`
module is now also using this new list.
task-3519564
closesodoo/odoo#137287
Signed-off-by: Laurent Smet (las) <las@odoo.com>
We don't want to force anything and make clear that we have 3 solutions
the user can choose: hash, lock date and audit trail.
This reverts commit 3a5fc92c34.
closesodoo/odoo#136625
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Following new regulations in Denmark, we need to prevent users from
modifying posted entries in sales and purchase journals.
By using a forced hash on the journals we do just that.
task-3497062
closesodoo/odoo#135202
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently the tax report always opens the previous month by default.
Since tax periods are not always months, it makes much more sense to
open the previous "tax period" (whatever length it has) when opening the
tax report.
In order to allow that, this commit introduces a "This Tax Period" and
"Previous Tax Period" option for reports and sets the default period
for the tax report to "Previous Tax Period". The rest of the
functionality is done in the related enterprise commit.
task-3481913
closesodoo/odoo#133715
Related: odoo/enterprise#46601
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When trying to drop an invoice on a journal on the journal dashboard,
it fails with a message "Could not upload files". The issue is that
commit 6f95be6884 changed a CSS class
where the upload functionality depended on, making it fail.
This commit fixes this issue by adapting the CSS selector of the upload
field.
task-3496997
closesodoo/odoo#134965
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Add helper functions to check structured communication references for
ISO (existing), Belgium, Finland, Norway and Sweden.
task-3284330
closesodoo/odoo#122835
Related: odoo/enterprise#41629
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
After feedback on the new branch management feature, there were a few
bugs reported. This commit solves several of them:
- Display the company/branch name of a reconciled payment in the info
popover when viewing customer invoices and vendor bills. This way you
can see why you don't have access to the payment e.g.
- Make it possible to select the taxes of the parent company when
creating moves in a branch.
- Allow users with only access to a branch to open the Accounting app.
The dashboard would fail with a security error before.
task-3461421
closesodoo/odoo#134000
X-original-commit: 92d261d9a3f64fcbb01023e680d362b598061707
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Since the relational model JS refactor in
d4fe919db5, we are unable to create new
branches of companies.
The required field `partner_id` (which is created in the model's
`create` method), was set as `required="0"` on the form view, but not on
the list view. After the relational model refactor, when merging the
modifiers of the field in both views, it is considered required. When
trying to save a new branch, it thus complains that the `partner_id`
field is empty.
Setting the `required="0"` modifier on the list view solves the issue,
making the `partner_id` not required anymore for the JS form dialog.
task-3461421
closesodoo/odoo#133488
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Currently when unlinking moves, we check whether the dates of these
moves are not before a lock date. If so, we show an error to the user.
However, if the move is not posted, we have no reason to show an error,
since unlinking an unposted move, even before a lock date, is a valid
operation. This change only checks the lock date for posted moves.
opw-3305506
closesodoo/odoo#128701
X-original-commit: 1d18a5e4aaa254eba2b12cf1bae19ac2cc4c3c6f
Related: odoo/enterprise#44199
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Since 7bd93cc64b, we add the amounts to
invoice from sales order to the credit limit warning. When looking at
the credit amount on a partner from an accounting perspective, it is
not correct though that sales orders to invoice are considered as well.
In this change we split the credit amount from invoices and from sales
orders to invoice. On the partner we only show the credit amount from
invoices. In other places we add both.
task-3375260
closesodoo/odoo#128158
X-original-commit: 94eae9b73995dbf2175ecee65548ace5a382f5f8
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Currently when saving a miscellaneous journal entry, we always recompute
the taxes and modify them to be exactly as calculated by us.
However a user could also modify taxes based on a document he got from
a supplier, where the tax might be 1 cent off.
Before this change: On save, we recompute the taxes and override the
user's modification.
After this change: If the user manually modified the taxes, we don't
touch them anymore on save.
task-3262448
closesodoo/odoo#127166
X-original-commit: 8752013127160334c1690518586531fabd6d3f18
Signed-off-by: William André (wan) <wan@odoo.com>
By default all the draft moves that are not the first one in a period
get the name `/`, indicating it is in draft. In the UI the name field
is then just an uneditable `Draft` placeholder.
When quick edit mode is activated, we always show the text field for
move names to allow users to edit the sequence number beforehand.
However for all abovementioned draft moves, it would show `/` in the
text field, requiring the user to first delete that symbol before
entering the right sequence.
This commit makes sure the names of draft moves without a sequence
number are empty (no `/`), so that in the UI the text field can be
filled out immediately and a placeholder `Draft` is shown.
task-3326827
closesodoo/odoo#124186
X-original-commit: 83a7daa07fedcaeddb983a94a86e4c7a187915d9
Signed-off-by: William André (wan) <wan@odoo.com>
* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Currently, when we create a draft move in an empty period, a sequence
number (name) gets generated and set on the move. This is fine.
When subsequently we change the date of that move to a period that
already has entries in it, the sequence number (name) for our draft move
is recalculated according to the new period.
When we post a new move in this same period afterwards, and then
delete our previous draft move, we are left with a gap in the sequence.
Example: We already have a move on 2023-01-01 with name `2023/01/0001`.
We add two new moves `A` and `B` as follows.
| Step | Move | Action | Date | Name |
| ---- | ---- | ----------- | ---------- | -------------- |
| 1 | `A` | Add | 2023-02-01 | `2023/02/0001` |
| 2 | `A` | Change date | 2023-01-10 | `2023/01/0002` |
| 3 | `B` | Add | 2023-01-15 | `/` |
| 4 | `B` | Post | 2023-01-15 | `2023/01/0003` |
| 5 | `A` | Delete | | |
A gap is now created, since we have `2023/01/0001` and `2023/01/0003`,
but `2023/01/0002` was deleted (possible since it was in draft).
To solve this issue, we now make sure that when a draft entry is moved
to a period that already has entries in it, we reset the name to `/`,
to not consume a sequence number and prevent possible gaps in the
sequence later on.
task-3326834
closesodoo/odoo#123329
X-original-commit: 31f94b31b820799459ad70593abb74a2f5415b47
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
After the removal of the `balance` line in payment terms in 16.2, the
behavior was not the same as it was before when using a fixed line.
Example: $ 1000
| Amount | Type | Example Value |
| ------ | ------- | ------------- |
| 50 | Percent | $ 475 |
| 50 | Fixed | $ 50 |
| 50 | Percent | $ 475 |
We used to remove the fixed lines, then split the remaining amount
according to the percentages, and finally insert the fixed lines again.
Since this behavior is both different than before (where we had a
balance line) and not clear to the user, we changed it so that the last
line in a payment term (no matter the type) is behaving as a balance
line. After this fix, our example looks as follows.
Example: $ 1000
| Amount | Type | Example Value |
| ------ | ------- | ------------- |
| 50 | Percent | $ 500 |
| 50 | Fixed | $ 50 |
| 50 | Percent | $ 450 |
task-3270971
closesodoo/odoo#122552
X-original-commit: 1bc73bc9daff4fa9d88739ba49382971f2077e3f
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
English term changed in source. Dutch and French via Transifex.
task-3193776
closesodoo/odoo#117789
X-original-commit: 8225fcfe0de231788952ec4c9f6d0eabdc387aa5
Related: odoo/enterprise#39372
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The current algorithm to match vendor bills with purchase orders was written
while keeping in mind that the vendor bill data came from an OCR scan and was
thus not very detailed or totally reliable.
The current algorithm tries to match in this order:
1. Document reference(s) match(es) one or more purchase orders and the total
amounts of the bill and the purchase order(s) match as well.
2. Document reference(s) match(es) one or more purchase orders and the total
amount of the bill matches a subset of lines in the matched purchase order(s).
3. Document reference(s) match(es) one or more purchase orders but the amounts
do not match.
4. No document reference, but the vendor and total amount of the bill matches
exactly one purchase order.
When we generate a vendor bill from an EDI document (electronic invoice), we do
have very accurate information however and can also match line by line, since
our vendor bill will contain separate lines.
In this commit we add an extra algorithm specifically for EDI documents:
* We find all purchase orders matching the vendor bill reference(s)
* For every vendor bill line (having a unit price), we try looking in our
matched purchase orders' lines for the same unit price and a remaining
quantity higher than or equal to what is in the vendor bill. If multiple matches
are found, we check the name similarity and take the most similar line.
* We replace the vendor bill line with the purchase order line, changing the
quantity to the one on the original vendor bill line.
* Unmatched vendor bill lines remain untouched.
We also remove matching method 2 (see above) for EDI documents, in favor of the
new algorithm.
This approach makes that more purchase order lines will be able to get matched
when using EDI documents.
task-3140712
closesodoo/odoo#112684
Related: odoo/enterprise#37061
Signed-off-by: Laurent Smet <las@odoo.com>
In the partner form, when you change the state of the partner address and the country remains the same, it still triggers an update on the country field.
This change makes sure that the country is only updated when it has actually changed.
task-3143841
closesodoo/odoo#111230
Related: odoo/enterprise#36386
Related: odoo/upgrade#4277
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Since 16.0 the `Tax ID` field label is dependant on the company country.
For the US we chose `EIN` as the label.
Since there are multiple sources of tax ids in the US, it is better to leave it as the default: `Tax ID`.
task-3162675
closesodoo/odoo#112561
X-original-commit: f6846f5b9dcae6a0a9e26f3b847593a2e8a3222b
Signed-off-by: William André (wan) <wan@odoo.com>
Taxes in Luxembourg have been reduced until the end of 2023: 17% -> 16%, 14% -> 13% and 8% to 7%.
This change remaps the OSS tax mappings for Luxembourg to the new tax rates.
task-3159138
closesodoo/odoo#111286
X-original-commit: e7edd71a3a4d8d7297c07f44b6b701052f2c5b7d
Related: odoo/enterprise#36477
Signed-off-by: Josse Colpaert <jco@odoo.com>
In the forward-port to 15.0 of https://github.com/odoo/odoo/commit/b4cd54a3c9227370667913ff2e170e24539c6328 the migration folder was renamed from 5.1 to 15.0.5.1, which causes the forward-port to 16.0 to not take into account this migration.
This change renames the folder back to 5.1, such that the migration will run in 16.0 as well.
Related to task-2993087
closesodoo/odoo#111280
X-original-commit: 86343618a4d6bd7f8e30c30fefdc0f1c2c73f315
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Currently the Spanish address format does not include the province/state.
This change adds the province between parentheses after the zip code and city.
task-3147965
closesodoo/odoo#111012
X-original-commit: 2c31ad84137b3a764116bea6a6d765a2c7d03eb7
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
For companies having a Chart of Accounts that inherits from an ancestor CoA linked to the taxes, the current tax update script did not work.
This change also supports this case.
X-original-commit: 45aae69c20d40467d64af4c7e4f0b45b7832b89c
Part-of: odoo/odoo#110841
Previously, when copying a report with top-level aggregation lines that reference other top-level lines, the codes in the aggregation formula where not correctly replaced.
This commit solves the issue, so reports can be correctly copied.
closesodoo/odoo#104632
X-original-commit: 94a524a1be42e2128b291a2357a637ddef4cce6b
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Currently, when you create a "Cut-Off" entry on an account move line of an invoice or bill, the analytic distribution set on the original line is not copied to the automatically created account move lines.
This fix solves this issue by copying the original analytic distribution.
closesodoo/odoo#103119
X-original-commit: d8bc4175268ebde615902524f3ac7c25e2cf0c17
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The analytic distribution widget in the Analytic Distribution Model form displayed its selection field on a new line, making it too large and odd. This PR fixes the styling and simplifies the widget.
closesodoo/odoo#103282
X-original-commit: 73b11378b18a709537dff5b60373b40009a04a14
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Currently, when posting accounting entries from an expense report, the accounts set on the expense entries were not taken over in the account move lines. Also, the employee was not set as the vendor of the purchase receipt (account move).
This PR makes sure that both the accounts on the expenses, as well as the vendor (employee) is set on the account move created from an expense report.
Tests added as well.
closesodoo/odoo#103037
X-original-commit: 066c70e483b2f49ae48cb98ddc412014f4fe258a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Dylan Kiss (dyki)