- Display correct bom count for product, before this commit it was
not displaying the bom count when we have bom for template without variant.
task-39561
- Tested the flow and verify computation made in hierarchical order
- Tested with different Unit of Measurements
- Tested with 3 level of componets and sub-componets
- Tested with Work Operations
- Tested with Inventory Valuation
task-39561
Purpose
=======
Compute cost of product(s) based on it's BoM
Specification
=============
real_time: not with FIFO otherwise open the
wizard with the bom price as default new value
periodic: directly set the cost on the form view
Add a server action in order to directly set the price
on selected product.
When getting price from a bom with a sub-bom it will take the
cost of the sub bom except if the sub-bom is set with the bom
itself in the server action (in this case the sub bom cost will
be used).
Capacity is not used for this functionality
task-39561
Purpose of this merge is to link reminders to notes. The whole feature is
therefore moved to node module that extends activities and systray.
See sub-commits for more details.
This merge is related to task ID 1833628. Closes#24129.
This commit refactors f488dc58c3 that added reminder feature in activities.
After merging it was suggested specifications were not correct and it has
been decided to move the whole reminder feature in note.
Reminders are now notes instead of activities. Now when having note appµ
systray proposes to create a note / reminder. A note.note record is created
with info given by the user. If a date is given in the systray quick create
then an activity is scheduled on this note.
This means user can create records in activity systray that are not
activities but notes used as reminders. Those will use the first availableµ
note column for the user.
As reminders are now notes the support of activities not linked to any
document is removed, as well as archiving activities and tests linked to
that behavior.
This commit has been not carefully tested nor in-depth reviewied. It is
considered as too important for the upcoming freeze. This closes task ID
1833628. Closes#24129 . Many thanks to @dpr-odoo for its quick development
and good work on this task.
Purpose is to have first column holding all todos and reminders. We then
add a few columns for today / tomorrow / later to help people organize
themselves.
- We show the completion date of a picking when it's done
- We add the filter that show canceled picking
- We remove the filter that show confirmed picking as it doesn't exist
anymore
TASK-38741
- Delivery slip of a picking not done will show the initial demands
- Delivery slip of a picking done will show details of what have been processed
- Remove the shipment backorder message
- Remove the Weight and show the Shipping Weight
TASK-38741
- Remove 'Production Order #'
- Don't diplay source field if empty
- Change subtittle
- If MO not done, only shown reserved products
- If MO done, show what has been really consumed
- Show product barcode
- Show reserved product location
- Show reserved product tracking data
TASK-38741
Users can configure multiple references in a same
category. This might cause problems during conversion
and does not make sense.
Since this is a "late" constraint, we define it in
python to avoid conflict with existing data.
We allow user to have multiple unactive reference, but
force to have exactly one active. So when a new UoM
category is created, user have to encode the reference
unit first, and then the bigger/smaller ones.
This commit also update stock tests, since they were
redefining new reference UoM in the same category, and
finally, this commit provides some tests for this
uniqueness and custom UoM behavior.
Task #1820076
In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.
Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.
To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)
Task #1820076
These modules are currently made to run with an odoo 8.0 server.
They are given as-it on the odoo repository but are intended to be run on the
posbox and not supported on a classic server.
Add a new report in order to display:
- bom structure and cost
- bom structure
- bom cost
The user is allowed to print multiple bom reports at once.
Print the report dynamically depending what have been unfolded.
In html the rendering is lazy, when unfolding the client make a request
to the server in order to get the html that will be append to the DOM.
For the pdf the kwargs unfolded could be used in order to render everything
at once.
With the help of:
Dhaval Suthar <dut@odoo.com>
Jigar Patel <jat@openerp.com>
task-36741
Since report refactoring the function to override is get_report_values
that only returns a dict of value that are used in rendering.
In order to render a pdf with a landscape orientation, a context key could
be added however since it's not possible to return a report object in
get_report_values, it's difficult to add a contexti without using some tricks.
This commit add a report option to use in the template that will be used
in order to modify the pdf orientation. The process used was already existing
for other options like dpi,...
Current demo data do not have advanced configuration.
This commit provides new demo data in order to test
bom report or advanced MRP configuration with sub bom
bom with kit,...
Impacted modules: hr_timesheet, sale_timesheet and project.
This merge commit provides feature for service flow (selling
timesheet). The most important points are
1/ selling project based on template: on product configuration,
user can now set a template for the Sales Order to create a
project by duplicating this ones (stages, tasks, ... are duplicated
from the template). If several Sale Lines are based on the same
template, only one will be created. Same mecanism if multiple product
creating a project without template: only one project per SO.
2/ Project Overview Revamp: before this, it was based on a filter
domain on analytic line (aka timesheet). This causes many problem
as if you are selling prepaid services, you project plan was empty
as long as no timesheet was created. Moreover, this kind of domain
is not very usefull for the user (nobody want to see project plan of
timesheet containing "analysis" for instance). The project plan is
now a filter on project, to ease fetching data from the project (even
if no timesheet or forecast), and allow cross project analysis.
The overview table part is now available even when forecast is not
installed.
3/ Assign Tasks Massively: a wizard is provided to ease linking
task to the same Sale Order Line, to ease billing their related
timesheets.
4/ Usability Details: filter task per SO or SO line, stat button
on Sale Order now redirect to kanban project instead of global
project plan, generated task/project names are cleaner, ...
5/ Installing only timesheet module, user will be able to track
cost without selling time. Fields of cost and employee hourly cost
are moved from sale_timesheet to hr_timesheet.
To make this feature works, some technical efforts was required:
1/ Project and Analytic Account: To allow SO to generate multiple
project, we wanted them to share the same analytic account (the one
of the Sale Order). To do so, we had to remove the inheritS between
project.project and account.analytic.account models.
To allow timesheet on a project, an analytic need to be set manually,
or it will be automatically generated (like before with the inheritS),
if allow_timesheet is checked.
2/ Refactoring of SOL service generation: to allow SOL to generate
only one project (per template) for the SO, the part of service creation
on sale.order.line needed a refactoring.
3/ Revamping the overview also improve its performances: some part
are now based on SQL queries (table part), or on report (profitability
report). Doing a report allow the user to create its own filters, and
give him a more accurate tools to extract statistics then project plan.
The idea is to get only one source of information for reporting and
analysis.
Please see sub commits for more details.
Thanks for @tde-banana-odoo for his review and advices during
development,
and thanks to @bst-odoo for his functionnal ideas, testing and support.
Tasks #34702Closes#22268
'remaining_hours' is defined in project as a simple
float field, manually updateable, only displayed
when the group "Time Estimation on Task" is activated.
But for now, there is no setting to active this group.
Those are legacy useless stuff, so we can remove it.
The purpose is to make 'time estimation' feature only
available when timesheet is installed.
Thie commit also split the compute methods of
'remaining_hours' and 'progress' fields to make
'remaining_hours' updateable, though inverse method.
Without splitting the compute method, the calculation
of the progress was done correctly during onchange
but not when saving.
We want to split the sale order line description as follow:
- first line will be the title of the task, prefixed by SO
reference
- the rest of SO line description should be the task
description
The purpose is to avoid duplicating the first SO line
description in task title and description.
Task #1831934
From task stat button from SO form view, it
is relevant to see the task of the SO only.
So, we add a filter to do so. AS the kanban
task use a read_group, it is required to store
the sale_order_id field on task.
The code of the project overview is split to be used when only
timesheet is installed (no forecast). The table part only
display column for timesheeted time per month.
When forecast is installed and activated, other columns
comes to complete this table.
This commit also makes visible SO line having no timesheet
linked in project overview.
When selling a project from a sale order, the SO line
creates the project. When we create a task in that
kind of project, by default, the task will be linked
to the SO line of its project.
However, for the SO line field to be visible on the
task form view, the customer must be set. This commit
set the customer from the SO line when changing
the project (billable project only).
Selling product creating project can now be based
on project template. When setting a project template
on product, this will copy the project (like a duplicate)
and replace its customer, ... with information from the
SO line, on SO confirmation.
There is only one project without template per SO, and
one project per template per SO (so 2 SO lines with the
same project template on their product will only create
one project with this template).
When confirming a SO, only one project will be created, even if
some so lines would create a project. Only the first line will
create the project, the other will not be linked to its.
`project_id` field is added on so line, to keep track of the
generated project, as already done for the task.
The '_timesheet_service_generation' method has been rewritten
to be execute in batch and improve performance and prefetching.
On SO confirmation, no message are now post in chatter to avoid
having one message per so line that should have created a task.
A message is only posted when user manually add SO lines on
confirmed SO.
Now that an analytic account can be linked
to several projects, you might want to change
the analytic on the SO.
Before this commit, the user was allow to create
an analytic account on a confirmed SO but not
modify it. This was usefull when you wanted to
reinvoice an expense on a SO without AA set.
This is now solved (AA is automatically created
when validated expense).
Now, we want to allow set manually the AA before
confirming SO to match the one of potential
projects.
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
The project overview is kind of badly design. This
commit does not solve all the issue but tries to make
it simpler and more efficient:
- Does not depends on AAL anymore: the overview search
is now about projects. You can see the overview of multiple
projects. Even when no timesheet are encoded, the plan will
not be empty.
- "Time by people" displays each employee assigned to task,
even if no timesheet are recorded.
- Code now use reporting view to keep consistency and simple
code in overview controller.
The cost of an employee should be in hr_timesheet for a long time, to
allow user to track time on project/task: hours spent and their cost.
This commit simply moves fields and related views. It also moves the
'postprocess' method from sale_timesheet to hr_timesheet since this
method is responsible to set the amount (cost) on AAL.
User can now track their time and cost, without having sale_timesheet
installed.
The project of a SO will not be used anymore, as we planned
to have a sale order creating multiple projects.
The concept of 'only project from SO' does not make sense.
This commit provide a real reporting tool
for project profitability: graph and pivot
views.
You can now have a look at cost and revenues
per project, so line, product, see which
project manager brings the more money, which
project costs many human time, ...
The project overview is based on this report
analysis to be consistent.
However, a change of computation for 'amount
invoiced' is introduced: we now based the amount
on the price_reduce of the SO line, and not from
the invoice lines. Also, once a draft invoice is
generated, the quantity is considered as invoiced
at the price of the SO line (no matter is extra
discount happens when validating invoices).
Sanjay Jamod