In the scenario where a company uses anglo-saxon accounting, if you receive products from a customer and don't expect to refund the customer but send a replacement unit you still need to create a debit entry on the Stock Interim (Delivered) account. In order to do this the best approach is to create a customer refund from the RMA, but set as free of charge (price unit = 0). The refund will be 0, but the Stock Interim (Delivered) account will be posted anyways.

Steps to reproduce:

Sale Process:

• Increase product Wagon inventory with 1.0 and assign serial number XXXX01

• Create a sale order, product Wagon, confirm it and deliverer to customer (serial XXXX01)

• Review on hang quantity for Wagon or serial number traceability report. It will show location movement From "Stock" to "Customers". It will be decrease quantity from Stock location.

RMA Process:

• Create a Customer RMA, select customer and provide serial XXXX01

• Create a incoming shipment and receive it (serial XXXX01).

• Review on hang quantity for Wagon or serial number traceability report. It will show location movement From "Customers" to "WH RMA". It will be increase quantity to Stock location.

RMA Repair Order Process:

• Go back to Customer RMA and click on create a repair order button.

• Change quantity to repair 1, checked "To Refurbish", select Refurbished Product "Wagon (Refurbished)" and create a repair order.

• "Wagon" and "Wagon (Refurbished)" are two different product.

• Review repair has correct information for example lot number. (Improve at #76)

• Start repair and provide serial number refurbished product.

• End repair.

Current behaviour:

• Review on hang quantity for Wagon or serial number traceability report. It will not decrease quantity from "WH RMA" location.

Excepted behaviour:

• It should decrease quantity for product Wagon from "WH RMA" location. For example: location movement should be "WH RMA" to "Refurbish"

Requirements

• Allow the customer to create an RMA group from the portal and enter lines with product, lot and quantity
• Allow the customer to upload and attach documents (i.e. picture of the damage good)
• Allow the customer to download the return label when the RMA is approved

Impacted versions: 10.0

Steps to reproduce:

• Create "Supplier RMA Group"
• Click on "Add from stock move" and add one or two moves.
• "Confirm" it

Current behavior:

This security: https://github.com/ForgeFlow/stock-rma/blob/14.0/rma_account/views/rma_order_view.xml#L14

Should be applicable to account.group_account_invoice

In order to avoid duplicated efforts in different versions I am creating the list with the latest changes in v9 and v10. Please notice that some of the changes are usability improvements whereas other are bug fixing (maybe some of them remain in v11)

@max3903 @guewen @bodedra It would be nice if you do the same for the latest improvements in v11 so we can make v9 and v10 to meet. Maybe some cherry-picking back and forth is possible:

Latest changes in v9/v10 from 11th May 2018 onwards (creation of 9.0-imp-rma and 10.0-imp-rma branches):

RMA

• filter first by product and then by document not the other way around: 4f01231

• better names in rma operations data and adding missing routes : 31a6a2b and 344dd2b

• dropshipping: propagate the partner to the supplier rma and propose the operation + fixing: bd61b76 and 8cca155 and 190a82b and 8ae4d66 and c72e3df and e45eafc and 7b53426

• add domain to addresses: 08337d6

• security: add rma to stock group and the other way around: 527e6c3

• Warehouse: rma in this warehouse will automatically create the rules and sequences. Also delete them if the chackbox is set to False:880c5d4

• rma location company is the warehouse company: 2c00171

• usabilty filters: c1487eb and 2daa98e

• view domains in products: 766019a

• major refactor on tests: c17ef8b and 9245adc and 28cf4d0 and 22a90f9 and e62d913 and 5cbac7b

RMA SALE

• fixing constraint that checks the partner: 4e78a58
• use sale routes when selling not rma ones: b6f3a4a

RMA ANALYTIC

• fixing: e496586

RMA OPERATING UNIT

• fixing view domains: d9cc676 and 0976bf1
• module dependencies: 75330bf

RMA ACCOUNT

• filtering invoices by product: 4f01231
• demo data: cab4cf9 and 2103ea0
• accountants menu with filter: 4a0a3b3 and d3309cc
• create refund from the refund menu by adding rma lines: a107228
• nicer name_get to make easier search: d8e068a

RMA SALE

• filtering sales by product: 4f01231
• default sale oepration: 146fe51
• renaming policy field: bdfa485
• nicer name get when searching: f43942a

RMA PURCHASE

• name get method when searching: 89a2f5c
• add purchase policy and create Purchases from the RMA (it is needed for advance refund operations): 2100329

ping @lreficent @jbeficent

If it behaves like it does now it has to be called "qty in repair". AS soon as I create the repair order it appears as repaired.

Hi guys,

First off great module, thank you for your work!

Second would you be interested/willing to accept a small patch that would allow the module to create a delivery for a different product than the incoming? I've got something barebones working already, but didn't want to waste time submitting a PR if you weren't interested :)

Steps to reproduce:

• Create a sale order, confirm it and deliverer to customer (serial XXXX01)
• Create a Customer RMA, select customer and provide serial XXXX01
• Create a incoming shipment and receive it (serial XXXX01).
• Go back to Customer RMA and click on create a repair order button.
• Change quantity to repair 1 and create a repair order.

Current behaviour:

• Following fields are empty:

  • Lot/Serial,
  • Delivery Address and
  • Invoicing Address

Excepted behaviour:

• It should bring necessary information from RMA Line.

If the RMA customer is the primary customer and not the billing contact then the wizard to select invoice lines, finds nothing.
The search domain for invoice lines must use the commercial partner.

The wizard was available in v13 form rma orders

cc @ForgeFlow

This is the last commit in v14 that ran travis job: ef756e9.

Latest commits only run pre-commit.

@jbeficent I have fixed following two test case.

• test_customer_rma
• test_supplier_rma

And third test case test_dropship fails with 'incoming' type of picking. (No procurement rule found.) So for try I have changed with 'Outgoing' and it passes following test case.

Would be appreciate to provide details on drop test case.

Moreover, if I don't have the grouping setting activated we have to click two menus to get to RMAS: Customer RMA (parent_menu) and then Customer RMA (Child menu)

No tax_ids added to the refund lines.

Hi,

While creating a lot from an RMA order line the product is not passed as context (context="{'default_product_id': product_id}") could this be added?

Cas

Hi @jbeficent ,

@bodedra identified some challenges to migrate to version 11. Can you review his solution below before he starts development?

Thanks!

Hi guys,

Do you have a runbot for this repo?

• Cannot edit approval policy in product from view (It is ok. it is only updateable from the category)
• RMA Sale has no link to the RMA (Not True, it is in the line)
• Sale policy still editable in approved RMA
• Button create supplier RMA returns the customer form view
• Route rma_customer has 2 wrong procurement rules

Hi Guys,

IMO, have an active field on master data always useful.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

Modules to migrate

• rma - By @AaronHForgeFlow - #127
• rma_account - By @AaronHForgeFlow - #128
• rma_analytic
• rma_operating_unit
• rma_purchase - By @Chanakya-SerpentCS - #143
• rma_purchase_analytic
• rma_quality_control_issue
• rma_repair
• rma_sale - By @AaronHForgeFlow - #129
• rma_sale_analytic
• account_move_line_rma_order_line

When Create Supplier RMA from Wizard threw getting traceback like : AttributeError: 'rma.order.line.make.supplier.rma' object has no attribute 'rma_id'

For Solution as Suggestion:

rma/wizards/rma_order_line_make_supplier_rma.py File in _prepare_supplier_rma_line method
(https://github.com/ForgeFlow/stock-rma/blob/16.0/rma/wizards/rma_order_line_make_supplier_rma.py#L105)

Solution : ("company_id", "=", self.rma_id.company_id.id), to ("company_id", "=", self.supplier_rma_id.company_id.id),

Wrong account in credit notes for customer RMAS. It is using stock output (interim) account by default. It should be sales.

Versions: at least 14.0

The RMA order lines field is incorrectly positioned.

Hi Guys,

Since all move created via procurement.order, the price_unit value will equal to product's cost price. This would be wrong for incoming move. Stock move's price_unit should be taken from RMA Line price unit.

This commit try to fix it 18991b3.

I don't have the requirement for a specific version but exposing RMA on the portal would be nice. Customer or vendor could enter their RMA and download the shipping label once approved.

The system to keep track of the incoming or outgoing pickings is mostly fragile. We should investigate how to make it stronger to avoid future errors.

For example, if you create a return for a delivery picking in RMA, the delivery would disappear from the related RMA.

Hi guys,

receipt_policy on rma.operation has (1) ordered, (2) received, and (3) no as selection. But rma.order.line has (1) ordered, (2) delivered, and (3) no.

I think rma.order.line's selection are the right one.

PS:
Sorry i could not provide PR since me and my team still working on v8.0. Here is our 8.0 branch https://github.com/open-synergy/stock-rma/tree/8.0 . Feel free to cherry pick.

@max3903 we're using these internally and have just noticed a missing dependency here:

https://github.com/ForgeFlow/stock-rma/blob/16.0/rma_purchase/__manifest__.py#L11

for purchase_stock.

When the module rma_repair is installed but rma_put_away not, an exception occurs when viewing an existing customer RMA group.

AttributeError: 'stock.move' object has no attribute 'is_rma_put_away'

Looking at the code this attribute is referenced in rma_repair but defined in rma_put_away. When I manually install rma_put_away the problem is solved.

Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1638, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/opt/odoo/custom/src/odoo/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1665, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1869, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
    result = endpoint(**request.params)
  File "/opt/odoo/custom/src/odoo/odoo/http.py", line 700, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/opt/odoo/auto/addons/web/controllers/dataset.py", line 42, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "/opt/odoo/auto/addons/web/controllers/dataset.py", line 33, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/api.py", line 468, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 2996, in read
    return self._read_format(fnames=fields, load=load)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3175, in _read_format
    vals[name] = convert(record[name], record, use_name_get)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5948, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1210, in __get__
    self.compute_value(recs)
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1392, in compute_value
    records._compute_field_value(self)
  File "/opt/odoo/auto/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
    return super()._compute_field_value(field)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 4232, in _compute_field_value
    fields.determine(field.compute, self)
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 98, in determine
    return needle(*args)
  File "/opt/odoo/auto/addons/rma_repair/models/rma_order.py", line 19, in _compute_repair_transfer_count
    .filtered(lambda m: m.is_rma_put_away)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5444, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5444, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/opt/odoo/auto/addons/rma_repair/models/rma_order.py", line 19, in <lambda>
    .filtered(lambda m: m.is_rma_put_away)
AttributeError: 'stock.move' object has no attribute 'is_rma_put_away'

@jbeficent

Would you please create 11.0 branch. So I will submit PR.

Looking forward.

Requirement: Be able to send components to the customer so they do the repair order themselves.

• Use the repair type module (https://github.com/OCA/manufacture/tree/14.0/repair_type) to customize the locations in order to repair in the customer site.
• From the repair order. Be able to create a picking, or a sales quotation that will eventually deliver to the customer, to do the actual delivery of the materials to the customer.
• The invoice can be handled in 3 different places:
  1. Do a pre-invoice in the RMA
  2. Invoice from the repair order
  3. Invoice from the sales quotation created on the repair order.
• Once the picking is delivered to the customer the repair order is set to done, as long as we are done everything that is expected from us (deliver the components). The automated stock moves created in the repair order are symbolic, the consumption/production will occur in the customer locations.
• It would be nice to see the invoices created in the RMA form view, independently if those are created from the repair order or from the sales quotation.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Modules to migrate

• rma - @ageficent - in #52
• rma_account - @ageficent - in #53
• [ ] rma_account_analytic - merged in rma_analytic
• rma_analytic - By @aheficent - in #110
• rma_operating_unit - @bjeficent - in #63
• rma_purchase - By @murtuzasaleh - in #69
• rma_purchase_analytic
• rma_quality_control_issue
• rma_repair - By @grindtildeath - in #65
• rma_sale - @grindtildeath - in #66
• rma_sale_analytic
• account_move_line_rma_order_line By @aheficent - #95

Create a module similar to OCA/account-financial-tools#1276

Depend on rma_account, account_move_line_rma_order_line

This module should allow users to locate customer or supplier rma's that have unreconciled entries a reconcilable account and to trigger the write-off in a wizard, allowing the user to decide what account to write-off to, and the write-off date.

For example, in a normal situation using demo data in US country (anglo saxon accounting), using the operation "refund after receive" the rma would produce the following journal entries:

1. On receiving the incoming shipment from the customer

Dr. Inventory 100
Cr. Interim Account (Delivered) 100

2. On creating the refund

Dr. Interim Account (Delivered) 100
Cr. COGS 100

In this case the rma_account, account_move_line_rma_order_line modules ensure that the account.move.line records involving the account 'Interim Account (Delivered)' both point to the same rma_line_id, and both move lines are currently unreconciled.

We want to display a smart button in the RMA called "Unreconciled items" that can take you to all the unreconciled move lines that are related to a rma_line_id.

We also wanto a button "Reconcile entries" (only visible in the status 'done' and if there are unreconciled entries) that allow the user to initiate a wizard to reconcile unreconciled move lines. It is possible (but unlikely) that there may be more than one reconcilable account. The user should be able to see, for each account, the unreconciled amount between debits and credits and to indicate a write-off account and date of write-off. When processing the wizard the application should generate the write-off.

As it happens with OCA/account-financial-tools#1276, it should be possible to filter by RMA lines that have unreconciled entries.

@ChrisOForgeFlow @AaronHForgeFlow

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• rma - by @bodedra - in #28
• rma_account - by @bodedra - in #30
• rma_account_analytic
• rma_analytic
• rma_operating_unit
• rma_purchase - by @bodedra - in #31
• rma_purchase_analytic
• rma_quality_control_issue
• rma_repair
• rma_sale - by @aheficent #42
• rma_sale_analytic
• account_move_line_rma_order_line - by @aheficent #46

• When creating a return to vendor (supplier rma) Odoo takes me to a "customer" rma view. That is, I see "Customer" instead of vendor, and the link to a "Supplier RMA" instead of a link to a "Customer RMA". Steps to reproduce: create a Customer RMA, approve it, and then create a Supplier RMA using the button in the form view.
  

There are several issues:

• the rma_account module fails when creating refunds. It depends on crm when it should not. Once crm is installed it's failing because the accounts are not set properly.

• the wizard to create supplier rma from customer rma is not adapted to the new model

Target version: 14.0 (to be ported to other versions if needed)

Steps to reproduce:

1. Create an RMA group for 3 RMA lines (I used the serial number feature for this, but the problem could happen in other scenarios as well - not tested):
   

2. Navigate to lines and approve them (side note, a batch action to request approval and approve would be handy here).

3. Select all 3 lines and create the incoming shipment.
   

4. The incoming shipment will be for 3 units but it will only be linked to the first RMA line.
   

5. Also, if you reserve that incoming shipment, it does not reserve the lots/serials the RMAs were created for.
   

That filter is important for repair teams.

The wizard "Create Delivery" just open a new window with the list of transfers but does not create any.

Hi Guys,

On v8.0 i encountered problem when osv_memory.autovacuum run. Here are the logs:

2017-10-24 02:21:36,138 3724 ERROR mrp1 openerp.addons.base.ir.ir_cron: Call of self.pool.get('osv_memory.autovacuum').power_on(cr, uid, *()) failed in Job 1
Traceback (most recent call last):
File "/home/andhit_r/odoo8/odoo/openerp/addons/base/ir/ir_cron.py", line 138, in _callback
getattr(model, method_name)(cr, uid, *args)
File "/home/andhit_r/odoo8/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "/home/andhit_r/odoo8/odoo/openerp/addons/base/ir/osv_memory_autovacuum.py", line 31, in power_on
model._transient_vacuum(cr, uid, force=True)
File "/home/andhit_r/odoo8/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "/home/andhit_r/odoo8/odoo/openerp/models.py", line 5108, in _transient_vacuum
self._transient_clean_rows_older_than(cr, self._transient_max_hours * 60 * 60)
File "/home/andhit_r/odoo8/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "/home/andhit_r/odoo8/odoo/openerp/models.py", line 5072, in _transient_clean_rows_older_than
self.unlink(cr, SUPERUSER_ID, ids)
File "/home/andhit_r/odoo8/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "/home/andhit_r/odoo8/odoo/openerp/models.py", line 3631, in unlink
'where id IN %s', (sub_ids,))
File "/home/andhit_r/odoo8/odoo/openerp/sql_db.py", line 158, in wrapper
return f(self, *args, **kwargs)
File "/home/andhit_r/odoo8/odoo/openerp/sql_db.py", line 234, in execute
res = self._obj.execute(query, params)
IntegrityError: null value in column "wiz_id" violates not-null constraint
CONTEXT: SQL statement "UPDATE ONLY "public"."rma_order_line_make_repair_item" SET "wiz_id" = NULL WHERE $1 OPERATOR(pg_catalog.=) "wiz_id""

It cannot erase all the wizard data (rma.order.line.make.repair) since all the wizard items (rma.order.line.make.repair.item) need wiz_id. Do you guys having this similar problem?

Propose Solution:

1. set required=False on wiz_id field, or
2. Add ondelete="cascade" parameter on wiz_id

We do not necessarily want to install all the modules of RMA, that's why, I think that the option 'auto_install' is not necessary.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0

Modules to migrate

• rma - By @MateuGForgeFlow - #146
• rma_account - By @MateuGForgeFlow - #147
• rma_analytic
• rma_operating_unit
• rma_purchase - By @MateuGForgeFlow - #153
• rma_purchase_analytic
• rma_quality_control_issue
• rma_repair - By @MateuGForgeFlow - #154
• rma_sale - By @MateuGForgeFlow - #148
• rma_sale_analytic
• account_move_line_rma_order_line

Field sale_selectable used in some stock.locations.routes records on demo data is defined on sale_stock Odoo core module which is not included on manifest module dependencies.

Hello,
I have an issue with my use case, and it is kind of linked to this recent fix : #265
I'd like to understand better why there is such a strong will to have mandatory "rma route".

I have multiple customer case where, the company never repair the returned product and always delivery products in RMA cases in the exact same way they would do from a sale order.
And they have a lot of different route depending on the type of product they ship. So it would be quite heavy (too much configuration) to have to create an rma operation for each type of product, with a exact same route that is configured on the product and then configure these operations on the product side etc.
When just letting odoo chosing the route with no special configuration would work as a charm.

I understand that in other case, we need a specific RMA route and it is important, but I believe it should be optional no?
From what I see, making route optional for now would be quite a lot of change, so I don't want to go there.

From what I understand from #265 the goal is to raise an error in case the rma chosen route is not used, due to a configuration error ? (Indeed, the rma route has priority on any other rule so the problem must be only in case of bad configuration right ?)
I wonder if we could find a way that would manage both case (raise in case of bad configuration but leave a way to use routes configured on product/categories/warehouse).

One way could be to allow all rules from any route with the flag rma_selectable
Here https://github.com/ForgeFlow/stock-rma/blob/14.0/rma/wizards/rma_make_picking.py#L147
Something like force_rule_ids = self.env['stock.location.route'].search([('rma_selectable', '=', True)]).rule_ids.ids
And it would be the exact same allowed rules for delivery which is my actual concern.
I think that would solve both case.

Anyway, I don't know well these modules yet, so I'd like to have your opinions about this. @StefanRijnhart @JordiBForgeFlow @DavidFIB

Hi Guys,

Since you have two type of RMA operation (customer and supplier), IMO it will be best if you have 2 rma_operation_id on both product and product.category.

When the repair policy is the one being delivered.

If the customer has a specific fiscal position, or the fiscal position is set up to auto-detect, then it should be proposed in the sales order.

Hello,

Is it possible to add a branch for 16.0 version?
I've started a standard migration of main module already, I'll be able to make a PR once the branch is created.

@JordiBForgeFlow @DavidJForgeFlow