OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.
The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).
This is a forward-port/cherry-pick of 7bdd4de805
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.
For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.
Since commit 2ab68047, the Paypal link can be sent in an invoice as it
was the case before. However, in order to be able to save the Paypal
account in the accounting settings, the Paypal account must be
website-published. If the module `website_payments` is not installed,
this is not possible.
We remove this condition, since it should be possible tu use the Paypal
payment method without installing the whole website.
opw-686216
This reverts commit a57b10dbd5. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. On some status
bars, clicking doesn't work anymore.
The reason is because, in some mysterious cases, the event is propagated
to the parent. The `currentTarget` is not the `li` element, but the
parent `ul`. By setting the `immediate` argument to `true` (execute the
first function instead of the last), this solves the issue.
When removing the "Save as Attachment Prefix" field
of the Invoice report (`account.report_invoice`),
it was no longer possible to reset the invoice to draft
opw-687130
Since 85bcd6fdd8, the field `paypal_account`
has been removed. The field `paypal_url` cannot be computed correctly
anymore. Convert it to a dummy field.
When a database is created, we are not auto-logged in to the new
database anymore because the login passed to the authentication request
is 'admin' instead of the one set in the creation form.
To fix this issue, we used the login parameter from the creation form
in the authentication request. We also set the login field to
required in the create database form view.
This bug comes from rev https://github.com/odoo/odoo/commit/903733a32
When anglo-saxon accounting is enabled and the valuation of a product is
'real_time', rounding errors might occur in the price difference between
the invoice price and the product price. It occurs when the product
price precision is larger than the accounting precision.
To avoid these rounding errors, we calculate the difference as the
difference between the price before update and the price after update.
opw-686730
- Activate the option "Track Lots or Serial Numbers".
- Set the outgoing process as 3-step one.
- Create a stockable product for which the tracking is "By Unique Serial
Number".
- Go to Sales > Sales > Sales Orders.
- Create a Quotation for the created product and confirm it. A picking
is generated but it is waiting availability.
- You are sure to have this product in stock so you force the
availability and assign the serial number (001) you want to transfer
in the operation lot details.
- Validate the picking. By doing this, it creates a negative quant in
the origin location (WH/Stock) and it creates a positive quant in the
destination location (WH/Packing Zone). The two quants are linked to
each other.
- Go to Inventory > Inventory Control > Inventory Adjustments.
- Create an inventory in WH/Stock for all products and set it in
progress.
- You want to correct the negative quantity you have so set the real
quantity of product B to 0.
- Validate the inventory and you get the following warning: "The serial
number 001 is already in stock.Otherwise make sure the right
stock/owner is set".
We should allow a quantity larger than 1.0 temporary, so it allows the
system to reconcile the quants.
opw-685825
category was changed to "Website" so it'd appear under the website
category in the store, but it needs to be "Theme" otherwise it doesn't
appear in the "Choose your theme" menu after installing website.
Since 5a9e1af64 our guess_mimetype accepted a `default` named argument.
This commit fix the use of library used instead of our implementation, so
we don't get an error from an unexpected argument when having python-magic
installed on a given server.
Since python-magic functions always return a default mimetype:
- empty content: application/x-empty
- text content: text/plain
- binary content: application/octet-stream
the guess_mimetype default argument is not used with python-magic
implementations.
closes#13343
opw-687354
When an owner is defined on a quant, the current behavior is to to allow
only the owner to use it. This is restrictive for internal transfers:
when a quant is owned by Partner A, only a picking with owner Partner A
can select it.
The fix is to make things a bit less restrictive: when a quant is owned
by Partner A, a picking without owner or with Partner A as owner can
select it.
opw-687207
In the new API, default calls are supposed to return recordset
(even empty recordset), not bool values for relationnal fields.
If the table for this model was already present and if no l10n_x
was installed, no default value could be computed correctly for
existing entries. This caused a crash on install.
opw-683470
If you create an issue when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create an issue directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created issue. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the issue, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
If you create a task when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create a task directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created task. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the task, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
Before this commit, the focus point the user can move on the image in
the background position configuration dialog was only following the
mouse as we want if the image original width was larger than the dialog
one. This is because the javascript relies on the fact the image takes
100% width of its container. To fix this, the container now does not
take 100% of modal width but the size of its internal image (with a
max-width of 100%).
It might happen that a price is strike through in the shopping cart
although it has the same value than the discounted price. This can be
due to differences in decimals smaller than 0.01.
The fix is to apply the same logic than in other places: strike through
if the difference is larger than 0.1.
opw-685109
This is needed to avoid the scheduler to stop suddenly as the scheduler
takes a bunch of moves to reserve without looking if all moves of
a picking are taken. That way, it is possible that a certain key
is not there in this dictionary and the solution is to simply
filter them out.
Closes#13286
In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order
will generate unexpected behaviour.
Eg:
> id id_dept name
> -------------------
> 1 1 Tom
> 2 1 Mike
> 3 2 Meggie
> 4 2 Marge
> 5 3 Bart
> 6 3 Lisa
> using LIMITed selects like:
> SELECT * FROM employee ORDER BY id_dept LIMIT 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6
> You can have some result missings from the 3 requests, and others duplicated.
> Because id_dept is not a uniq order.
opw-686639
note: backport of saas-12 4dce8616
Even if there is only one provider,
you could still use the internal login rather than
this oauth provider to sign in,
and therefore you need to remain on the regular
login page if you would like to reset your internal password
If you create an ir.ui.view from the backend, it'll everytime
show a traceback (Keyerror arch).
The field we write to in the form view is `arch_base`. Writing in
`arch_base` will indirectly write on `arch`.
The issue is that the `create` function or ir.ui.view is overriden
in order to compute the `type` column. For this to be done, we parse
the `arch` content and the type is the string of the root tag.
The issue is that we parsed the `arch` field instead of `arch_base`.
However, during the creation of the db, convert.py will write to
the `arch` field when inserting the views in database.
Another thing is that we'll get a traceback if the parse fail for
any reasons (an invalid xml string for example). To workaround
that, we chose to catch the issue and do nothing with it as the
constraint on `ir.ui.view` will detects this issue among others and
will raise a proper ValidationError.
Lastly, the actual code only clears the `arch_fs` field if we write
on `arch`. This patch also clears it when writing on `arch_base`.
Christophe Simonis