Hi All,
I have a requirement that the quantity field (ReceiveNow) on the product receipt form should default to zero when the form opens. To achieve this, I’m editing the PurcheditLine form by extending PurchFormLetterParmDataPackingSlip as shown below:
[ExtensionOf(classStr(PurchFormletterParmDataPackingSlip))]
internal final class PurchFormLetterParmDataPackingSlip_Extensions
{
protected void setParmLine(PurchLine _purchLine, VendDocumentLineMap _parmLine)
{
next setParmLine(_purchLine, _parmLine);
PurchParmLine purchParmLine = _parmLine as PurchParmLine;
if (purchParmUpdate.SpecQty == PurchUpdate::All)
{
purchParmLine.ReceiveNow = 0;
}
}
}
The issue I’m facing is that setting ReceiveNow to zero causes the line to disappear from the form. Setting it to 1 works fine, and 0.001 displays as zero while keeping the line visible—but then it allows posting zero receipts, which isn’t acceptable.
I’ve tried debugging the standard code but haven’t been able to find anything that explains this behavior.
Question: Has anyone seen this behavior? Is there an internal mechanism that hides lines when ReceiveNow is zero? Do you think it’s better to override that condition or adjust the packing slip logic to block posting if the value is 0.001?
Thanks!
This seems to be about the same thing as Product Receipt Default Quantity to Zero.
As suggested there, you should use the debugger to find the piece of code responsible for this behaviour. For example, there may be a filter in the form, or maybe the problem isn’t that the record isn’t show in the form, but maybe it’s not saved at all when it has no quantity.
You can’t start designing a change unless you identify the actual problem.
1 Like
Thanks for the suggestion. I stepped through the debugger to look for any filters or block posting logic for ReceiveNow set to zero, but I couldn’t identify any obvious code causing the behavior. Which was why I had posted on here. Have you seen this issue before or found where the logic might reside? Any additional insights would be appreciated.
It also makes me wonder, since you can set the quantity to zero on the form, why the code is preventing zero being set as the default value upon form opening.
Let me show you a more systematic approach to problem isolation.
First of all, find whether the PurchParmLine was inserted or not. The answer will immediately makes (roughly) half the size of the code where the problem may lie and will tell you what to focus on.
If the record wasn’t inserted, you’ll know that you should look between you setting the ReceiveNow to zero and the place where insert() is called if you don’t do that. If you find that it got inserted, it’s either deleted at some point or it exists (again, you can test both these things) but hidden. In either case, you’ll know much more than at the moment.
Thanks for the systematic approach. I already know the record exists—if I set ReceiveNow to 1 or 0.01, the record shows up without issue. This clearly indicates that a zero value is treated differently. It seems some filter or condition is hiding or disregarding records where ReceiveNow is zero.
I’ll focus my debugging on tracking down any filters or event handlers that might be excluding these zero-value records. Any additional pointers on what specific areas to inspect would be appreciated.
You’re wrong. The fact that the record is created when ReceiveNow is not zero doesn’t prove that it’s created if ReceiveNow is zero. Imagine code like this:
if (purchParmLine.ReceiveNow != 0)
{
purchParmLine.insert();
}
You should test your assumption, otherwise you may be looking for a problem at a completely wrong place.
The Product Receipt lines come from existing PO lines, so the records do exist. Since the Product Receipt is accessed by going through All Purchase Orders → Selecting a PO → Product Receipt, it is directly tied to the PO and its lines. In multiple purchase orders, the lines exist and show up in the Product Receipt by default. This behavior is only happening when ReceiveNow = 0, so it seems more likely that they’re being filtered out rather than not being inserted at all—unless I’m misunderstanding something.
I’ll double-check to confirm, but if ReceiveNow = 0 is causing the lines to be hidden, I’m trying to track down where that filtering happens. If you’ve come across this before or have any pointers on where to look, I’d appreciate the guidance.
I was thinking of checking PurchFormletterParmDataPackingSlip, PurchFormLetter, or PurchParmLine, since that’s where I’d expect the data generation logic to be. Does that seem like the right direction?
Your statement The Product Receipt lines come from existing PO lines, so the records do exist shows that you don’t understand the purpose of PurchParmLine table. These are temporary records created for a particular posting. They’re generated based on the form configuration and may include just some lines of the selected orders or none at all. For example, look at the discussion in the previous thread about the Quantity option. If you, say, ask to get just registered quantity and you have none, no PurchParmLine record will be created.
That a purchase order lines exists says nothing about PurchParmLine records. There may be no such a record or many of them (for different ParmIds).
You already know about the class generating the parm lines PurchFormletterParmDataPackingSlip and you know that you can modify the quantity before inserting, but you somehow haven’t accepted that it happens.
Of course, finding the problem is difficult if you don’t understand the process you’re trying to debug and you refuse to look at potentially critical parts of it.
Please look at the existing code if you don’t believe me. For example, put a breakpoint to PurchFormletterParmData.insertParmLine() to see that PurchParmLine records are really created by the form; not when an order line gets created.
Oh, okay—so PurchParmLine records are created dynamically in PurchFormLetterParmDataPackingSlip and stored in PurchParmLine when the form opens?Since I know the grid pulls from PurchParmLine, that makes sense. And its not really filtering, but the logic is that if ReceiveNow is by default zero, then the record won’t be created at all.
I’ll debug insertParmLine() as you suggested to check if ReceiveNow = 0 lines are even reaching that step. But just to clarify—if a PurchParmLine record isn’t created for a line, would that typically be controlled directly in insertParmLine(), or could it be determined earlier in the process (like in setParmLine() or when the form retrieves lines)?
I just want to make sure I’m focusing on the right part of the process.
You can easily answer your question (if a PurchParmLine record isn’t created for a line, would that typically be controlled directly in insertParmLine()) by yourself. Look into the code; you won’t see any such a condition in this method.
Personally, I would put a breakpoint to PurchParmLine.insert() to see if the records get created. If so, your question isn’t relevant and I wouldn’t spend any time with it. If I found that the record wasn’t created, I would begin my debugging PurchFormletterParmData.createParmLine().