The original issue is the following:
- Go to the journal item creation
- Choose a partner
- Add a line => the partner on the journal item is removed
This is because `partner_id` on the account move is a related to
`partner_id` on the account move lines. This is likely to cause errors
during the manual encoding of a journal item, since the relation will
link the partner of the account move to the partner of the first account
move line only.
opw-670661
1. Add an accounting configuration option
"Assets management & Revenue recognition"
2. Deferred revenue account not set by default in product
- Create new Deferred Revenue Type
- Create new product and assign this "Deferred Revenue Type"
you can see in income account there is nothing set. Actually
when we select revenue type then in income account system
have to set "Deferred Revenue Account" which we set on revenue type.
Otherwise, if we create invoice for this product then system will
by default take the income account from product category.
3. Change word Depreciation to Revenue :
The current test in landed costs puts landed costs on outgoing pickings.
It is a bit weird as they are put on incoming shipments normally. It checks
if the lines of the landed costs have been calculated well, but not if the
amounts/accounts/... on the account move and account move lines have been
calculated correctly. It should also check the entries created when some
part is already out and when we create negative landed costs. (in order to
be able to revert them)
Scenario :
- Two new products without stock as is done in current test in real-time
valuation,...
- Both products are received
- One product goes out (or a part of the quantity)
- A landed cost is created for the incoming picking
- Check that the journal items created, have the correct amounts and that there
is a part that went out and is put on the out account
- Create a negative landed cost as the first landed cost was a little bit too high
- Check again that the journal items created have the correct amounts
[FIX] account: fixed behavior in order to create the exchange rate difference entry at the full reconciliation only.
This is needed in order to support the use case where an invoice in foreign currency is paid on a bank account in company currency,
with the user encoding manually the difference due to the currency fluctuation (writeoff in the bank statement reconciliation interface): before
this patch, Odoo was doing automatically the same, what results in a duplicated currency difference booking). ticket ID: 670876.
A test has also been added in account/tests/test_reconcilication.py (test_statement_euro_invoice_usd_transaction_euro_full) to ensure that use case
is now fixed.
[FIX] account_full_reconcile: a reconciliation is full as soon as either total_debit = total_credit OR if total_amount_currency is 0
[FIX] account: when registering a payment with a writeoff, always create the writeoff line exactly as entered by the user. Before, it was modified
by the exchange rate entry, for some reason...
[FIX] account: on invoices, show the payment widget and outstanding payments in the invoice's currency always
[FIX] account: when assigning a payment in company currency on an invoice in foreign currency, save the amount_currency in order to create the correct
exchange rate.
[FIX] account: show the currency difference entry on the invoice payments widget
[FIX] account: fixed the reconciliation methods in order to work with exchange rate entries that have debit = credit = 0
[FIX] account: fixed reconciled field computation. A line is reconciled only if its amount_residual AND amount_residual_currency are 0
[IMP] display the move name of payments on the invoice payments widget
Multiple technical routes were listed in the sitemap,
and it's pointless to list them in the sitemap.
There is currently no way to exclude routes
from the sitemap using a specifc argument
(e.g. sitemap=False on the route).
Therefore, in order to remove them from the sitemap,
we play with the current conditions to exclude
these routes from the sitemap:
- routes with `auth` other than `none` and 'public`
are excluded. Technical routes marked as `auth="public"`
for no reasons are changed to `auth="user" so they
are excluded from the sitemap
- routes with required arguments are excluded as well.
the route `website/image` cannot work without any argument,
`website/image` has therefore been removed from the possible
routes for the method `website_image`, so it's no longer
listed in the sitemap.
For an exhaustive list of the conditions to exclude
a route from the sitemap, check the method
`rule_is_enumerable` in `website/models/website.py`
opw-670865
Commit 4a0b6f6 slightly improves the performances of `action_assign` by
skipping moves which already have pack operations. However, if the move
is not completely assigned, it prevents the possibility to search for
new quants to assign to the given move.
opw-672069
When adding new lines to an existing statement,
the order of the lines was not kept,
due to the re-sequencing operation done in the
override of `write` in `account.bank.statement`:
```
for statement in self.browse(cr, uid, ids, context):
for idx, line in enumerate(statement.line_ids):
account_bank_statement_line_obj.write(cr, uid, [line.id], {'sequence': idx + 1}, context=context)
```
as the lines order was based on `statement_id desc, sequence`,
which is the same for all lines added,
(except if the order is forced in the web client,
using the handle widget)
and, therefore, the order
of the lines returned by `statement.line_ids` was
not determinist.
Adding the `id` to the lines order
(as it's done in `sale.order`, for instance),
solves the issue, as the lines will then be fetched
in the order they were created.
opw-667541
The commit adds a "Refund" field on the stock move, in the module
sale_stock. This allows to decrease the quantity delivered in the
associated SO, and therefore to generate refunds more easily.
When validating a payment transaction,
if the cart (order) cannot be confirmed or
the email cannot be sent for any reason
(instance, the email template is broken),
the transaction must continue, so the payment
transaction can be set to `done` or `pending`.
In other words, not sending the confirmation
email or not confirming the sale order must
not be blocking to mark the payment
transaction as done.
opw-672486
This commit fixes two problems with the dashboard:
- The function prepare_dropdown_menu() has been removed by commit 002660,
breaking the include in dashboard.js, and thus the 'Add to Dashboard' feature
wasn't appended to the FavoritesMenu.
- The code to render the dashboard didn't correctly wait for the action
manager's deferred to be resolved, which produced a traceback when they were
a Kanban or List view in the dashboard.
Commit 7b7f3fa filters out the special periods. However, the filtering
should be done only for the display in the form view, nto for the
reporting which is actually correct.
opw-672531
In v8.0 and saas-6, the PoS does not support the concept of fiscal
position. Therefore, the invoice generated should not use it, otherwise
there might be an inconsistency between the PoS order and the invoice.
FORWARDPORT TO SAAS-6 ONLY!
Fixes#11299
opw-671743
For that, we needed to inverse the processing of the moves of the production order (first consumed, then produced
instead of the opposite) as that way we know the price to put on the produced moves based on what was consumed before.
Denis Ledoux