- add a new checkbox on fiscal position: TaxCloud API
- when computing this fiscal position, it will:
- return an existing tax if one exists for the same tax
percentage, state, zip and TIC Category
- or create and return this tax if it does not exists yet
- Create a data fiscal position: country U.S., tax cloud API
- In l10n_us, add a settings in accounting: compute tax automatically using tax cloud.
NB:
- The signature of map_tax has been modified to optionally specify the product
and the partner on which the tax is applied
- The avoid the validationerrors that may occur while evaluation the tax with Taxcloud
when a public user is on the frontend shop (website_sale), we have to execute the
error silently by logging it.
When processing the delivery order coming from a sale order,
the delivery line must be created as sudo, as the user
processing the picking could not have the access rights
to create the extra line on the sale order
(e.g. for users being inventory users but not sales
users).
opw-677628
In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..
Picking models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Allow users to define a percentage on shipping price, in order to cover
up differences between rating and shipping actual price.
Authors:
Barad Mahendra <mba@openerp.com>
Parth Mehta <pme@odoo.com>
The `purchase_price` is filled in automatically thanks to the onchange
method `product_id_change_margin`. However, when a SO is created
programatically, it is necessary to call manually the method in order to
fill in the field. This is not convenient since the module sale_margin
might not be installed, and crappy workaround (such as the use of
`hasattr`) are necessary.
To avoid this, this fix automatically computes the purchase price at
creation if no value is provided.
When clicking on the 'Put in Pack' button, do not open the wizard
to select the packaging_id if no packaging_id is available for this carrier
('package_carrier_type').
Example:
- If the carrier is Fedex, it makes sense to open the wizard
- If there are no packaging, it doesn't
Only call `product_id_change_margin` method if exists. This method is
defined in `sale_margin` module, but as there is no dependency between
modules (nor a bridge module), the call have to be done here.
* It is sometime useful to be able to set the package type and the package weight during the delivery
* These fields can be edited during the 'put in pack' operation or after, with a button in the view
* As the weight is computed, a new field 'shipping_weight' has been added
* These fields (package type and weight) will be used in the delivery carrier for the shipping
* Packaging types are now handled in a centralized way for all shippers
Add the normalized quantity to the SO line. This field is useful for
delivery carriers, since the package price depends on the weight, which
is always defined as a function fo the product UoM.
opw-667594
HS Code is a standardized code used to describe products categories, and
facilitate customs clearance.
(https://en.wikipedia.org/wiki/Harmonized_System)
Some international transporters require HS codes and use them. We allow
users to store them on product.template's.
Backport of 48156efcd9 + 44f6409731 that fixed the problem in next versions
Revert of da563bcf5c that hid warning for users in backend
One day, we will have to refactor website_sale_delivery. But today, we are the dung beetles.
With a UPS delivery type carrier,
`ups_get_shipping_price_from_so` can return a `ValidationError`,
making the carrier unavailable for this order.
Nevertheless, the iteration checking the availability of the remaining
carriers must be ensured.
opw-657161
Since a2b94b0b6d, we already push the cost
of deliveries on the DO (it may be a grid or a carrier).
So we simply harmonize the behavior: when a DO is transferred,
_add_delivery_cost_to_so() is always called (it will check whether the
delivery costs are to be added to the SO or not)
If the delivery method chosen is NOT an external provider (such as
Fedex, UPS...), the shipping cost is not set on the delivery order.
This fix will search for any shipping cost on the associated sale order
and will update the shipping cost accordingly on the delivery order.
opw-653328
Christophe Simonis