Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Grouped deliveries for RMAs #211

Closed
florian-dacosta opened this issue Mar 12, 2021 · 14 comments
Closed

[RFC] Grouped deliveries for RMAs #211

florian-dacosta opened this issue Mar 12, 2021 · 14 comments
Assignees
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.

Comments

@florian-dacosta
Copy link
Contributor

The need to have multiple RMAs grouped into a single document is questionable, I am not sure yet if it will be a blocking point for some customers, but I believe it is an issue at least on the warehouse point of view.

For instance if you create multiple RMAs from one sale order because you have to receive and replace multiple products,
I guess you may be able to process it in batch with the replacement wizard on RMA side, but as a result, every product should be grouped in the same picking.
You don't want to do multiple deliveries to the same customer if it is not necessary, right?

I think the grouping could be done quite easily with a procurement group.
Maybe it would be possible to create automatically a procurement group for all the RMAs created from the sale order for instance, it would be a start, what do you think? (in rma_sale)
Or directly in rma module, we could have an option to create a procurement group automatically on RMA creation or find an existing one on existing rma sharing some common criterias (same partner, draft state, same requested operation...)

Also, I did not see any shipping_partner field on RMA.
On the test I made, if I create a RMA from a sale order which has a different delivery address than the main partner, the RMA won't take it into account and I will send the replacement product at the wrong address (different from the one in the original sale order)
Any reason? Else I'll try to make a PR about this.

Thanks for your insights
@pedrobaeza @chienandalu @ernestotejeda

@sergioeix
Copy link

+1 @florian-dacosta i think this will be great, to group all the lines on the same rma instead to have a single rma by line.

@pedrobaeza
Copy link
Member

This was done on purpose as a design principle, as:

  1. It's not usual to return a lot of things at the same time.
  2. Even in that case, each product/unit may have a different treatment (repair, refund, change...), so grouping them at that level will mean to need to handle 2 levels of things with a lot of information and duplication in both.
  3. You already have the tools to refund/return in batch, just acting over the RMA list view and selecting them together.

@florian-dacosta
Copy link
Contributor Author

I don't really agree, I have multiple customers who receive multiple products at once, and have the same treatment.
But anyway, from the design, I don't see an easy way to group multiple RMA in one.

But, the main issue for me, is really about delivery, you can process all products one by one at RMA level, but when delivering, you do not want to send multiple pack to customer if you return/replace multiple products.

So I worked on a POC, in order to group the RMA only on the inventory/logistic level (with procurement group).
The idea is that when a RMA is created, it would get the same procurement group as other draft RMA for a same customer (criterias could be customizable). And so, it will get the same delivery order in case of return/replacement.
It is not perfect, but I think it can be a good workaround for this issue and it would be an optional module.

@pedrobaeza What do you think of such a module?

@pedrobaeza
Copy link
Member

But you already have that in current module. You just need to select all of the RMAs in the list, and click on Action > Return/Refund for doing them grouped. Have you tried?

@sergioeix
Copy link

I got your point @pedrobaeza

This was done on purpose as a design principle, as:

  1. It's not usual to return a lot of things at the same time.
  2. Even in that case, each product/unit may have a different treatment (repair, refund, change...), so grouping them at that level will mean to need to handle 2 levels of things with a lot of information and duplication in both.
  3. You already have the tools to refund/return in batch, just acting over the RMA list view and selecting them together.

but when you have to return a sale order with 5 lines or more (in some companies its more usual than you think to have this kind of returns), then you have to do the 5 receipts manually (this case is even worse if you use lots), i think the receipt can be the same for the 5 rma´s of the same order if done at the same time, and keep the isolated treatment you said at rma level to repair refund or replace.

I have to say that this case only happens on rma´s created from the sale order (rma_sale) if you do this from the delivery by return button and check create rma´s on the wizard only one receipt its created for all the rma´s

@pedrobaeza
Copy link
Member

AFAIK, you are able to also do the receipt all together with the same technique.

@sergioeix
Copy link

I think it cant be done, and with lots i am sure that it cant be done.

@pedrobaeza
Copy link
Member

I'm talking about generating one single reception picking, that is covered by the module.

@sergioeix
Copy link

sergioeix commented May 10, 2021

Let me explain the case, steps to reproduce on runbot:
1 - create sale order with 3 lines and do the delivery
2 - create rma from rma button on sale order
3 - 3 rma are created and 3 diferent receipts are created
spected behaivor
3 rma should be created but only 1 receipt should be created

if its not clear i can make a video, as i said it only happens from rma button on sale order, if you try to do this from return button on delivery 3 rma are created and 1 receip

@pedrobaeza
Copy link
Member

Then that seems a bug. @chienandalu can you take a look?

@chienandalu
Copy link
Member

Then that seems a bug. @chienandalu can you take a look?

I'll do. You can assign me

@florian-dacosta
Copy link
Contributor Author

florian-dacosta commented May 14, 2021

But you already have that in current module. You just need to select all of the RMAs in the list, and click on Action > Return/Refund for doing them grouped. Have you tried?

From what I see, the reception is always one picking per RMA.
The action in mass do not allow replacement not confirmation for now also if we really want to manage RMA per group, it is not really user friendly.
The module I may intend to do would be to also to improve the usability.
Maybe a smart button to check all RMA from a same (procurement) group, to be able to do this without always filtering manually.
I was wondering, in this grouping usability module about group RMA automatically at creation for 2 reasons :

  1. Ease further mass action on all RMA from group and visibility right after creation
  2. Be able to have some kind of consistency in RMA naming. Indeed, grouping at creation allows us to choose a name accordingly to the group. Instead of having RMA001, RMA002, etc...
    I could have RMA001-1, RMA001-2, RMA001-3 with a procurement group named RMA001.
    Then, on inventory side, I could search by origin RMA001 to find the right pickings, etc...

This may seem unnecessary, but it actually is a big usability improvement to be able to search for a unique reference in group of RMA.
Well anyway, I am not sure yet, but this is the kind of thing I would put in this additional grouping module

@sergioeix
Copy link

About this issue i want to mention that it only happen with rma_sale when you try to create rma from RMA button on sale order.
The same way if you try to create rma from website (from a sale order with 3 lines as example) the created rmas (one for each line) on backend are created as draft and cant be confirmed on block at the same time, so if you try to confirm each rma one by one a single picking its created for each rma.
Let me know If it is not clear and I will make a more extended explanation.
B/R

@github-actions
Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label May 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

No branches or pull requests

4 participants