Have 2 repair records with the same partner_id, ready to be invoiced
In list view select both records and click Action>Create invoices
In the wizard check 'Group by partner invoice address', create invoices.
Separate invoices will be created, but while grouping 1 invoice should
be created joining the 2 repairs
opw-2476539
closesodoo/odoo#70434
X-original-commit: 8f6e2fa1096f57ace6c84ae6083ab77ee37a69a1
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
When adding a product to a repair order, the module automatically adds
all product's taxes, even if some taxes belong to other companies.
To reproduce the error
(Need 2 companies C01 and C02. Let C01 be the current company)
1. Create a product P
- Must have a tax T_C01
2. Switch to C02
3. Edit P
- Add a tax T_C02
4. Activate C01
5. Create a Repair Order
- Add a customer
- Add a line with product P
Error: Both T_C01 and T_C02 are added. However, since C02 is the current
company, T_C01 should not be added.
(Similar issue possible with `repair.fee`)
OPW-2486791
closes#68079closesodoo/odoo#70352
X-original-commit: 75a122bbae3a32bfa79da3506179fc63a8bced5d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to follow to reproduce the bug :
- Install the Repairs and Accounting application
- Create a new user and give him only access to Accounting
- Connect with this user
- Create a draft invoice
- Try to delete it
- Access rights error is triggered.
Problem:
When we delete an invoice and the Repairs app is installed, we check if it is not an invoice related to a repair.
But the user does not have access to “repair.order”, so we can not check the field "repair_ids".
opw-2507867
closesodoo/odoo#70095
X-original-commit: b5588246a0e032c92b8443e67875ff4146858fe8
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
The purpose of this commit is to improve the repairs module general
workflow, to make it more intuitive and more flexible.
1. Change in the way the Repair Reference is created. It is now always
autogenerated. A new Repair Description can be used.
2. Make the 'Parts' and 'Operations' tabs editable up until (and
including) the stage 'Under Repair'.
3. Make the 'Lot/Serial Number' Field non mandatory for tracked
products, up to and including to the stage 'Under Repair'. If the
user forgot to specify the serial number and clicks on 'End Repair',
shows the exisiting error message.
4. Add product moves related to the repair order in a smart button at
the top right of repair, just like for a finished manufacturing order.
5. Add a Sale Order field in the repair form to make it easier to
perform return if needed.
6. When a component is not tracked by serial/lot number, leaves lot/serial
number read only.
7. Separationo of notes and internal notes into 2 seperate tabs.
8. Lot/serial field always visible but readonly when no tracking.
Task ID-2424420
closesodoo/odoo#66496
Related: odoo/upgrade#2327
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- In Repair: create a new repair order
- add some product to "Add' and operation.
- Select option for Invoice Method: Before/After Repair.
- Confirm Repair, finish repair and create invoice.
Bug:
No line was created in the invoice
PS: the invoice_line_ids were popped from function _move_autocomplete_invoice_lines_create
opw:2493091
closesodoo/odoo#68587
X-original-commit: 952ff15a3af90bb32660262b4fd32ca8a1172eac
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
commit 38711e9f9c prevent multi company issues.
But it goes a litle too far in restriction and prevent to put a service
in the repair fee. Which is a feature since user would like to register
and invoice human ressources in maintenance cost.
closesodoo/odoo#64033
X-original-commit: 64de68b4420eb4d82ff2130dfaa310e40775a0b7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
Fine-tuning of 9d7d618220e27024321a75be0058db2289115af2
Although the mentioned commit delays the consumption of a sequence
number at creation, it has the drawback to not generate one if the user
modifies the name.
In practice, we still want to generate a RMA number even if there is a
custom name. A good balance is to generate the RMA number if the user
leaves the `/` at the beginning of the name. If the user removes the
`/`, we don't generate the RMA number.
opw-2301412
closesodoo/odoo#57932
X-original-commit: 2ad9b4b2b5780c20a0cd77c48b24dcb76d69f912
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- On Safari, go to Module Repair
- Create a Repair Order
- Add a new line L
- A default type Add was set
- Set a product P on L
Bug:
The default value was reset
opw:2319954
closesodoo/odoo#57332
X-original-commit: 3aa92c1805f9d47dad4655b3ba49d08c319ef1df
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When a field is specified as widget="monetary" it makes sense to have the
currency actually shows. It won't happen if currency field is not present
within the view.
An heuristic to detect missing currency field presence when using monetary
fields or monetary widget tag will land soon in master. As this commit targets
a stable version only view fixes are provided.
Task ID-2329114
PR #56946
X-original-commit: 9c1c848ad1e8fef11320e2a162b008de7e304bcb
- Install Contacts and Repairs
- Go to Contacts and configure Payment Terms of Contact X (i.e. 2 Months)
- Go to Repairs and create a Repair Order:
* Select Contact X as Customer
* Select "Before Repair" as Invoice Method
* Add Parts or Operations
- Confirm Repair and Create invoice
The Payment Terms of the created invoice is the default one and not the Payment Terms of Customer.
opw-2304818
closesodoo/odoo#55152
X-original-commit: 351718d5f579fca4945538c78e63aa50118af2b4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a repair order
- Cancel the creation
- Create another repair order
There is a gap in the sequence number.
The gap is due to the fact that the sequence number is consumed by the
`default_get`.
Although this is a change of behavior, the actual one is not really
expected. Even if a gap is possible with the sequence, we don't want to
consume a number every time we get the default values.
opw-2301412
closesodoo/odoo#55005
X-original-commit: 9d7d618220e27024321a75be0058db2289115af2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a repair order
- Choose a customer A
- Change the invoicing address to customer B > set default
- Create invoice
The delivery address set on the repair order is not taken into account
on the invoice. The delivery address field on the invoice stays empty
despite having a delivery address set up on the repair order.
opw-2285659
closesodoo/odoo#53831
X-original-commit: e109faec5f1e14864addfb1eb56c508ab04f6eb0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
On a SO, you can set a default delivery address or a default invoicing address according to the customer.
The same behavior has been applied on repair order.
opw:2277679
closesodoo/odoo#53194
X-original-commit: 5dfedd9fa452ad5a7ea5ee25209a4d31da379f2d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Translate the sale description for products and operations.
opw-2274120
closesodoo/odoo#53176
X-original-commit: df364e64e75523533b86fb8d488cb081eb2e5b77
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Translate the repair fees description in the language of the partner, as
done for repair lines.
opw-2274120
closesodoo/odoo#52760
X-original-commit: 0bc7ac2a9d60534f0e7bec120ad716bbb7d13155
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a repair order RO for a product P1
- Create a part for a product P2 that needs a lot L
- Specify a source location for P2
- Process RO
- Click on 'END REPAIR'
Bug:
A UserError was raised saying: You need to supply a Lot/Serial number for product P2
even if a lot L was set to P2
opw:2251047
closesodoo/odoo#51797
X-original-commit: 1e3ed56332efd3f58ccd05f23c6af9cb23f1052f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Default and onchange fallbacks don't consider the current company
when searching for a pricelist.
Forward-port of #46429closesodoo/odoo#49650
X-original-commit: 812af92080648bdb7f7bb0e4e6aef55c6dc4b9d4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before Commit:
-Current Functionality doesn't Restrict Unlink of Order Based on States.
-if we delete the invoice linked to repair order the state button of invoice
still visible in reapir order and when we click on state button it open
new draft invoice.
After Commit:
-Add Validation on Unlink the order based on State,link unlink order only
on draft and cancel state.
-Always show the "cancel" button on repair orders.When the orders have been
cancelled, only allow to delete them if there is no invoice linked, or if
the invoice which is linked can be deleted (is still draft and has never
been posted). If we are not in one of those conditions, raise the following
error "You cannot delete a repair order which is linked to an invoice which
has been posted once."
-Add wizard when cancelling a repair order which has a draft invoice linked.
task-id: 2198997
* Repair lines should have a repair order
* Repair fees and lines companies should be related to the order
company.
closesodoo/odoo#46774
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The parameter `lot_id` must be a recordset, not an `int`.
opw-2188752
closesodoo/odoo#44525
X-original-commit: aeafd2a84e309ee4a496f9a109d7fe6b0fb9cd3d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Improve the inherited wizards of 'stock.warn.insufficient.qty' by adding
some piece of information about the quantity involved. Also
change titles to integrated the related product into.
task-2144636
Co-authored-by: Ankita Raval <anr@odoo.com>
- Create some stock in WH/Stock for product A
- Create some stock in WH/Stock/Shelf 1 for product B
- Create a Repair Order for Product A in WH/Stock
- Add a line in Parts with B, leave the location to WH/Stock
- Process the order until the end
Negative quant is created in WH/Stock for B instead of using the
quantity in WH/Stock/Shelf 1.
We do a best effort in order to reserve the quantity in the
sub-locations.
opw-2177352
closesodoo/odoo#43716
X-original-commit: 2158f07cb2d32480f0db2a8e82aaea73ac266271
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a fiscal position FP with automatic detection for customer in your country
- Let's consider two taxes T1 and T2 where T1 is mapped by T2 in FP
- Let's consider a product P with T1 as customer taxe
- Let's consider a customer C in your country with no fiscal position
- Create a repair order for C
- Add P as an add line
Bug:
T1 was set as customer taxe for P instead of T2.
When manually creating an invoice for C with P, FP is automatically
detected and T2 is set.
With this fix, the automatic detection of FP is applied on repair order.
opw:2120595
closesodoo/odoo#40856
X-original-commit: 3810f9d96246fbc21297b71c34704e87288eb77a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, you can start a repair order with negative value
into its operations (who will cause a dead end when user will try to end
it). So, now a check is done when user tries to start it.
closesodoo/odoo#37045
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When user confirms a repair order for a consumable product, they always
get a warning wizard about insufficient quantity.
But as we don't track quantity for consumables, this wizard is useless.
Tracebacks caused by invalid values in invoice_line_vals.
Since accountpocalypse, 'number' became 'name', and the
invoice creation process in repair was forcing the repair name
as invoice name. To keep the visibility of the information that
a repair order was the source of the invoice, a field was added
in the form view.
TaskID: 2057443
closesodoo/odoo#35930
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
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
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Enforce the domain of the UOM not by an onchange but by a domain.
Exemple of issue if the domain is enforce by an onchange:
- create a picking
- add a move
- select the product
- select an uom
> the uom presented are the one from the product category.
-Save
- edit
- select an uom
> all UOM are presented even the ones of other categories
This commit enforce this new logic at most places.
task: 1886272
closesodoo/odoo#33083
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Andrea Grazioso (agr-odoo)