[FR] Allow returns to contain installed items

[timmyhadwen]

Please verify that this feature request has NOT been suggested before.

• [X] I checked and didn't find a similar feature request

Problem statement

We ship class sets of robots to schools and often a single robot in a set needs to be repaired, the current system only allows the full class set to be returned in an RMA.

Suggested solution

Allow installed items to be returned, individually and then returned/replaced/repaired to a customer

Describe alternatives you've considered

We currently have to remove the individual robot from the build, assign it to the customer and then create the return order. This is messy as it means we have 1 robot from a build assigned to the customer, as well as a 10 pack which doesn't contain 10 robots anymore.

Examples of other systems

No response

Do you want to develop this?

• [ ] I want to develop this.

[matmair]

Why are you sending a whole set of products as one item? I think it would make more sense to assign all real-world separate items as separate items in sales orders to - that way you can also clearly track individual RMAs.

From a conceptual model it feels iffy to have the ability to be able to return an installed item without the item it is installed in. What is installed meaning at that point? Maybe it would make sense to introduce something like bundles or SKUs to help handle grouped selling of things.

If you are open to discussing the details of why this process is built this way I would appreciate it to better understand the use case and what we could change. You could either share here publicly or write me an mail to code@mjmair.com

[timmyhadwen]

Hey Matmair, It's a good question. It's a different use case to what others are using it for so happy to explain.

We sell packs of 10 of our robots, in a pelican case. These get built ahead of time, as an assembly with the case, 10 robots, 10 usb cables, a charger and getting started guide.

This means (ideally) our warehouse is full of serialised packs, containing subsets of serialised robots so that when they are sold, the pack is simply allocated to the customer instead of having to open up the sealed box, determine which 10 robots are in the box, allocate them to a sales order etc.

When a robot has an issue that warrants a return/repair/replacement etc it makes sense to only return a single robot, rather than return the 6.5KG pelican case with 9 robots we don't touch.

It's a good point that we could indeed allocate 10 robots to the sales order, and we used to do this when everything was built on demand. However as we scale it makes a lot of sense to have packs on shelves ready to ship without them needing to be unpacked, allocated to the sales order and repacked.

Happy to jump on a zoom etc if you'd like to chat about our use case, I know I've got a couple of open discussions on here that probably warrant a longer chat.

Edit because we had a chat in the office about this further:

Thinking about something like a mobile phone, you should ideally be able to return the phone without its accessories. Or return the charging brick to be replaced etc without returning the phone.

I am wondering whether this needs to be a setting on a sub assembly which is basically marking something as a final assembly (packing etc) rather than an actual assembly. Of course you don't want someone to be able to return the 0402 resistor on their phone, but rather return the charger that is packaged with the phone.

Maybe a solution to this is a seperate assembly type which is "exploded" on allocation to a customer.

[timmyhadwen]

To add to this again, I have been talking to a PCB/electronics manufacturer in Brisbane (one of our partners) who built their own system for their entire business to understand how they have dealt with this. Here is a summary of my conversation with them:

1. Anything with a serial number can be returned Regardless of how deep into an assembly it is. They brought up an example product which comes with a very custom and fancy cable, which often is damaged (mining related product) and therefore is often returned and replaced. This never comes with the actual device in a return as the device is normally permanently bolted or even welded into the mine site.

2. They allow returns to happen regardless of sales orders For example they brought up that they provide products to a customer, who may not be the end user (think a distributor of a product etc). The returns are handled direct customer to manufacture and skips the distributor. Therefore items need to be able to returned by a customer who never was sold the device in their system.

This is an interesting situation and Im not totally sure I like it, but it does make sense that you can return something under warranty even if you aren't the purchaser. I can think of even a family member adopting a phone or device etc, should still be able to return it if it is damaged or fails under warranty.

Worth some longer discussions I think

Another thing to add is we have developed an integration with Xero so that sales orders get generated from Xero Invoices, which means we don't necessarily want to add every single item in a set to each invoice to a customer.

[matmair]

Reading all this I am really rethinking using assemblies for purposes of sale. I think a distinction between physical and logical assemblies would make sense.

Jumping on a call and discussing this further is probably the best solution to sketch out how this should be modelled and what kind of interaction would make sense. @SchrodingersGat you want in on this?

An accounting (Xero or similar) integration is something I have encountered multiple times now. Separating sellable logical "kits" and physical assemblies would help in this regard too.

[SchrodingersGat]

@timmyhadwen @matmair some great discussion here. I agree that the ability to return an item should be decoupled from how it was sent out, potentially (with some obvious caveats)...

Perhaps, only serialized items can be returned is a good limitation?

regarding the separation of "kits" and "assemblies": this is similar to a very long-running discussion about being able to purchase a "bundled" item: https://github.com/inventree/InvenTree/issues/2624 - in such a case you buy a "kit" from a supplier that you want to be able to "explode" on purchase into multiple items. A similar concept but for sales orders would be good here.

A "10 pack" of robots (in your case) is obviously not a physical assembly...

Happy to jump on a call to discuss this (and @timmyhadwen looks like you guys make some really cool products)! I'm in Australia too, also in the robotics space :)

[timmyhadwen]

Yep hadn't even thought about the purchasing side, there are several parts we purchase (enclosures are one I can think of straight away) which contain multiple parts but we buy as a "kit". Screws, main body, end caps etc all part of 1 enclosure. We explode these manually during purchase but this obviously isn't ideal either.

I'll email @matmair to organise a call and he can loop you in.

PS: thanks! Great to hear your local and would love to have you visit sometime if your ever in Brisbane to see how we're using this awesome software.

[github-actions[bot]]

This issue seems stale. Please react to show this is still important.

[SchrodingersGat]

Still active