* CoA up to date
* Taxes up to date
* SKR03 installed by default but users can easily switch to SKR04 while no accounting entries exists for the company
* removed unneeded things
* set tags accordingly on accounts and taxes for the reports to work (new reports in enterprise)
Was task 31826. Was PR #17447. Discussion related on #18571
- Go to Accounting > Configuration > Journals.
- In the form view of a journal, click on Action > Voucher Entries
- Click on Create => traceback
opw-771415
Since procurement refactoring in commit 0e4f3bb959
the partner was not propagate between sale order and picking.
It happens because the _run_move method uses the group's
partner on the picking but the partner was not set on the
group during its creation.
This commit add the shipping partner id of the order
in the create method and this partner is used later in the
picking/move create method.
- 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
Introduces a lock/unlock mechanism on stock.picking. When a picking is
unlocked a user is allowed to:
- change initial demand when picking is not done
- change quantity done when picking is done
- 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.
When we validate stock move having move lines with quanity done equal to
'0', these move lines are unreserved and in MRP, it creates move lines
with product_qty = 0 and qty_done = 0 which is not wanted
The production wizard raised a traceback when you were trying to consume
product tracked by lot without reservation.
To fix this issue and some potential others, we have removed the
move lines from the wizard and create produce lines that are used on
validation to create the move lines.
This also let us show the 'To Consume' quantity of a lot instead of the
reserved quantity which has no sense when there is no reservation.
In some cases, the consumed quants can be more than one.
In this case the check for the lot must be done just on the first
consumed quant. Courtesy of @jco.
opw:748472
- Create a vendor bill
- Register a payment in the future (e.g. Bank payment)
On the dashboard, this payment in the future is taken into account,
while it shows a graph up to today. Moreover, when clicking on
"Difference", the report is opened at today's date.
opw-768155
- Change the date of an event through the form view
=> a mail is sent to the attendees.
- Change the date of an event thanks to the drag and drop of an event
=> the mail is not sent.
It is necessary to introduce a context key in the write call so we can
make the distinction between the write triggered from the drag and drop
and the write triggered by a recomputation of fields. Indeed, when the
form view is used to change the date, `write` is called several times.
We should avoid sending the same email each time.
opw-766295
*im_livechat,rating.
Emojis are now encoded in unicode characters in messages. This
allows to copy/paste messages including emojis, ensures that
emojis are properly displayed in mail interfaces (at least those
that support unicode, e.g. GMAIL, counter-example: outlook), and
allows the user to directly use emojis of its smartphone in mobile.
This commit also adds several new emojis.
PR #11095
Before this rev., a traceback was raised when the user clicked on a
many2many tag in a kanban view without color field.
For instance, it was the case in the kanban view opened by clicking
on the Lead/Opportunity section of the activities icon in the
systray.
Nicolas Martinelli