Sales Order line quantity can be zero. WHY?

Releases, too, of course.

I’ve known this from the beginning. But now I ask why?

Purchase orders cannot have zero quantity.

What is the use case for a sales order for zero of a part?

I mean, I have seen one, but it’s not enough of a reason:

  • Order line created for 1 EA. Make to order.
  • MRP makes a job tied to the line/release
  • Sales wants to delete the line. Can’t - there is a job tied to it!
  • Solution: make the order qty to be zero. Wait for MRP to run. Job disappears. Now delete the line.

Someone in sales brewed that one up, and I was impressed at the ingenuity.

However, all you have to do instead is delete the job or change the demand link, etc.

Anyway, I’m off to make a simple BPM for this. As you can imagine, we got bit by this today.

But I’ll probably submit an Idea for it. So that it can be rejected. Because there is bound to be someone who relies on it. Well, maybe make it a setting or something.

1 Like

KIN-I-5923

1 Like

A placeholder for a pending (or lost) sales opportunity?
Didn’t say it made sense but that’s all that came to mind.

2 Likes

We use this functionality a few different ways:

ONE: To help sync our sales order lines with customer PO’s (on occasion).

For example we quote 5 items. We get a PO for 5 items. We enter a sales order for 5 items.

Customer then cancels item 4. We don’t necessarily want to delete item 4 from the sales order (for record keeping purposes). We change the quantity to zero and add some comments. Demand disappears and we can happily move on.

This also keeps the invoicing consistent. We have some customers who require consistency across documentation… Quote Line numbers need to match Sales Order Line numbers which need to match the customer’s PO Line number which need to match our invoicing Line numbers.

TWO: We also use it for items we want to appear on a sales order… but may be included and shipped as an assembly. So, sales order includes 4 lines.

  1. Full Assembly
  2. Top Part
  3. Middle Part
  4. Bottom Part

We’re only SHIPPING Line 1. It holds the price. The other lines have zero quantity and zero price. But they appear on the sales order, again, for record keeping and keeping our documentation and customer documentation in sync. Yeah, I know, this could probably be done in more official ways, but its an easy work around. In this case we would create a job for line 1 and include lines 2, 3 & 4 as subassemblies on the job. The Sales Order is an easy record for what was sold… but we only ship and invoice line 1.

THREE: We’ve also used this for repeat orders. Copy a previous order, but then remove a line the customer didn’t want this time. Yes, we could delete the line. BUT, the next time the customer places the order, they want that part again. So then we’d have to put it back in… but they want it to appear as line 6 in a 10 part order. Well… you CAN’T REORDER LINE ITEMS! So, we would have to either start from scratch or delete most of the lines and manually put them back in after reinserting that part as Line 6.

The easiest thing to do, is to use a previous “master order” as a template. We copy that “master” each time and use the line item quantity to toggle particular lines on/off for a specific order.

Again, are there other ways to do it? Probably. But being able to have a line item with zero quantity has come in useful.

5 Likes

That all being said… I’m okay with your “Idea” because you’re suggesting a setting in Company config to control it.

Akin to allowing supplier pricing to be change upon receipt. Its valuable to us. May not be to others. So, being able to turn that on/off in Company Config is the right solution. Its then up to individual companies to allow it or not.

2 Likes

So do we, we’ve also created a BPM for the cases where we do NOT want the line price to be zero. Also a screen customization that turns the price field RED if it’s zero.

Can’t you just void the line? Then you would still have the history of the qty too

2 Likes

Yes, but a voided line won’t print on the OrderAck. Which, yes, in some cases is good. But in other cases, we want all lines to show.

In our case we actually put in a directive so after closing/voiding order lines, the voided checkbox is unchecked in the background so that those items still WILL appear on the printed OrderAck. So, yes, we DO do this at times.

We could be doing a capital turnkey system, for example. Part of the way through the project the customer cancels a line. We WANT to show that it was initially part of the order. We set the qty to zero and add comments “cancelled by customer on Change Order XYZ dated 1/10/2025”. That all prints on the OrderAck.

Again, this is a case-by-case “works for my company” type of thing.

I’m not disagreeing with the Idea… I’m saying I agree that it should be an optional setting in Company Configuration because there are instances where it could be utilized.

4 Likes

I can see this.

With job material, I recommend the same idea of zeroing out the quantity. First, because you may not be able to delete the line. But second, because retaining it lets people know, “I know I’m not crazy there was demand for this before, right?”

This gets on a whole other tangent of enhancement request, but it would be nice when you get denied by some error message, if it also said “Did you know that you could change this setting in Company Configuration? Ask your system administrator today!

Well… maybe worded in some cryptic way rather than blurting it out like that.

I do this with BPMs that I make. The last line of the error says “This is a method directive on SalesOrder.MasterUpdate” or something like that. Which is code for, “Jason did it.”

4 Likes

Yeah, this is akin to me wishing they had better field help descriptions that would include information on module dependency. I’ve wasted a ton trying to figure out why a field wouldn’t work… or trying to research what a setting does… only to find out it is for a specific module which my company doesn’t even have!

A little more effort in the descriptions would go a long way!

4 Likes

I have a similar disclaimer on my BPM messages. So when a user submits a ticket it’s easier for me to know which BPM they’re referring too. Assuming they submit an image of the error (which is not always the case)

2 Likes