[FR] Support non-serializable (part) item Return Orders

[baltuonis]

Adding support for non-serializable (part) item Return Orders

Feature request: #8372

[netlify]

✅ Deploy Preview for inventree-web-pui-preview ready!

Name	Link
🔨 Latest commit	9c462aa
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/6723ecab06327f0008c53cb9
😎 Deploy Preview	https://deploy-preview-8400--inventree-web-pui-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (🔴 down 1 from production) Accessibility: 86 (no change from production) Best Practices: 100 (no change from production) SEO: 78 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[baltuonis]

@SchrodingersGat I was not sure how to add a parameter to disable/enable this. If you could point me to the right location, I could try adding it.

[SchrodingersGat]

@baltuonis thanks for submitting the PR! This approach is not exactly what I had in mind, what I envisioned was that you would simply remove the restriction that the returned item had to be serialized:

InvenTree/src/backend/InvenTree/order/models.py

Line 2408 in feefa60

if self.item and not self.item.serialized:

What you have implemented here is a lot more complex, and I am supposing that what you actually want to be able to achieve is to create a "return order" for a stock item which does not "exist" in the system? It that correct?

For example, if a non-serialized item has been shipped to a customer, that item should be able to be returned via the existing processes, if we allow "non serialized" items to be added to a ReturnOrder via the ReturnOrderLineItem model. I do not think that these extra models you are adding here are necessary.

Perhaps you can expand a bit more on what exactly you are trying to achieve, based on the context above?

[baltuonis]

@SchrodingersGat right, so this was my first "hold my beer, I'm gonna make a PR in 15 mins" approach.
But then I've bumped into an issue where I can't return more than 1 item in the same Return Order (RO), because of unique(item,order) constraint.

If I want to return them, I have to create a bunch of stock items for the same product. Now imagine, we have return orders with 17 units of item1, 5 units of item2, etc. That's where I had to add quantity field.

Another problem (as you've suggested) is that sometimes there are items that are not present in the main warehouse and we have to issue an RO that includes them... That's where I added part field.

So then I've realized that adding those fields + all the surrounding logic inside a ReturnOrderLineItem would result in a weird polymorphic object that will complicate everything long term.

That's why in the end I've added a separate section with a new model. I think that could be turned off/on with a flag in admin settings.

[SchrodingersGat]

@baltuonis can I suggest a simpler approach, which I think should work for you here.

Let's say you have sent a quantity of 100x books to a customer. This appears as a single StockItem (with quantity 100x) at the customer.

The customer wants to return 15 of these books. Rather than adding another layer of complication with a new model that maps a "quantity" of the item to be returned, I'd suggest the following process:

1. "Split" the single stock item into two, 1 with quantity 85 and 1 with quantity 15.
2. Issue a return order for the quantity 15
3. Repeat the process for returning other smaller quantities

This utilizes processes which already exist, and does not require this additional alternative process.

To make this happen you would need to make at least the following adjustments to the codebase:

a) Allow stock items which are "at" a customer to be "split" - currently this is prevented, I think
b) Enable non-serialized stock items to be part of return orders

Does this make sense? I strongly feel it is a cleaner alternative which will work better for you anyway