Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
ON THE DELIVERY SLIP :
1. CUSTOMER REFERENCE
- If a customer reference is filled in the SO, on the delivery slip, under
Customer Address, add a section Customer Reference :
- Display every customer information in the header
2. SO NUMBER
- Display the SO reference under the origin instead on the picking type name.
Do not display it if unset
3. LOCATIONS AND STATUS
- remove the columns locations and status
4. ORDERED QUANTITY
- add a column (between product and quantity) named Ordered Quantity. It
contains the quantity of the initial demand. Rename Quantity into
Delivered Quantity
5. BACKORDER
- If the delivery is a backorder, add the string : This shipment is a backorder
of "stock.picking.name".
- If a backorder has been created, add the string : All items couldn't be shipped,
the remaining ones will be shipped as soon as they become available.
- If it is a backorder and another backorder has been created, both strings should
be printed.
6. SCHEDULE DATE
- Should be the date when the delivery order is validated.
- Rename Scheduled Date into "Date"
- If the DO is not yet validated, display the scheduled date.
- If the DO is validated : display the date it was validated.
7. WEIGHT
- Add the unit of measure after the weight value
- Display only if set
8. CARRIER
- Display only if set
9. LOT/SERIAL NUMBERS
- Keep the header of the column + rename it into Serial Number / Lot
10. CUSTOMER/CONTACT ADDRESS
- Should be displayed on the right, keep only minimal information: Customer name,
phone number
ON THE PICKING REPORT
- picking: https://drive.google.com/file/d/0Bx4JWs1efCreX1FrZUhaZDEtblU/view?usp=drivesdk
- form: https://drive.google.com/a/openerp.com/file/d/0B5BDHVRYo-q5X3VGVWI1aThWcWM/view?usp=drivesdk
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>
* 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.
As the transporter interfaces will put a label on every package,
it is in handy to have a field with the list of the final packages
(and their weights) treated in the picking.
We give a weight for the products that are not in a package also(bulk).
We only put the weight on the package in the views.
The weights in the product form views should appear entirely or not in
product / product templates (only when only 1 variant)
(attrs was only on the field, not label, ...)
The digits= for the weights are not needed as there is a decimal precision
on these fields.
* migration to new API
* removed delivery.grid object, has been merged with delivery.carrier
* change view of delivery.carrier (price rules, etc.)
* tests from yml to py
* website : restrict the list of countries for delivery address in the shop
Yannick Tivisse