Add Posting Validation Logic to Release

kelseykong@hotmail.com

Dear expert

One of our customer wants to have all the validation logic for posting a Purchase Invoice added to "Release" function on Purchase Order.

However, the customer has assigned different permission groups to various users. Some of them are allowed to release a PO, but cannot post a Purchase Invoice. Neither can they edit an Item Card.

We have added all the validation logic from posting a PI to the Release function. However, the issue is that the user keeps receiving errors regarding that they don't have the permission to insert in certain tables, such as Item Ledger Entry table, which is the logic for posting a PI. This does not make sense, since the user does have the permission to release an order, and should not see the irrelevant information. In addition, users will not be allowed to release a order due to those errors.

May I know if there is any suggestion regarding how to achieve the requirement without affecting users' normal operation?

Thank you.

Li

Yogi1983

Hi Li,

If I understand it correctly you want to automatically post a purchase invoice after releasing a purchase order? My first question is what the business logic is behind this requirement? Since you mention Item Ledger Entry I assume the purchase is item related. Normal business rules would require that a purchase receipt is posted first and that this receipt is matched with the purchase order and invoice (three-way match principle).

Furthermore technically, if you automatically post purchase invoices after releasing a purchase order, the user who releases the order has to have also permissions to post the purchase invoice. Just because you program it behind a certain trigger / function does not mean the user who performs the action does not need the permissions. So in this case you would have to assign the permissions for posting a purchase invoice to all users who must be able to release a purchase order.

But I would first review the business requirement very carefully.

jglathe

Hi Li,

kelseykong wrote:

We have added all the validation logic from posting a PI to the Release function. However, the issue is that the user keeps receiving errors regarding that they don't have the permission to insert in certain tables, such as Item Ledger Entry table, which is the logic for posting a PI. This does not make sense, since the user does have the permission to release an order, and should not see the irrelevant information. In addition, users will not be allowed to release a order due to those errors.

This sounds strange. How did you implement the validation logic? If I understand the requirement correctly, you want to simulate the posting without actually committing it. This would be the only way to be sure that the posting can go through. This is no easy task IMO, you have several issues with this:

- Even uncommitted inserts require the permissions (what you already found out).
- You lock the system for other posting runs, that's the practical effect of it in the end.
- With the simulation run, posting numbers will be fetched and retained (like in a failed posting too). This can be done intentionally, since even number series limitations can lead to a failure when posting. But it may be not the desired outcome.

You would need to write up a posting routine that doesn't commit anything anywhere, and do an "ordered" fail even on success, without killing your execution context. And you would need a proxy user who has the permissions to actually post. And you need to get your document into this execution context from where you are, and the information back. Sounds to me like an asynchronous job, preferrably run on the NAS service. But not easy to do.

with best regards

Jens

Miklos_Hollender

I wouldn't do this, I would not accept this requirement this way, as Jens wrote it is either very difficult or incorrect. It would be a sensible requirement - Navison could and should put the checks into a separate codeunit, like how it is with item journal, CU 21 or 11. But it is simply not done so, and the way it is structured it does not lend itself to this.

So I would identify the most common kinds of problems. Which, I think, will be dimensions, at least, since we stopped using the durned things, my blood pressure is way more normal Frankly the common mistakes outside missing dimensions are not that many. Maybe a blocked vendor or item, maybe posting groups missing in item, vendor, that is roughly it, a few more. Just check for these and for everything else the people booking the invoices complain about.