Blocking Product Receipt Posting for ReceiveNow Quantity Less Than 1

Finance and Operations/AX Developer Forum
1

I’m trying to implement a new requirement within the Product Receipt form (PurchEditLines) where users should be blocked from posting ReceiveNow quantities less than 1. Some users have been able to post receipts with values like 0.5 or 0.005, which later causes issues with the purchase order. If another packing slip is entered after a small quantity like 0.5 or 0.005, it results in an error.

Currently, the system prevents posting when the quantity is zero, and I want to extend this functionality to block any values less than 1.

I’ve been trying to locate this logic but haven’t had success. I used the debugger to track the messages:

“Posting Purchase order: XXXX No lines for posting or quantity = 0.”
“Posting - Purchase order: XXXX - Posting has been canceled.”
However, none of the references to these messages seem to be tied to the ReceiveNow logic in the product receipt process. I’ve also debugged parts of the standard code but haven’t been able to find where the validation occurs.

Has anyone dealt with something similar or knows where this logic might be handled?

2

This requirements sounds suspicious to me. This should depend on the configuration of the item and the unit. I shouldn’t be able to receive a half of TV but what why couldn’t I receive a half ton of sand?

3

Hi Martin,

The company I work for is a commercial construction company, so we don’t handle bulk materials like sand or gravel where partial quantities might make sense. Instead, we deal with construction-related items like plumbing fixtures, ceramic tiles, adhesives, and similar materials, which are typically managed in whole units rather than fractional amounts.

For example, a product receipt might include 5 ceramic tiles, but we might only receive 3 in a given shipment. In this case, we want to allow partial fulfillment (e.g., receiving fewer than ordered) but still ensure that each unit is received as a whole. We wouldn’t want users entering values like 0.5 ceramic tiles or 0.3 sealants, as these materials aren’t used or stocked in fractions.

That’s why we need to extend the existing restriction (which already prevents zero quantities) to also block any quantity less than 1.

Do you know where I can find the logic that currently handles the validation for zero quantities? I’ve tried debugging around the error messages related to posting cancellations, but I haven’t been able to track down where this check is implemented for ReceiveNow. Any guidance would be appreciated!

4

But then your actual requirement is different. Not just that 0.5 of a tile makes no sense, but 1.5 or 2.5 either. It’s not about quantity smaller than one, but about fractions.

F&O already can do that, you just need to configure your items correctly.

I’m not a functional consultant, but I think can configure these things in the Inventory part of default order settings.

image
image892×646 37.6 KB

5

Hi Martin,

I see your point, but in this case, this is a specific user requirement—they want to ensure that the ReceiveNow quantity cannot be less than 1 for any product receipt (PurchEditLines), regardless of item configuration.

This requirement came up because a user accidentally entered a 0.5 quantity, and after that was posted, any subsequent postings were rejected, causing issues with processing that purchase order. While this specific case could have been corrected manually, the concern is that any fractional quantity below 1 (e.g., 0.5, 0.3) can lead to the same problem. Users typically work with whole-number quantities, so they want to proactively prevent any accidental entries of fractions below 1 rather than relying on cleanup after the fact.

At this time, there hasn’t been an issue with quantities greater than 1 that include decimals (e.g., 1.5 or 2.5). The problem seems to be specific to values below 1, which is why the users want this restriction in place. If future cases come up regarding larger fractional quantities, we can revisit it, but for now, the request is strictly about blocking values less than 1.

Ideally, they want this to behave the same way the system currently blocks zero-quantity product receipts—where an error prevents posting if the quantity is 0. We need to extend that same validation to also block any value below 1.

Since I know the system already enforces this restriction for zero quantities, I’d like to find that existing validation and extend it rather than implementing something entirely new. Do you know where that logic is handled? I’ve checked around the error messages related to posting cancellations but haven’t been able to track it down yet.

I’d really appreciate any guidance on where to look!

I’ve attached a screenshot of the Product Receipt form where this issue occurs. The ReceiveNow quantity is entered here, and we need to enforce the restriction at this point. Let me know if this helps clarify the request!

image
image2259×843 51.8 KB

Thanks!

6

You seems to be saying that values like 1.5 are wrong but you’ll do extra work to design a solution that keeps this bug in place just because the users haven’t explicitly complained about it. It doesn’t even mean that it doesn’t cause problems, just that it hasn’t been reported. Also, users aren’t analysts and software engineers - it should be your role. You should realize that the underlying problem is about fractions and not just about the interval from 0 to 1. You’re currently putting users to the position of solution architects, implying that you can’t help them in that area. Consider whether you really don’t want to do more for your company or clients.

Anyway, what if you set Min. order quantity for purchase and inventory to 1?

7

Hi,

I would not write code for this requirement.

The solution Martin mentions in his responses would be a better way to go, that is using the default order quantiles for purchasing (minimum and possibly multiples of 1).

You could also setup a new unit of measure that has zero decimal places and use that as your purchasing unit of measure on your released products - as you already have inventory and transactions you would need to setup a 1:1 unit conversion but new items could use the new unit for purchasing and inventory units.