- Create a bank statement for a negative amount, e.g. -100.
- Click 'Reconcile'.
- Create a counterpart line for this bank statement, but specify
receivable account.
The payment created has `partner_type` set as `supplier`.
Although a receivable account is used for customers.
This use case can arise in case of a credit note to a customer: the
reimbursement should create a customer payment, not a supplier payment.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1910807
closesodoo/odoo#30232
As the journal is mostly set in the Odoo world the _default_journal
method is not needed during create, but in case you only have
partner_id, account_id and type in vals you will have retrieved a wrong
journal in case you have an incoming invoice.
closesodoo/odoo#28635
Typically if you use an onchange method to retrieve values on the server
and convert them to write it will also try to write empty values like
[(6, 0, [])] and this will crash as it has also the length of 3 but no
dictionary but a list
closesodoo/odoo#27937
As the order on the product itself is destroying the functional sequence
in the backend of the module product (handle widget is ineffective on
the view) and is individually set since 4dce861 for its original
purpose, it should not be of any risk to remove the redefinition of
product order for website sale.
This commit closes#26118
Commit dc1681b1 did change the name of the inventory creation from
direct qty update, but test still tries to compare the product.name
closesodoo/odoo#25948
Use case(stock_picking.py):
- Sell a product which has tracking enabled
- Reserve the stock on the delivery order and assign to all stock.move.line a lot/serial, but leave the qty_done zero
- You will get an error message which is not correct
(stock_quant.py)
Give more information about the source of failure
opw:783828
opw-776927
Closes#19973
Due to the fact that some products might be maintained in a module and
will write on the product on upgrade we need to take care that it will
allow to write not changed product types.
In case you have a delivery partner set on your shipping contact,
when checkouting your cart, the preferred carrier will be used instead
of the first available carrier.
1df72cb01b added a stringification of
the domain parameter to handle situations where an actual
domain (list/tuple) is being provided rather than a string, however
this causes issues when the string input is text (unicode) containing
non-ascii data as in Python 2 `str()` will then raise a
UnicodeEncodeError.
Rather than stringify the input, bypass safe_eval when the input is
already a proper domain.
Closes#19367
The constraint does not allow the same check out time as the next
check in time which might be rare but a possible and likely use case.
opw-756694
Closes#18400
Error thrown by google request is an urllib2.HTTPError that can be read
and loaded in JSON. However in some cases the result of the read may
be void or not JSON-ready. This was causing a crash in the error
management and hid the actual issue.
This commit tries to read and JSON-load the error but fall back on
simply displaying the raw error in case of issue when handling it.
Closes#17308 .
When a PoS order is closed, the payment and the sales journal item are
not automatically reconciled. This potentially leaves a lot of
unreconciled entries for a customer, which will appear in his follow-up
report.
This introduces an auto-reconciliation process upon order closing. The
process restricts the reconciliation to an order individually, i.e. we
don't try to cross-reconcile several orders for a customer.
opw-697565
Add missing sudo to allow a user without accounting rights to close a session
and reconcile entries.
Closes#16517
We do not want to allow the change of a related config via a pos.order
and in case the pos.order is done or invoiced we should not be able to
change the user_id anymore and the fiscal position should never ever be
changed after the order is not in draft anymore.
User editable introduced at dca370d7.
Closes#16372
In case a product is a single variant we should not leave it with a BoM
of zero as soon there is a BoM for its template. This would for example
hide the `compute_price` object button which relies on the `bom_count`to
be visible.
BoM is not found for a single variant product and compute price not
possible from the `product.product` view although it is implemented
actually there.
Closes#16237
As show is needed to call super it is impossible to override the
function without running into the immediate print. It is possible though
that you might need some delay that local CPU has rendered everything on
the PoS Ticket before printing...based on this you are able to override
the handle_auto_print and add a delay there.
Closes#16174
The partner of an account move is defined as a related on the partner of
the move lines. This kind of relation implies that the partner of the
account move is the partner of the first account move line. This is
arbitrary and doesn't make much sense.
Closes#14167
opw-693289
We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.
This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.
opw-690812
Closes#13929
Forward-port of 19cca50e7c
We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.
This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.
Closes#13699Closes#13762
opw-690812
Before the fix, the tax base amount is computed only for a complete
invoice line. However, depending on the tax sequence and their inclusion
in the base amount, the tax base amount might be different for the
various taxes of an invoice line.
We keep track of the base amount for every single tax, and refactor the
`_compute_base_amount` to take these values into account.
opw-691177
Closes#13819
`all([]) = True`, therefore if there is no `matched_debit_ids` or
`matched_credit_ids` on a payment ==> boom when you access
`payment.matched_debit_ids[0]`
opw-677157
Closes#12232Closes#12242
The code used the key vals['company_id'] while it was not checked it was present
in the write call (and it should not necessary).
If a key is not present, browse the record instead.
Fixes#8906
[FIX] Valuable checkout hooks for website_sale
[FIX] Values might need to be changed for different field mappings
[FIX] Make definition of form fields inheritable within a function
[FIX] Make shipping_info values available for inherited module manipulation
Close#8490
As eCommerce is not complete and could be improved easily and was
not working anyway until
https://github.com/odoo/odoo/commit/9d0cb024fdc784fa7d53fecd3f0b9125c6f06481
- Use EAN13 instead of internal product id if available
- Add tax to transaction data
- Add shipping costs if available to transaction data
Commit 856bc6f2b1
may cause an issue if the auth_crypt module
is loaded before the base module. That should never
happen in normal circumstances, but forcing an
explicit import does not hurt and makes it safer.
Closes#6742
This reverts commit 2f5d681135.
The previous commit was intended to fix a wrong assumption in case the
purchase uom was different to the standard uom.
The wrong assumption:
- price is related to purchase uom
- therefore it was tried to convert the bom price accordingly
- as the price needs to be already in standard uom it does lead to a
wrong calculation now
Closes#7421
having lines with products using a different UOM for
sales and purchases
If a product does have a (different) purchase uom, we should first
take it as a base for calculating prices as the standard price relates
to it and not the sale (normal) uom.
Closes#6829
opw-640616
Wolfgang Taferner