Sales Orden Items with CSV with obsolete items error

[miguelangeljop-png]

Hello:
When i upload a CSV for a sales order. If there is an obsolete item non of the other items in the CSV file show up. I cant add items or do anything else. Is there a work around this?

[dalers]

Why is there an obsolete item in the sales order CSV?

It seems reasonable to me an item identified as obsolete cannot be sold. If you want to sell the item, can you first modify the item from "Obsolete" to "Current"? If you don't want to sell the item, can you delete it from the sales order CSV before importing?

Am I misunderstanding your intention?

[miguelangeljop-png]

Hello: I copy my customers PO and they have some obsolete items still in there system because they still have inventory. In the older versions I didnt have that issue. Is there a way to fix this issue. I have more than 400 SKU and 40+ stores and its complicated to remove al the obsolete items from the CSV. Thank you for any help. Miguel Angel Jop Valle Gerente de Ventas Ventas | Club de mercadeo y compras, S.A. +502 6634-2379 <tel:+502 6634-2379>| +502 5704-7526 <tel: +502 5704-7526> ***@***.*** ***@***.***> Carretera Antigua Salvador Lote 40 Zona 7 Aldea Puerta Parada Bodega 20 Kilometro 14 Punto 8 , Santa Catarina Pinula, Guatemala

…

On 5/01/2026, at 2:13 PM, Dale Scott ***@***.***> wrote: It seems reasonable to me an item identified as obsolete cannot be sold. If you want to sell the item, can you modify the item from "Obsolete" to current? If you don't want to sell the item, can you delete it from the sales order CSV before importing?

[dalers]

Hi @miguelangeljop-png

It may be reasonable to add a configuration switch in webERP v5 so it will behave the same as v4 in this respect. This is the resolution for issue #793 (comment) (in v4 a work order could be created for an item that does not have a BOM while v5 a BOM is required). Perhaps a new section in [Setup > General > System Parameters] for "v4 Backwards Compatibility" could be warranted.

Alternatively, do you think a checkbox on the import form to "ignore obsolete items" would be better?

However, I still don't understand why an obsolete PN appears in your customer's PO, in particular if they are not actually ordering the item and it appears in the CSV only because they have stock on hand.

[miguelangeljop-png]

Hello Dave: I think the best way would be to ignore obsolete values. It apeares in there POs because there system automatically reordes until the have 0 inventory even if we have it marked as obsolete. Miguel Angel Jop Valle Gerente de Ventas Ventas | Club de mercadeo y compras, S.A. +502 6634-2379 <tel:+502 6634-2379>| +502 5704-7526 <tel: +502 5704-7526> ***@***.*** ***@***.***> Carretera Antigua Salvador Lote 40 Zona 7 Aldea Puerta Parada Bodega 20 Kilometro 14 Punto 8 , Santa Catarina Pinula, Guatemala

…

On 5/01/2026, at 3:00 PM, Dale Scott ***@***.***> wrote: Hi @miguelangeljop-png <https://github.com/miguelangeljop-png> It may be reasonable to add a configuration switch in webERP v5 so it will behave the same as v4 in this respect. This is the resolution for issue #793 (comment) <#793 (comment)> (in v4 a work order could be created for an item that does not have a BOM while v5 a BOM is required). Perhaps a new section in [Setup > General > System Parameters] for "v4 Backwards Compatibility" could be warranted. Alternatively, do you think a radio button in the import script to "ignore obsolete" items would be better? However, I still don't understand why an obsolete PN appears in your customer's PO, in particular if they are not actually ordering the item and it appears in the CSV only because they have stock on hand. — Reply to this email directly, view it on GitHub <#808 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4K6UGZQPEJUYEDO4HJLNXD4FLGITAVCNFSM6AAAAACQXQF2Q2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBRHA2DSNY>. You are receiving this because you were mentioned.

[dalers]

Thanks for elaborating. To me, this is clearly a backwards compatibiltiy issue (as was #793). and while it could be argued the customer should "fix their data" (and not order obsolete items), that would require work by the customer and no one wants to create friction with a customer.

What is your schedule for migrating your company to v5? I.e. when do you hope to be importing CSVs from POs into a v5 production server?

What are your thoughts @timschofield? @pakricard?

[timschofield]

This was brought in by @pakricard in commit b1de573

This change made the import abort when it got to this item. Removing lines 63 and 64 from includes/SelectOrderItems_IntoCart.php would allow the import to continue without that item, but is this what we would want the behaviour to be?

Tim

[miguelangeljop-png]

Hello: Yes thats exactly what I need. Thanks!! Miguel Angel Jop

…

On 9/01/2026, at 6:43 AM, Tim Schofield ***@***.***> wrote: This was brought in by @pakricard <https://github.com/pakricard> in commit b1de573 <b1de573> This change made the import abort when it got to this item. Removing lines 63 and 64 from includes/SelectOrderItems_IntoCart.php would allow the import to continue without that item, but is this what we would want the behaviour to be? Tim — Reply to this email directly, view it on GitHub <#808 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4K6UG5QMAWPYTCM7AJJBND4F6O6TAVCNFSM6AAAAACQXQF2Q2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBVGQ2DEMI>. You are receiving this because you were mentioned.

[timschofield]

I think we need to hear from Ricard before doing any change as it is his code.

Tim

[dalers]

I would also like to hear from @pakricard but the proposed solution would not alter the user behavior of his commit. Adding a "ignore obsolete items" checkbox to the SelectOrderItems.php form would be similar in concept to the solution accepted for #793 - add a control variable and logic for backwards compatibility with webERP v4 and the default behavior being the current behavior (i.e. the user needs to click the checkbox for v4 behavior).

[timschofield]

Aren't there 3 possible scenarios?

1 Abort when you reach the obsolete item, and leave it for the user to change the input data - Current solution.
2 Skip the obsolete item but import the rest or
3 Import everything including the obsolete items.

Tim

[dalers]

You are correct @timschofield . You are thinking about the system and I was only considering the effect of the commit.

It seems a radio button is needed (v4 compatibility will require 2 additional clicks):

@timschofield were you able to learn what the issue was, that @pakricard's commit resolved?

My initial thought was that the commit prevented a data-entry error and that without the test, a valid order would still be created (although other parts of the workflow could have issues including financials). The commit may also have resolved functional issues when an order is placed for an obsolete item (since such an order was no longer allowed), but it seems @miguelangeljop-png did not experience any issues so it seems unlikely.

We should have @pakricard's insights...

[pakricard]

This change made the import abort when it got to this item. Removing lines 63 and 64 from includes/SelectOrderItems_IntoCart.php would allow the import to continue without that item, but is this what we would want the behaviour to be?

As I see it, and the spirit of the commit, is that an obsolete item is an item that we don't buy, produce or sell any more for any reason. It is just kept in webERP for historical data consistency (as we keep GL data, supplier's transactions, etc from X years ago). We "should not" be selling an obsolete item.

Checking the code, there are around 200 checks with this flag to prevent mixing up current and obsolete items: BOM's, counter sales, Internal stock requests, inventory planning, MRP, price lists, PO's, reorder levels, supplier tenders, WO's, etc. If we remove this check in sales orders, should we do it around all these functionalities too, for sake of consistency?

If we allow the obsolete item to be added to the sales order, and it triggers a PO or a WO: Should we also lift the restriction there?

I think it is a good safety measure to avoid mixing up obsolete with current items. Otherwise, what would be the use of the current/obsolete flag if we allow the items to be operated the same way?

If it is an exception (some leftover item, that we still have a few items and want to sell them to get rid of them), isn't it easier to just flag the item as current, perform the sales order and flag it again as obsolete?

If it is not an exception, but a regular issue for a company, should the company redefine the conditions to flag an item as obsolete?

As usual, I will be happy to accept whatever the community votes for, ;-) but in this case, I would keep it on my code.

R

[dalers]

@pakricard

If we remove this check in sales orders, should we do it around all these functionalities too, for sake of consistency?

If we allow the obsolete item to be added to the sales order, and it triggers a PO or a WO: Should we also lift the restriction there?

Impossible to say until we find out if adding an obsolete item actually triggers a PO or a WO, or some other side-effect. However, if the logic in related scripts hasn't changed since v4 then there are likely no side effects or @miguelangeljop-png would have encountered them (at least for his use-case).

@miguelangeljop-png can you manually make the change proposed by @timschofield (#808 (comment)) and test for undesirable side effects? If you find there are none, we could proceed to add the exception case with more confidence. @pakricard is right to be cautious after finding:

...around 200 checks with this flag to prevent mixing up current and obsolete items: BOM's, counter sales, Internal stock requests, invent

[pakricard]

@dalers : If we allow this, can you please define what an "obsolete item" will be?

Impossible to say until we find out if adding an obsolete item actually triggers a PO or a WO,

True, impossible to say beforehand, but it can lead to inconsistencies, as having an obsolete item on a sales order and then needing to buy or manufacture the item itself (or any of its components) and webERP will not allow it.

R

[timschofield]

An obsolete item should definitely not be allowed on purchase or work orders.

I can however envisage a situation where an item A has been superseded by an item B, but you still hold a stock of item A that you want to sell off, and so I can see that there would be circumstances where you would want item A on a sales order. If item A shouldn't be sold at all (safety reasons for example) then it's stock should be written off, and the stock levels set to zero - effectively stopping it being sold anyway.

@pakricard I don't want to break your system, can we see a compromise that will allow what I have said above, but still work for you?

Tim

[dalers]

I read through the posts again and I may have been thinking the solution was more complicated than needed.

From @miguelangeljop-png,

I copy my customers PO which has some obsolete items because they still have inventory. In the older versions I didn't have that issue. Is there a way to fix this issue? I have more than 400 SKU and 40+ stores and it's complicated to remove al the obsolete items from the CSV.

I think the best way would be to ignore obsolete values. They appear in their POs because their system automatically reorders until they have 0 inventory - even if we have it marked as obsolete.

If I understand Miguel correctly, this means option 2 listed by @timschofield would be acceptable:

Aren't there 3 possible scenarios?
1 Abort when you reach the obsolete item, and leave it for the user to change the input data - Current solution.
2 Skip the obsolete item but import the rest or
3 Import everything including the obsolete items.

Option 2 would also be acceptable to @pakricard if I understood him correctly.

I led the discussion off the rails by seizing the opportunity to make a nice three-button radio button selector graphic.

Re the definition of "obsolete", I agree the scenario you described @timschofield is valid (superceding an item that still has stock on hand that is desirable to be sold but not re-ordered or manufactured), but I think using "obsolete" in this way would be contrary to the generally accepted definition and also The Manual, which says simply:

the stock item is no longer used.

So far as I am aware, webERP currently does not have a way to deal with this scenario, either an item is obsolete or it is not.

If webERP was to deal with this scenario, I suggest it be dealt with in a seperate issue. One solution may be to replace the boolean "obsolete" variable with a multi-value "stock item status" selector variable with possible values "unreleased", "released", "superceded", or "obsolete." "Unreleased" for items that are not yet approved for purchasing, manufacturing or sales (useful during the engineering product design process), "released" being equivalent to the current "not obsolete", "superceded" for the scenario described by Tim, and "obsolete" for items no longer used. Perhaps there is a way to merge this concept into webERP in a way that avoids updating the 200+ checks Ricard referred to, but I think it would be best left for another day (and another issue).

[timschofield]

I'm still not sure I get the distinction between superseded and obsolete. If I physically have stock of an item that I no longer want, then I have 2 choices, I mark that stock as not to buy/manufacture and then I either sell my remaining stock, or I physically dispose of the stock, write it off in my accounts, and reduce the inventory level to zero. The terminology I use for this really doesn't matter.

Tim

[dalers]

Hi TIm, I accept "no longer used" can be interpreted in a variety of ways and I had a very narrow definition - meaning not sold, purchased or manufactured (I was going to add "or not transacted in any way" but that would exclude reducing the stock quantity to zero). I think the best definition for now is simply how the code behaves when an item is set to "obsolete".

But back to the OT, how does everyone feel about changing the behavior from option 1 to option 2 only?

[miguelangeljop-png]

Hello: For me option 1 and 2 sound like a reasonable solution. Thank you

…

On 10/01/2026, at 4:53 PM, Dale Scott ***@***.***> wrote: Hi TIm, I accept "no longer used" can be interpreted in a variety of ways and I had a very narrow definition - meaning not sold, purchased or manufactured (I was going to add "or not transacted in any way" but that would exclude reducing the stock quantity to zero). I think the best definition for now is simply how the code behaves when an item is set to "obsolete". But back to the OT, how does everyone feel about changing the behavior from option 1 to option 2 only? — Reply to this email directly, view it on GitHub <#808 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4K6UG7HVZJZTBHQGQCU32L4GF7HFAVCNFSM6AAAAACQXQF2Q2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBWGU2DANA>. You are receiving this because you were mentioned.

[pakricard]

@pakricard I don't want to break your system, can we see a compromise that will allow what I have said above, but still work for you?

@timschofield : It is not "my" system, it is "our" webERP. I just happened to code those 2 lines ;-). Yes, if you feel it is better to remove this restriction, then I happily will keep it on my installation, no harsh feelings at all ;-)

Aren't there 3 possible scenarios?
1 Abort when you reach the obsolete item, and leave it for the user to change the input data - Current solution.
2 Skip the obsolete item but import the rest or
3 Import everything including the obsolete items.

I think option 3 is dangerous. It breaks the idea of "obsolete" item if we can sell it as any current item. Option 2 is reasonable, but user should be notified that some items are being skipped.

Being said that, I think my point is more a conceptual than practical one:

If we allow a door for an obsolete item to be sold (as an exception case); Wouldn't it be just safer and easy to keep the restriction and, in case you really need to sell an obsolete item, then the user is forced to flag the item as current, sell the item, re flag it as obsolete?

I mean, exceptions should not be easy to work with, so the user is conscious that something "exceptional" is going on.

Similarly: We don't allow (and I know @timschofield will back me 100% on this) to modify any financial transaction once reported, even if sporadically it would make user's life easier. Once gltrans is recorded, no update is possible. We force the user to insert a correction.

In Petty Cash module, we don't have an "authorize all expenses" button, so the authorizer has to take the effort at least to scroll over the expenses and think if they are legit and correct or not. Otherwise, authorizers could click the "authorize all expenses" without reading them, losing all the benefits of the authorization process.

One of the great benefits of an ERP is that it enforces a way to do things in a company, thus reducing human errors

One solution may be to replace the boolean "obsolete" variable with a multi-value "stock item status" selector variable with possible values "unreleased", "released", "superceded", or "obsolete." "Unreleased" for items that are not yet approved for purchasing, manufacturing or sales (useful during the engineering product design process), "released" being equivalent to the current "not obsolete", "superceded" for the scenario described by Tim, and "obsolete" for items no longer used. Perhaps there is a way to merge this concept into webERP in a way that avoids updating the 200+ checks Ricard referred to, but I think it would be best left for another day (and another issue).

@dalers This is a big modification. This obsolete flag is checked around 200 times around many scripts. It might then look like a "item life cycle" more than a flag. And different types of items might have different life cycles. Happy to start a discussion about it! P.S.: I currently simulate life cycle with stock categories, but could possibly benefit from a dedicated variable to control this.

Hi TIm, I accept "no longer used" can be interpreted in a variety of ways and I had a very narrow definition - meaning not sold, purchased or manufactured (I was going to add "or not transacted in any way" but that would exclude reducing the stock quantity to zero).

The item should be written off as current and the very last step should be setting the flag as obsolete. My POV: Once marked as obsolete, you should not operate in any way with that item, except if it converted back to current.

For me option 1 and 2 sound like a reasonable solution.

@miguelangeljop-png Option 1 is the current one, the one that caused your trouble in the first place. Did you find a workaround it?

R

[timschofield]

Hi @pakricard, when I said "I don't want to break your system" I was referring to your companies implementation of webERP. I know that you are already maintaining some differences with mainline webERP, but if further differences could be avoided that would have been my preferred option.

It seems to me that we have decided to go for option 2 (Skip the obsolete item but import the rest) are we agreed? This only requires the removal of 2 lines of code so is simple to implement, shall I commit it?

Tim

ps @pakricard - just to satisfy my professional curiosity what would be an example of an item where you still have stock of an obsolete item but you wouldn't wish to sell it off?

[dalers]

Option 2 is reasonable, but user should be notified that some items are being skipped.

What if the user had to click a check box to get Option 2? The default behavior would be Option 1 so no changes if the box wasn't checked (and no "always skip" system parameter). If the user checked "skip obsolete stock items", and there were obsolete items skipped, the form should report this to the user after the import was complete.

[pakricard]

It seems to me that we have decided to go for option 2 (Skip the obsolete item but import the rest) are we agreed? This only requires the removal of 2 lines of code so is simple to implement, shall I commit it?

OK for me! Probably this discussion came from our slightly different definitions of obsolete item. I'm happy to go with option 2), as it satisfy the majority of us, and for the ones using the most strict definition of obsolete ,this change won't break anything.

ps @pakricard - just to satisfy my professional curiosity what would be an example of an item where you still have stock of an obsolete item but you wouldn't wish to sell it off?

In my definition of obsolete, it does not happen, as we change the flag current to obsolete as the very last step. We try to sell / write off the item before.
Anyway, in retail, an example of an item you hold in stock that you don't want to sell of might be a defective item. You might still have it, as some components can be reused, but the dismantling process is not done yet, so in inventory you still have it.

I think the best idea of this conversation, is @dalers's idea to turn this boolean flag into a multi value flag, converting this current/obsolete life cycle, into a more detailed one. If we are keen to explore this route, we'll need to decide if we set up a predefined standard life cycle or allow different installations to have different life cycles, and how to move between stages, etc.

We should keep it on the to-be-explored-someday-list ;-)

R

[dalers]

best idea ... is to turn the boolean (obsolete) flag into a multi value flag, converting this current/obsolete life cycle, into a more detailed one. ... If we are keen to explore this route, we'll need to decide if we set up a predefined standard life cycle or allow different installations to have different life cycles, and how to move between stages, etc.

Let's move the product lifecycle discussion to a new topic while the ideas are top of mind. #813