We added a model to work easily with packages, using the quant packages
was not a good solution to move entire package and plan package moves,
because we always had to give the picking in context, and create some
move lines, so it was only possible when state was assigned (when move
lines exists)
So we created a model package level, linked to picking, move and move
lines allowing to easily plan package transfer and put in pack.
Easypost return multiple tracker links for a single
picking. Currently it returns one link per package.
*_get_tracking_link instead of returning a simple string,
it could return a list of list with data
[[tracker number, tracker_puclic_url], ...]
stored as a json dump.
This commit add a check on carrier_tracking_url
in order to check if it has a json format. In this case it
will log a note and will not use the url action.
- Create a picking, set as 'Carrier': 'Free delivery charges'
- Enter a 'Tracking Reference'
- Validate the picking
The tracking reference is removed.
opw-1849279
The calculation of the delivery cost for a sale order / invoice was not correct when
free over a limit had been satisfied.
Steps to reproduce the bug:
- Set a delivery method DM with a fixed price = 10.0 and free when the amount of the order exceeds 100
- Create a SO for an amount of 150 and set on it DM
- Confirm the SO and deliver it
Bug:
A SO line with DM was created with a fixed price of 10.0 instead of 0.0
opw:1838070
Use case to reproduce:
- Install delivery/batch picking
- Process 2 pickings in a batch.
-> Traceback due to ensure_one.
It happens because the action_done method in delivery is
not multi and batch_picking launch action_done on multiple
picking.
This commit makes action_done in delivery multi.
This merge changes the templates used to send notification emails. They
are currently defined as mail.template using jinja. We choose to make
them QWeb views. There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
templates people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This merge also factorize the "custom layout" used in several addons
to use a single secondary template defined directly in mail. Indeed they
are using the same template. Therefore having it defined only once helps
editing or fixing it.
Please see sub commits for more details about the merge.
All those templates are basically the same except some bug fixes that
were not propagated about company. Let us use just the one we just
defined in the mail module.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
template people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
This commit adds the possibility to chose between pounds and kilograms
to express the weight field on the product. This is done so that
companies that worked internally in pounds do not have to convert their
weights back to kilograms for a consistent computation of the rates in
delivery.
We complete the general settings with the selection of the weight's uom.
Validating the setting will create an ir.config.parameter. A static
method defined on product template will return the chosen UOM.
We display "weight_uom_name" on the form view so that the UOM is not
clickable/editable because we fear user would want to edit the UOM
instead of changing it in the res config.
We move the view definition allowing to fill the product's weight from
stock to product to help the generation of the intrastat report without
installing inventory.
install delivery
Create a SO with a shipper
Validate it
validate the delivery
Before this commit it was:
- impossible to do the setup for the delivery cost on the SO to get updated with the delivery validation
- the delivery cost on the SO did not update
This was because the stock API changed a bit a some functions were not here anymore
OPW 786500
The package weight is computed by summing all move lines related to it,
which is wrong, because if you have a package that is in two pickings,
its weight will two times bigger than the real weight.
To fix this, we will compute the weight based on the quants in the
package, except if we are opening the package from a pickin, it's weight
will be the sum of move lines of the package that are in the current
picking. This allow user to see the weight of a package after a put in
pack when there are not yet any quants in the package
When an order is shipped, a notification email is sent to the customer.
If there is a tracking URL, it is included in the email.
(and also a bit of refactoring)
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
If the picking has no carrier set, do not open the put in pack wizard
and keep the behavior of a classic picking. Also, filter the delivery
packages according to the carrier (note: this doesn't work at the moment
because of a bug in the new views, but it'll be fixed very soon, so we
merge anyway).
Also, remove an harmless typo in `manage_package_type` method.
On a picking, the UoM of the weight is the default UoM for the weight
category. However, weights in Odoo are always considered to be
kilograms.
This might lead to inconsistencies between what is displayed on the
picking and what is printed on a shipper label.
opw-702564
Because now the carrier id is set on all picking from the same
procurement group, we want to call the carrier API only when there are
some package with a packaging_id set on it.
We have moved the 'quant.package' view into a wizard, because it's
always used as a wizard, and and there was context trouble with the
'Save' button as a button with nale 'write' (the context was mixed with
the field, and there were two write action whan "Save button was
clicked.
The price set for the non integrated carrier must be the same either when you
set it on the SO with button "set_price" or when you set it on the stock picking.
The field "carrier_price" must be in readonly when the state of the picking is done.
opw:691224
Pierre Masereel