A leave type now generate timesheet by default. So
the internal project/task are taken from the leave
type company (a default value for the company has
been added).
To allow the hr leave manager to select a project,
he should be alble to read the analytic account
(otherwise, crash when calling name_get).
Setting the default internal project/task is advanced,
so hidden in debug mode on timesheet config.
Timesheet logged on project created from a SO line are
not exactly the same as the non billable ones.
To ease the reporting, we split the non billable type
of timesheet: when timesheeting directly on a project
(whatever the product config), the billable type will
be 'no task found'.
The Overview is adapt to display the 2 'non billable'
categories.
The stat button now shows all the project involved
in the sale order (created, or linked).
This commits introduce the field `project_ids`,
containing all the project involved in the sales
order (created, or linked via products).
The stat button now shows all involded projects (if
many) or the timesheet overview of the single project.
The project name should take the customer ref into
account, when creating project.
The task name should be the first line of the SO description
to avoid having multiple tasks generated with the same name.
When clicking on kanban box, the first action is trigger; the user
have to click on the label of the box to see the 'timesheet' (for
instance), otherwise he will see the tasks.
Since HTML5 supports `div`, `table`, ... being wrapped by `a` tag,
we can use it to make the entire kanban box clickable. (See
https://www.w3.org/TR/html5/text-level-semantics.html#the-a-element)
When assigning task to a SO line (through procurement),
related timesheet should become billable (according to the
product of so line), and have their revenue recomputed.
This commits also add a test.
Tests of sale_timesheet were using many demo data. This
is a practice we want to avoid. A common class setting up
test data (product service, partner, ...) is created to
help writting good test cases.
All tests has been adapted, moved, and some were added
to cover the new flow (new product configuration).
The field `project_time_mode_id` on res.company is
already defined in project module. This came from the
good old days where timesheet was not totally depending
on project.
In sale_timesheet, the field was redefined, and a hack
with xml id was done. It is time to remove this crap.
The purpose is to simplify the product configuration.
Adding detailled options about the service tracking
(create task and/or project) make the setup less
confusing for users.
The invoice policy is replaced by "Invoice based"
(only for services). We don't support "ordered
quantities" with "manual" tracking anymore. The
supported use cases are :
- Ordered quantities (using timesheet)
- Timesheet on task (delivered with timesheet)
- Milestones (delivered manually)
Also, even when selecting 'Milestones', the SO line
can generate a task/project, but timesheeting on
thoses objects will not change the delivered
quantities on the SOL. So, a task can always be created
whatever the service invoice policy of the product.
Every generated task or project are linked to their SO
line. But this SO line is only incremented (on delivered
quantity) if its product 'service_type' is timesheet.
Since this field is an analytic account and not a project, its
name should be more explicit. This commit makes the code more
understandable. Naming things correctly improve developper's
sleep.
As so line already generate task, and project
for the SO sometimes, making it always create the
project seems to be a good idea.
Grouping all the logic is better for maintenability
and readability.
The handling of analytic lines to sell is a little
mess. We can reinvoice analytic lines from timesheet
or expenses, or manual lines.
This commit tries to clean the code, factorize it,
make proper hook (see _sale_postprocess method)
and move specific in its corresponding modules.
Code was properly split, in order to make modules responsible
for only their own features:
- sale module handle the link of SO line to an analytic
line, and increment the delivered qty accordingly.
sale also provide the mecanism of determine magically
the SO lines of an analytic line with an expensable product
to reinvoice it at cost.
- sale_timesheet identifies the so line concerned when
timesheeting on a project directly. Also provide the domain
of analytic line when setting the SO line on AAL.
Cleaning is necessary for futher dev.
* CoA up to date
* Taxes up to date
* SKR03 installed by default but users can easily switch to SKR04 while no accounting entries exists for the company
* removed unneeded things
* set tags accordingly on accounts and taxes for the reports to work (new reports in enterprise)
Was task 31826. Was PR #17447. Discussion related on #18571
Since procurement refactoring in commit 0e4f3bb959
the partner was not propagate between sale order and picking.
It happens because the _run_move method uses the group's
partner on the picking but the partner was not set on the
group during its creation.
This commit add the shipping partner id of the order
in the create method and this partner is used later in the
picking/move create method.
Introduces a lock/unlock mechanism on stock.picking. When a picking is
unlocked a user is allowed to:
- change initial demand when picking is not done
- change quantity done when picking is done
Suppose you have a product tracked by serial number. In your inventory,
you have two quants: -1 for serial1, +1 for serial2.
If you create a move for 1 product and try to run `action_assign`, it
didn't work before this patch because stock.move's
`_update_reserved_quantity` is guarded by a call to
an unstricted `_get_available_quantity` (unstricted meaning considering
all quants regardless of their lot_id/package_id/owner_id). This call
resulted in an available quantity of 0, thus the stock move could not be
reserved
To fix this issue, we patched `_get_available_quantity` so that it
rightly considers products of different lot_id as different products,
i.e. it returns an available quantity of +1 in the initial scenario. Of
course, we consider all quants of the same lot_id, i.e. if you have -1
for serial1 and +1 for serial2, the available quantity amounts to 0.
In another scenario, let's say we have only -1 serial1 in stock, if we
run `_get_available_quantity`, the method should return 0: nothing is
reservable. We continue this reasonment by returning 0 everytime the
available quantity is negative, tracked or not. This is probably what a
method named `_get_available_quantity` should have done since the
beginning.
There's only a single case where we need to know the quantity even if
it's negative: it's just after we move a quant to its destination
location. If this quant was tracked and resulted in a negative quant
(i.e. we moved something we didn't have), we try to compensate with an
untracked quant. In this special case, we do not want to ignore the
negative quants when calling `_get_available_quantity`. That's why we
introduce a new argument to this method. We could have added a new method
`_get_quantity` for clarity sake.
Before this commit, the xml attributes defined with 'context.get(key)' in the
subviews not inline were not evaluated correctly. This was caused
by the loss of the one context in the '_loadSubviews' method.
This commit fixes this issue and modifies the mockserver in order to be able
to use the parameter 'viewOptions.context'.
Before this commit, when an event had only a date, the event
was set to midnight.
This commit sets the event as all day event if the field used as start date
is only a date and not a datetime.
When we validate stock move having move lines with quanity done equal to
'0', these move lines are unreserved and in MRP, it creates move lines
with product_qty = 0 and qty_done = 0 which is not wanted
The production wizard raised a traceback when you were trying to consume
product tracked by lot without reservation.
To fix this issue and some potential others, we have removed the
move lines from the wizard and create produce lines that are used on
validation to create the move lines.
This also let us show the 'To Consume' quantity of a lot instead of the
reserved quantity which has no sense when there is no reservation.
*im_livechat,rating.
Emojis are now encoded in unicode characters in messages. This
allows to copy/paste messages including emojis, ensures that
emojis are properly displayed in mail interfaces (at least those
that support unicode, e.g. GMAIL, counter-example: outlook), and
allows the user to directly use emojis of its smartphone in mobile.
This commit also adds several new emojis.
PR #11095
Before this rev., a traceback was raised when the user clicked on a
many2many tag in a kanban view without color field.
For instance, it was the case in the kanban view opened by clicking
on the Lead/Opportunity section of the activities icon in the
systray.
Jérome Maes