When a stock user want to create a lot an exception is raised saying
that he cannot modify a product.
This is caused by the field 'product_uom_id' on the model
'stock.production.lot' that is a related to 'product.product' and not
set as readonly in the 'stock.production.lot' view.
So by setting it as readonly, we don't set the uom to the server, and so
don't try to re-write it on the product
The move line view when the option no suggest is checked doesn't work
because it hasen't been adapted during the refactoring of stock module.
So to avoid having differences between the view in no suggest and in
suggest, we use the same tree view that we reference. Because the views
shouldn't be different if we are either in suggest or no suggest
Custory reading seems to denote that field names are probably already
text in the normal case, and thus should not need decoding? It only
blows up in a tour so...
When a move is set to done and a backorder should be create, we get a
traceback saying that we cannot set the quantity done on a move with
multiple move move_lines.
This occurs, when the stock move has multiple move lines with quantity
done set to 0;
Because the new move only contains move lines having quantity done 0, we
remove the useless line that set the quantity done on the move
* gitignore pycache folders (apparently appear for some)
* update xlwt requirement: 1.1.2 does not work with Python 3.6, 1.2 should work, 1.3 officially supports it
When running action_assign on a mts move bypassing the reservation,
we always created a new stock move line with the quantity of the move.
This proved to be too naive when running recheck availability.
Exemple: Let’s say I have a reserved move of quantity 5.
If I edit the initial demand to 7 and click on recheck availability,
I end up with a move line of 5 and a move line of 7. We adadapt the
code in a similar way that what’s done in _update_reserved_quantity,
by looking for a candidate move line and only increasing the reserved
quantity by what still needs to be reserved.
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
opw-749752
opw-751294
opw-751348
-Make a return picking from a SO, and condigure the items to be refunded on SO(in the wizard)
-Copy the return picking.
-Validate it.
Without this fix, it would just keep decreasing the delivered value on SO.
opw:767429
- Go to Accounting > Configuration > Journals.
- In the form view of a journal, click on Action > Voucher Entries
- Click on Create => traceback
opw-771415
- Create 2 companies:
- Company A and check VIES VAT Check
- Company B and do not check VIES VAT Check
- Set current company of admin to Company A and do not allow Company B
- Create a demo user on Company B and give him Adviser group in
Accounting.
- Log in with the demo user.
- Create a Customer A as a company with:
Country = Spain
TIN = ES85847955H
- Create a contact on Customer A: "Contact Sample"
- Create a Customer invoice on "Contact Sample" partner
- Through the menu Accounting/Payments, create a new payment on "Contact
Sample" partner with the total amount of the invoice.
- Open the menu Manual Payments and invoicing matching. The invoice and
the payment should be proposed for reconciliation. Do CTRL+ENTER.
An error message appears: 'The VAT number [ES85847955H] for partner
[Contact Sample] either failed the VIES VAT validation check or did not
respect the expected format ESA12345674.'
This message should not appear as the current user is on Company B which
doesn't have the flag "VIES VAT Check" checked.
The issue comes from the `sudo` in `mark_as_reconciled`, which will lead
to `self.env.user` to be the admin in the VAT check, and therefore
`self.env.user.company_id` will be Company A.
Closes#19274
opw-770018
When selecting a partner in the reconciliation widget, using the SelectCreateDialog
(Search More), the partner wasn't correctly displayed.
This was due to a difference between the change format of the many2one ; when using
the dialog, only the `id` is sent (while the `id` and `display_name` are sent when
using the many2one dropdown).
These two behaviours are now standardized and both now send `id` and `display_name`.
It has the advantage of sparing some `name_get`s called by the model because the
`display_name` was missing.
This change implies some refactoring where the SelectCreateDialog was used.
The module studio gives the abality to name columns or tables with
upper cases. So making the SQL case sensitive avoids problems with studio.
opw:770022
- Create a purchase tax computed with Python code.
- The Python code must use an attribute of the product, e.g.
`product.price`.
- Create a PO using the created purchase tax.
It crashes, because the product (as well as the partner) is not sent to
the `compute_all` method.
opw-770078
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
- Associate a product with a "Deferred Revenue Type"
- Create a customer invoice and add the product => the account of the
deferred revenue is used.
- Create a SO with the same product, and generate the invoice => the
account of the deferred revenue is NOT used.
opw-769254
Suppose you have a product tracked by serial number. In your inventory,
you have two quants: -1 for serial1, +1 for serial2.
If you create a move for 1 product and try to run `action_assign`, it
didn't work before this patch because stock.move's
`_update_reserved_quantity` is guarded by a call to
an unstricted `_get_available_quantity` (unstricted meaning considering
all quants regardless of their lot_id/package_id/owner_id). This call
resulted in an available quantity of 0, thus the stock move could not be
reserved
To fix this issue, we patched `_get_available_quantity` so that it
rightly considers products of different lot_id as different products,
i.e. it returns an available quantity of +1 in the initial scenario. Of
course, we consider all quants of the same lot_id, i.e. if you have -1
for serial1 and +1 for serial2, the available quantity amounts to 0.
In another scenario, let's say we have only -1 serial1 in stock, if we
run `_get_available_quantity`, the method should return 0: nothing is
reservable. We continue this reasonment by returning 0 everytime the
available quantity is negative, tracked or not. This is probably what a
method named `_get_available_quantity` should have done since the
beginning.
There's only a single case where we need to know the quantity even if
it's negative: it's just after we move a quant to its destination
location. If this quant was tracked and resulted in a negative quant
(i.e. we moved something we didn't have), we try to compensate with an
untracked quant. In this special case, we do not want to ignore the
negative quants when calling `_get_available_quantity`. That's why we
introduce a new argument to this method. We could have added a new method
`_get_quantity` for clarity sake.
Before this commit, the xml attributes defined with 'context.get(key)' in the
subviews not inline were not evaluated correctly. This was caused
by the loss of the one context in the '_loadSubviews' method.
This commit fixes this issue and modifies the mockserver in order to be able
to use the parameter 'viewOptions.context'.
Before this commit, when an event had only a date, the event
was set to midnight.
This commit sets the event as all day event if the field used as start date
is only a date and not a datetime.
Pratima Gupta