Right now, the default invoice policy policy for the products is set to
'delivery'. However, in the case of event ticket products, usually you
don't really handle the "delivery" of the ticket. It's most likely to be
sent by email automatically.
With this commit, the invocing policy for the default ticket product is
set to 'order' to ease inovicing the SO. Apart from default product, the
onchage method for 'event_ok' is adapted for setting the correct invoice
policy and product type.
Task Id : 2243915
closesodoo/odoo#63725
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
=======
This PR is in the continuity of odoo#62360.
- Display remaining hours in task sales_line_id (name_get + task form view)
- Remove internal reference from services demo data
- Display sol in project timesheets list if project is billable
- Remove use of non_allow_billable in timesheets as it has been removed from project and task in previous PR (see above)
- Only recompute planned_hours for service product
- Determine the correct SOL for timesheet
- Set the last SOL of customer on timesheet if none is set on task or project
- Allow edition of so_line in timesheet
- Restrict SOL on project to sale lines with a service product
- Use same widget on partner_id many2One than in sale.order (using ranking)
- Remove timesheets table in SO and invoice portal.They were added in previous PR (see above). This introduces the use of links to /my/timesheets/.
- Review portal timesheets (my/timesheets/ and link from orders and invoices)
- Activate group_uom "Units of Measure" on sale_timesheet install
- Hide partner phone number in task form view
- Only determine SOL of task and timesheet if allow_billable=True
- Filter SOL in task so that it matches the SOL of the project SO
- Display red label if remaining hours is negative
- Change SO compute behavior
- Only open SO for salesman on project overview
task-2409761
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closes odoo/odoo#63695
Forward-port-of: #62900
X-original-commit: b1985773f3a67e28049f9e2bb635bcab059ad9c0
Related: odoo/enterprise#15427
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
WHY: odoo translation framework still cannot properly handle terms that have
different translations, so we need to avoid english terms with double meaning.
Also, this improves term understanding for translators.
---
closes odoo/odoo#61668
Discussion: #60765#61272
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit improves the performance of the 'sale_price_subtotal' field of
event.event by refactoring the way it's computed.
The previous naive implementation looped on sale.order.lines linked to the
event and performed a currency conversion for every single line. This leads
up to thousands of requests to fetch the conversion rate and sum up everything
on a real production database like Odoo.com .
This new implementation groups the amounts by currency and performs a single
conversion per currency (factored by the number of events in 'self'). It has
the drawback of using 'today' to fetch conversion rates instead of the actual
SO date like previous implementation.
We (aka: all main POs as this decision was discussed) consider that as an
acceptable trade-off to increase performances.
Task ID-2335287
closesodoo/odoo#58650
X-original-commit: a4c4b03a09ffc08842f44b5759e3c7298cfbd915
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Provide some fixes after internal test deployment of event online features.
Notably: user registration flow, various fixes in templates.
Also add some unit tests to avoid regressions while working on event features.
LINKS
Task ID-2169118
odoo/odoo#55967odoo/enterprise#12438
X-original-commit: e66684b23eebaadc3df7b908427d3d7a83d4f0a0
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
/web/action/load is the public controller that Should be used by the
webclient to fetch actions
_for_xml_id is the default access method on actions that implements
fields filtering to avoid leaking server action code or other
information not needed by the webclient
Implementing whitelist of fields that can be access per model
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
RATIONALE
Even will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff.
PURPOSE
Prepare Event Online support by providing fixes in registration and event
frontend flows. Also provide a quick back2basic in backend views to prepare
addition of Online sub modules.
SPECIFICATIONS: IMPROVE BACKEND VIEWS
Registrations
* list view: show by default creation date which is Registration Date;
* list view: by default show email and phone, still optional;
* list view: by default, hide partner as other information is present;
* list view: hide event when being in context of a specific event to lessen
number of displayed columns;
* rename Source Sales Order to Sales Order, better for users. Make it
optional;
Tickets
* list view: description and start / end sales date are now optional to
lessen number of columns;
* list view: rename Reserved to Confirmed to match registration state naming;
Event
* form view: move organizer, responsible and company information on the right
with address. That way all address-related information are on the right
while timing information are on the left;
* kanban view: display 'confirmed' only if no auto confirm on event.
Otherwise both numbers are the same;
LINKS
Community PR odoo/odoo#55197
Enterprise PR odoo/enterprise#12113
Task ID-2309702 (Event Preparatory Merge 4)
Prepares Task ID-2252655 (Main Online Event task)
Prepares Task ID-2283796 (Event B2Basics / Registration Flow)
Bug
===
Register to an event with a public user.
Sometimes an ACL error will be raised.
Technical
=========
Before flushing the environment (after the creation of the event
registration in the endpoint `registration_confirm`), the ORM will
recompute all needed stored fields. As we didn't write on some of them
(`date_closed`, `utm_campaign_id`, `utm_source_id`, `utm_medium_id`)
they are in the list `Environment::all.tocompute`. So, the ORM will recompute
the fields even if the state didn't change (this behavior can be verify
in `BaseModel::recompute`). This is done after the "create" call of the
event registration and so without the SUDO flag.
Task-2299227
closesodoo/odoo#54624
X-original-commit: 38f37cd483b7907b20171e2c44e14e69e3e00596
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently if you configure an user without sales and mass mailing
rights you run into issues with links modules as
* sales data is computed on form view and requires sales access
rights;
* invite and contact buttons lead to tracebacks as their action
require mailing access rights;
In this commit we fix those issues by correctly setting groups
on fields.
Task ID 2184037
PR #53119
X-original-commit: af1a5d294b235e33a48b87c89886b24ea145450d
When duplicating a registration its SO and SO line should not be copied as
it may impact a done or ongoing SO with payments already done.
LINKS
Task ID 2166679
PR #52334
PURPOSE
Introduce a clearer way of handling registrations for multiple events occurring
at the same time and place by
* improve attendess kanban view;
* introducing a Registration Desk menu item;
SPECIFICATIONS
Introduce a computed "payment_status" selection field, allowing to display
status of a registration, based on its SO and ``is_paid```field. It is better
fro UX and display. It is not stored as currently stored fields are sufficient
for current requirement.
Add it to the kanban view.
Prepare barcode improvements by improving _get_registration_summary returned
data dict, adding some information to display in event_barcode. Reorganize
registrations actions, and prepare a generic one leading to attendees kanban
view for registration desk.
LINKS
Task ID #2214290
Community PR odoo/odoo#47511
Enterprise PR odoo/enterprise#9190
PURPOSE
Create event registrations in batch. It will allow to customize group-creation
of registrations, notably with automated rules for crm / event synchronization.
SPECIFICATIONS
Improve registration editor to create registrations in batch. Also be less
dependent from context in its code, currently a bit weird.
Move creation of registrations based on line from _action_confirm to
action_confirm. Indeed it adds complexity and we are unsure it really helps
having two methods.
Update based on lines now create registrations in batch instead of one by one.
LINKS
Task ID 2258685
Prepare Task ID 2166679 (create leads from registrations)
PR odoo/odoo#51341
Co-Authored-By: Jeremy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Typo was preventing create multi to multi create.
closesodoo/odoo#49352
X-original-commit: 2c65b7283a37b8c44d91e01112843882098bfc7b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 397872a07f remove most onchange in event related modules to replace
them by computed r+w stored fields. At that time copy was by default set to
False for computed fields as resulting of standard behavior.
Since 4b274d3b4101fbae154a572cdf40d23838899773 this is not True anymore as we consider those fields are
duplicable. We can therefore remove unnecessary copy=True on fields to clean
their definitions.
Task ID 2228189
Community PR odoo/odoo#48652
X-original-commit: c6b378987bd3351deba7770b51c2a5755f7ff341
Purpose:
Improve the registration on front-end by allowing the manager
to customize it and display more informations to users about the tickets
and the status of the event.
Specs:
For event manager:
Allow users to decide wether or not they want to unfold/fold
ticket details on their event. The reason behind this is that
some events might have 5+ different tickets and having them unfolded
would bloat the UI quite horribly.
By default, ticket details should be unfolded with no possibility for the end users
to fold it back.
Always display a button for the manager to go configure the event in back-end
For users in general:
Show price range in case the ticket details are folded.
Clearly show the user that a particular ticket is sold out/expired
Cleary show the user that registrations are open/closed/sold out
LINKS:
TaskID:2162438
PR: #43856
PURPOSE
Allow to use UTMs directly in event, notably to be able to sort or make
statistics on registrations.
SPECIFICATIONS
Move all UTMs fields definition to event. In base event module they are
set by hand or through links (when using mass mailing for example).Shared
links with utm bits defined in it allows to track marketing statistics
on registrations.
In event_sale registrations can be linked to a sale order. UTM information
are copied from the sale order to the registration itself. Order defined utm
always erase default one coming from event.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Related: odoo/upgrade#913
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to allow the batch create on those models that may be created
in batch, notably through import.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Origin is a char field holding the registration "source name". Its only use
is to copy the sale order name when registration is linked to a sale order
in event_sale. As we can filter / group / search on sale order or sale order
line directly instead of the origin there is no need to keep this char field.
If necessary to some internal reasons it can simply be added through studio.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
Specifications
--------------
Updating the uom of Sales Order Lines related to an event (selling event
tickets) should be avoided because it doesn't have any sense and wouldn't
work correctly if changed.
Note: As the product_uom field is already readonly according to the SO state,
introduce a new field on the 'sale' application to handle the different
behaviors server side instead of multiplicating the view overrides.
task-2178371
Closes#44818
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
When the auto confirmation flag is set on an event all registrations
must be confirmed by default.
When the auto confirmation flag isn't set the registrations will be
confirmed as soon as the related invoice is paid.
SPECIFICATION
Add a is_paid field in event.registration which will be updated in a
method as soon as the related invoice is paid. This field is used to
display a ribbon on the registration to emphasize its payment status.
LINKS
task ID : 2093336
PR : #43420
PURPOSE
Improve the integration between event and sale, by adding additional information
on both the sale order and the event registration views.
SPECIFICATIONS
- Add a stat button on the registration form linking to the related
sale order instead of a link in the form itself.
- Add a stat button on the sale order showing the registrations count
related to this sale order.
- When changing the ticket type on an attendee it displays an exception
activity on the sale order in order to warn the responsible for taking
action about it.
LINKS
task ID : 2093336
PR : #43420
PURPOSE
- In order to get an overview over events, add a graph view grouped by
event name and measure by seats available.
- Before this commit you had to install event_sale to see the popup window
in the barcode interface when scanning an attendee. With this commit you'll
see the popup even when event_sale is not installed.
SPECIFICATION
- Add the minimal information about the registration in the event module
and overrides it in the event_sale module to add the necessary informations.
That makes the window popup appear everytime when scanning an attendee.
- Add a "is_ongoing" field on event model to use it as a filter in
event_barcode.
LINKS
Task ID : 2093336
PR : #43420
Enterprise PR : odoo/enterprise#7760
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS 1: remove date fields from event.type.ticket
Coming from old ticket implementation there are several unused fields on
event.type.ticket, notably dates about selling. Indeed tickets defined on
event.type are templates and should not be time bound.
Previously those fields were available on event.type tickets but not propagated
to the event tickets. Now they are not available anymore, simplifying models.
We therefore remove them from event.type.ticket model.
SPECIFICATIONS 2: propagate seats definition from ticket template to tickets
Previously to the global feature this commit is a member of, only ticket name,
product and price were copied from event.type to its events. Description has
been added in a previous commit. In this commit we also propagate maximum
seats availability.
Use case is linked to event.type defining a recurring event in a given
location. As seats availability is known it can be copied on all events
linked to this event type.
SPECIFICATIONS 3: improve naming of event tickets
Before this commit, all tickets of an event were labeled the same way
by default, using simply ``<event_name>``. This is annoying when
having several tickets as they had all the same name.
In this commit we fix that behavior by setting the name
* directly from the ticket template when tickets come from an event.type.
Configuring Standard and VIP tickets on an event type will therefore
give Standard and VIP tickets on event;
* generic 'Registration for <event_name>' when adding manually a new ticket
for an event;
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we add a description on event.type.ticket and event.event.type
models. Its purpose is to have a description to use notably in frontend
(website_event and website_event_sale).
Currently a ticket description is available only in website_event_sale and is
the description_sale field of the ticket product. As we now have tickets
independent from products, we introduce a real description field on ticket
that is either put by hand (event), either coming from the product with
event_sale.
Field is therefore also copied from event type tickets configuration to its
event tickets.
Naming on sale order does not take into account ticket description as we
consider this fields as being used for front-end mainly. SO line descripiton
is now updated as the following
* either we have a description_sale on the product, and SO line description
is 'product.description_sale \n event.display_name';
* either not and SO line description is 'ticket.name \n event.display_name';
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
LINKS
Task ID 2177281
Community PR odoo/odoo#43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we make a quixotic attempt to clean call chain implied by
making registrations online, either in event frontend (website_event) or
with eCommerce inclusion (website_event_sale). Purpose is to get rid of some
preparation and data management methods to handle most of the code directly
at CRUD level whenever it makes sense.
We notably
* move at create and write level support of partner_id update: updating
its name / email / phone / mobile;
* move at create and write level support of sale_order-id update: updating
event, ticket, partner;
Using that and some code cleaning some methods are removed and call chain
is a bit reduced.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
There has been a few changes in the accounting module since the version 12.4.
The field 'invoice_ids' in the 'sale.order' model is now related to the 'account.move'
model instead of the 'account.invoice' model. The field that contain the payment state
is now called 'invoice_payment_state'. This field changed name again in master into
'payment_state'.
SPECIFICATION
Change the call from 'invoice.state' into 'invoice.payment_state'.
LINKS
Task ID : 2180184
PR : #43822
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Improve the attendees management: improve views, actions, (views, actions).
Specifications
==============
In order to allow state management in batch, state field is made editable in
multi edit mode of registrations. That way event managers are able to work in
batch. It required to move some code currently called in custom action-called
methods directly in write. It makes sense to consider that some required code
is called by writing on state field instead of depending on calling the right
method. Indeed there is not much "business" code to move: calling mail
schedulers on confirmation, and putting the closing date when closing.
Event and registration tree views are improved, some fields are now editable
in multi edit mode.
When a user register on a event from website, it will create a sale order and
a partner (the customer of the SO). Set automatically the partner of the
registration to the partner of the sale order.
Task ID 2119333
PR #40949
Purpose of this commit is to slightly improve event / sales integration,
notably finding sale orders from an event.
Specifications
* remove sales information from event kanban view;
* add it as a stat button on form view;
* clicking on this button should redirect to the orders linked to that
event, in no create mode to avoid creating de-synchronized data;
Task ID 2170831
PR #43173
Purpose
=======
In this commit we set the total sales price of an event to be the converted
sum of order lines, tax excluded. Currency is now a related on the company to
avoid de-synchronizing events and companies.
Fields and computation comes from 5d1837d250 .
Task 2170831
PR #43173
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
Use _tz_get for tz-based selection fields from partner as it smartly order
available timezones.
Remove a strange "event.confirm" wizard that calls an unexisting method,
is not reachable and is actually completely unnecessary.
Reorganize ticket fields to ease future improvements and perform some
public -> private method cleaning.
Remove duplicated code in event_sale.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
prout
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
As event model grow in complexity and features, it is easier to find its
way through the application with having registration model lying in its
own file to separate it from event-specific models (event.type, event.event).
Ticket (event_sale) and sponsor (website_event_track) models are also extracted
in their own file.
LINKS
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
Kanban view
===========
- add a field ``sales_total_price`` which contains the total sum of all sale order lines (care about the currency)
- this field is used in ``event_sale``
- display the number of expected and confirmed
- when clicking on these buttons, redirect to the tree view with the correct filter
- display this new field in the kanban view
- display the location instead of the country in the kanban view
Form view
=========
Change the order of the buttons in the header of the event form view
Preview Badge > Contact Attendee > Contact Speaker
Add a note field on the model `event.event`
Search
======
Remove the default filter "Upcoming/Running"
Task #2088538
Purpose
=======
Remove the state on the event and add a stage.
So, we can have more control on the event flow, and we will have less constrains.
Website event
=============
Before
------
People can register for an event if "seats are available" and if the state is "confirmed".
After
-----
People can register for an event if `event_registrations_open` is True,
- Event: seats are available and the event is not finished
- Event sale: One or more ticket has `sale_available` set to True
Task #2088538
Before this commit, the values of these 3 fields in database may be
desynchronised with the one set in the cache by the ORM but not
commited yet.
Before this commit, when confirming an attendee, the count was not
correctly recomputed. '_compute_seats' was triggerd when changing the
state of the registration but the value of 'state' was still the one
before the confirmation, making the sum outdated.
Note that two constraints are raised when modifying the field state:
- _check_seats_limit
- _check_ticket_seats_limit
If _check_seats_limit is executed first, the bug does not occures
because it first triggers the '_compute_seats' method on event.event
model, which has a correct flush method.
If _check_ticket_seats_limit is executed first, the bug occures
because the '_compute_seats' of event.registration is triggered first,
which did not have the flush implemented.
Fixesodoo/odoo#38340closesodoo/odoo#39677
X-original-commit: 46b168139e6043f5b5d7cc81a2bec62ef346fcd0
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When .with_context() is called with a dictionary as 1st positional
argument, it will replace context (and not modify the referenced keys)
It may create bugs when losing the content of the context (e.g. remove
partner's language)
This is a partial merge of #36164 without the inventory part as
discussed.
closesodoo/odoo#36729
X-forward: 4717ccfa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Suhani Modi