Increase the distinction between a journal entry linked to a bank
statement line and another one linked to a payment by adding a smart
button linked to them.
Also improve the navigation from the Bank And Cash view to directly
open the linked bank statement line or payment.
Task id #2448618closesodoo/odoo#65316
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Go to Accounting (module)> Accounting (menu) > Journal Entries
- Create a new account move M
- Remove the default journal
Bug:
Impossible to set a journal
opw:2445553
closesodoo/odoo#65200
X-original-commit: cd1823a1066dd9a820afed8427e3a9abc2faade0
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In 13.0, some account.move.line fields (amount_currency, debit, credit
and account_id) couldn't have a value when the line is of type 'note'.
Skiping them during line copy for notes is not an issue.
During 12.0->13.0 migration, we were facing issues with "grouped similar
invoice lines in a single move line", because this feature is not
available anymore in 13.0. To avoid any "loss of data" during migration,
we used lines of type note to create "missing" invoice lines in move
lines without altering accounting in any way. As a consequence, we have
13.0 databases with lines of type note having values for fields who
couldn't have ones.
closesodoo/odoo#64962
X-original-commit: 677edafeaf8d691764178f5e7e9639017b0249a8
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
To fully allow f4e67d8ae174d7e2ee75a1de1083b31a6ff2af8b
we need also to disable to check on account when
the constraint field has been used to set the account on
the journal
opw-2394959
closesodoo/odoo#64792
X-original-commit: 655597e9a3637abbaeffddcc78663e8733070db4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Install "Accounting" module
- Create a new bill :
- Set vendor
- Set no payment reference
- Set a bill reference
- Add products to bill
- Confirm and click on Register Payment
Memo field has no value.
Cause
The memo field is based on lines name.
Lines name is computed in `_onchange_payment_reference`
and depends only on payment_referecence.
Solution
If no `payment_reference`, fallback on `ref` to set line name.
opw-2440389
closesodoo/odoo#64692
X-original-commit: 31bc04afc3ed4ea74cd20f71ea10943b1026629c
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This use case can happen in case an invoice is imported without recreating all the taxes, only keeping the VAT information.
closesodoo/odoo#64638
X-original-commit: 7ad61842c703ceb031b2f917ad8bbc26d7d0b780
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287
closes#62536closesodoo/odoo#64627
Related: odoo/enterprise#15031
Related: odoo/upgrade#1983
X-original-commit: 4e8581b6846ef8ee4601c994b0d586734a4fe117
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- keep track of to_check changes in chatter
- add "set as checked" button
- make the "to_check" field optional in list view
- vendor bill / customer invoice : remove "entry" from "cancel entry" button.
Task: 2389849
When posting an account move before the tax lock date, Odoo will
automatically set its accounting date to the lock date + 1.
This can cause the chronology to be broken, which is not something we
want when automatically setting the date.
This will change that behavior to set the accounting date to today in
such case.
Task id #2411150closesodoo/odoo#62787
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a new sales journal;
- Start creating a new invoice using the new journal (the name/sequence
will be editable) and before saving, change the journal to the
old one;
Before this commit, the invoice will be on the old journal and will have
the new journal name/sequence and after validate the invoice all the new
invoices on the old journal will have the new journal name/sequence.
Now, when you change to the old journal the name of the invoice came
back to 'Draft'.
opw-2415975
closesodoo/odoo#64146
X-original-commit: 3b64640076af472b64a72c7061696772d0e118de
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
The Python constraint method `_check_unique_sequence_number` performs an
SQL query, and therefore needs to `flush()` the some fields before doing
so. However, it uses a generic call to `flush()`. In some situations,
the call to `flush()` ends up into recursive flushing, and that's the
beginning of a nightmare:
- write on account.move.state,
- which calls account.move._check_unique_sequence_number(),
- which calls flush(),
- which computes purchase.order.line.qty_invoiced,
- which reads field purchase.order.line.invoice_lines,
- which calls flush() for account.move.line.move_name,
- which computes account.move.line.move_name,
- which computes account.move.name,
- which calls account.move._check_unique_sequence_number(),
- which calls flush(),
- which computes purchase.order.invoice_status,
- which uses the not-yet-computed value of purchase.order.line.qty_invoiced,
and computes an incorrect value.
We fix it simply by making the call to `flush()` more specific: we only
need to flush 4 fields. This avoids the nightmare above.
X-original-commit: cf5f50a733ddfd87985a39ffe7daffc48cfb582f
As the price_unit and the uom rounding can be more detailed than the currency/accounting rounding (2 decimals as a standard) to cut the number before subtotal is wrong.
closesodoo/odoo#63817
X-original-commit: 1b4005f50ac45b53a73e0b95cfb661e8ccf040cd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Using group of taxes with type_tax_use='none' children messed up the sign of the tax_base_amount and line tags.
closesodoo/odoo#63479
X-original-commit: 3642c429899c4d5def27c9ba10ae76c763a8a566
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
If you have a move line which was having tag_ids before and you apply a new tax
which has no values defined and result in an empty list, the assignment does not work on a x2m field,
so we do offer the proper notation for such a use case.
Closes#62934closesodoo/odoo#63176
X-original-commit: f7cbbe381950699f2aeb26c454a4a955ed3bf2b4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
Issue
- Install 'Accounting' module
- Create a new 'Tax' X with a fixed price (e.g.: O.O57 $)
- Create a new 'Customer Invoice'
- Add a product P and set unit price to 0 $
- Set tax X to product P
Total tax amount : - 0.06 $ .
Solution
The sign must be forced to a negative sign in case the balance is on credit
to avoid negatif taxes amount.
enterprise PR : https://github.com/odoo/enterprise/pull/15035
opw-2378978
closesodoo/odoo#62758
X-original-commit: 684855529e8aaafa0cb90f958d19c563d6e2a897
Related: odoo/enterprise#15105
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287
closesodoo/odoo#62536
Related: odoo/enterprise#15031
Related: odoo/upgrade#1983
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Activate Anglo-Saxon accounting
- Set a foreign currency rate to 2.0
- Create a product A:
Inventory Valuation: 'Automated'
Costing Method: 'Standard Price'
Cost: 10.0
Public Price: 100.0
- Create an invoice in foreign currency
- Add 1 unit of A => the total amount is 200.0
- Confirm the invoice
The Amount Due is 100.0 instead of 200.0.
This happens because the Anglo-Saxon lines have the company currency,
while the other lines have the foreign currency. Because of this, the
`_compute_amount` method considers the move as multi-currency to compute
the various amount. However, the Anglo-Saxon lines should be neglected.
This happens from 14.0 because all lines have a currency. In previous
versions, lines in the company currency didn't have the `currency_id`
set.
opw-2390107
closesodoo/odoo#62657
X-original-commit: 9e1aec7873a935b287b4b3c5dbc2688acee5422a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In order to avoid eventual futur issues, this PR add a filter on the
journal field of journal entries to only allow selecting misc journals
task id #2371198closesodoo/odoo#62331
X-original-commit: 1b273d4c11e3e8d8583de302b71b2522a71f4d1d
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Fiscal positions shouldn't be deleted if used by existing account moves
closesodoo/odoo#62443
X-original-commit: 6b2d0faf170f7b5061f5facbaa3818e529a2de4c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
when a Vendor bill in an inactive currency is created (via an an EDI or the OCR,
or when the user create the invoice in an active foreign currency, then desactivate it)
it should not be possible to validate it.
Task ID: #2289537closesodoo/odoo#54096
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The partner is not visible in the form so copying can lead to unwanted
behaviours.
Task 2389917
opw-2388430
closesodoo/odoo#62276
X-original-commit: ef1b3332a523f0afdb954f8eb2abb8f442bdca58
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
- Install Invoicing
- Go to Invoicing > Configuration > Taxes
- Create a Tax 0% with its own tax group
- Go to Invoicing > Customers > Invoices
- Create an Invoice with a line having a normal Tax and several lines with Tax 0%
- Confirm and print Invoice
On the Subtotal section of the printed invoice, for the label of the Tax Group of Tax 0%,
only the amount of the first line having this tax is shown.
(i.e. "Tax 0% on $ XXX", where XXX should be the sum of all lines on which Tax 0% is applied)
opw-2381051
closesodoo/odoo#62106
X-original-commit: 9e244ae3053f46fc22b8e9a75015d57cd70053b8
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Before this commit, if a customer/supplier has an invoice address, when
creating an invoice/bill it's the invoice address that will be
identified as the customer/supplier and that will have its rank
increased and not the commercial partner.
Now, the rank increment is done to the commercial partner as well.
opw-2377870
closesodoo/odoo#61778
X-original-commit: dbf042611ccb134a220704d6b775aab650364ca2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Create a tax as follows:
* Tax Computation: Percentage of Price Tax Included
* Tax Scope: Purchase
* Amount: 100%
* Included in Price
* Affect Base of Subsequent Taxes
Create a vendor bill with the tax on the line
Change unit price
The total does not change
This occur because when having 100% tax debit/credit are unchanged.
So the onchange `_onchange_mark_recompute_taxes` is not triggered and
the tax lines are not updated, thus not changing the
total (as in this case the invoice total is just the tax value)
opw-2370861
closesodoo/odoo#61555
X-original-commit: 9e203cc016b45875f699ffab24fe3f8382a97303
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
We extract the `price_unit` and `tax_ids` recomputation logic from the
`_onchange_product_id` method. This way, it can be called
programmatically.
opw-2371934
closesodoo/odoo#61477
X-original-commit: ca6f25bef45137c032bc5cafd336c3f16a97a929
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The order to find when to reset the sequence needs to be the following:
* find a sequence used before the date of this move
* if there isn't any, find the sequence of any move
Because we were not looking at the second step for bank statements, we
could have an issue since we were not checking the sequence relative to
the correct date.
closesodoo/odoo#61495
X-original-commit: b863b9cfedb3e7b4d1e3d409c829ffa0bfa1d9bb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
We need to ensure the name stays consitent with the journal_id and the
date when we try to change one of those fields.
X-original-commit: 634aaeeac36d2371743338536466a0bcc9ad6c69
When the invoice is fully reconciled but not using payments, set the 'paid' status on invoices.
closesodoo/odoo#61339
X-original-commit: 052324cca4ec8682f065a4158e86fc113b0242e0
Related: odoo/enterprise#14590
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Steps to reproduce the bug:
- Create a vendor bill VB1 with one line L1
- Set an analytic account AA on L1
- Post VB1
- Create a new vendor bill VB2
- Set VB1 on the field Auto-complete
Bug:
The created line L2 on VB2 had no analytic account
PS: In 12.0, the analytic account was kept when using Auto-complete field
opw:2359432
closesodoo/odoo#60962
X-original-commit: 5f46c50442dbe42bc534718719a6b19ee087eab0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Co-authored-by: smetl <las@odoo.com>
When the exchange difference journal entry shouldn't be created, don't check its configuration in order to avoid an UserError in single-currency company.
closesodoo/odoo#61047
X-original-commit: 3ab451f3c4ce8dd42337f43628c1335d2caee011
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Use of '_for_xml_id' instead of read in order to avoid
access right issue on 'ir.actions.act_window'.
closesodoo/odoo#60946
X-original-commit: 4e65fbf14491ea97415ede6d10385222c8d4d074
Signed-off-by: ndeodoo <ndeodoo@users.noreply.github.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this, misc operations always used the balance of the base line as the tax_base_amount of the tax line. This was inconsistent with the invoices, for which we invert its sign when making a sale invoice or a purchase refund (as for those operations, positive amounts are put in credit). This commit should make everything behave in the same way.
closesodoo/odoo#60912
X-original-commit: 2ca3158ce2de596526067dbd86da2ef7d4ae85bd
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
* Analytic defaults keep their old value
* The date_maturity is non-sense, it isn't set on lines needing analytic
* Analytic default should work for misc. operations too, but only for
product/service lines on invoice documents.
closesodoo/odoo#60904
X-original-commit: 4d2b8dd1bef40c592215728fab6c31f192176e93
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
When switching immediate payment term to 30% advance then back to immediate payment term, the receivable line is back to its previous value.
This is due to the '_get_fields_onchange_balance' that is not updating correctly the business fields since price_subtotal == amount_currency.
So, when `writing`, debit/credit are removed from the dictionary because the values are the same as before. However, `price_unit` hasn't be updated with the new value and remains as its previous value.
It leads to a recomputation of accounting fields regarding the business fields and then, trigger the unbalanced journal entry.
closesodoo/odoo#60654
X-original-commit: 18b5ad16a442404061b1028c2ffd82f179beaba3
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
A tax line could have something in the `tax_ids` field.
Then, these condition needs to be inversed in order to not handle them as base lines.
closesodoo/odoo#60473
X-original-commit: eada9f91f3361f8335c23b3a27161803cfda6608
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Behavior before the fix:
- if you create a sales order for a customer invoice address (a child
partner record), then create the invoice for that order, the partner_id
is not consistent between the move_line (some get the child partner id,
some get the commercial partner id = the parent partner id)
- if you create the invoice directly from the accounting app for a
child partner, the commercial partner id is used consistently for all
move lines (the invoice itself keeps the child partner id)
Behavior after the fix:
- when an invoice is created from a sales order, the partner id is set
using the commercial partner id, consistently for all lines (in this way
the behavior is consistent with that of the accounting app)
It is more appropriate to use the commercial_partner_id for this purpose
as it is used pretty consistently in the account_move file
opw-2347878
closesodoo/odoo#60302
X-original-commit: cd299518ae45f2732d47788869b013be16b814e8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Currently the onchange is setting the price_unit to the price_subtotal to work out the proper price unit related to the tax, but does not have a different line quantity in mind.
The update of the price_unit was raising a balance difference UserError which is now resolved by the fact that we only update the price_unit if it is affected
OPW-2362066
closesodoo/odoo#60256
X-original-commit: 8c8d803992c31ba68a12801fa6dd4dcf909d9ed9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Suppose two price_included taxes: 10%, 20%, a product having a sale price of 110.0 and a fiscal position tax 10% => tax 20%:
When onchange_product_id is called, the price_unit is computed as follow:
110 / 1.1 = 100
100 * 1.2 = 120
So price_unit = 120 and balance = 100.0
But in onchange_uom_id, we do the same thing and we call _get_fields_onchange_balance_model with balance=100.0.
However, in this method, an empty dictionary is returned because price_subtotal == balance.
Then, {}.get('price_unit', price_unit) will return the original price_unit (110.0) instead of the new computed one (120.0).
closesodoo/odoo#60108
X-original-commit: f2a5476c52c1312d3dfc558f92b4a678d6aa5e25
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
As-is, the warning will reports that post() is called from within
post, which is not very convenient when trying to find what calls
post() (as there are other "post" methods in the system).
By increasing the stacklevel from 1 (default) to 2, the warning will
report the method's caller, which is a lot more useful.
closesodoo/odoo#60043
X-original-commit: 5bc6eb9b387112138ac118726ff746bad6d00f8d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Nicolas (vin)