BC Idea | Disable printing for Purchase Order under Pending Approval Status

This original idea posted by user YOKE MAY TANG on 7/31/2019 collected a total 135 votes at the time of development and I chose this one to be my first development because of its simplicity considering the total vote count.

In the original post, the user requests:

Would like to prevent PO to be printed/emailed to vendor while the PO is under Pending Approval.

It’s a simple statement, and it seems to be pretty straight forward, right? But it does have a few caveats to be considered.

When users told me in the past they would not like BC to behave in a certain way until an approval process has cleared, it was mostly because they didn’t want users taking a shortcut in the process.

In this request, if we take it literally, it would be very easy to create a block (maybe an Error message?) to prevent the user from printing the Purchase Order document if Status equals “Pending Approval”. But if you really analyze this further, only blocking this for “Pending Approval” status wouldn’t make much sense…

What if the user simply printed the Purchase Document BEFORE requesting an approval? Then this block would be pretty useless, right? ⌛


Implementation Details

Having this in mind, what makes more sense, is to actually prevent the printout if the status is not released. This means that even POs with status “Pending Prepayment” will be blocked from printing the Purchase Order document.

Having established that premise, we now need to then determine, in the code, where will we put this block?

In some of the comments, one user mentioned that it would be pretty easy to implement this block directly on the report, but I see one problem with that approach: a large majority of the customers customize the Purchase Order report. Most of them, yes, they reuse the original report as a base, and some of them, might probably be using Report Extensions. What about that small percentage that are developing the Purchase Order report from scratch, or even migrating those from a previous Business Central version…? Therefore, there’s a chance that the developer customizing the Purchase Order document will forget to put this block in place, and the whole feature goes down the drain.

Therefore, I chose to actually subscribe to 3 specific events:

  • Table Purchase Header:OnBeforePrintRecordsopen_in_new
    • This one is triggered right before BC tries to print the Purchase Order report
  • Table Purchase Header:OnBeforeSendRecordsopen_in_new
    • This one is triggered right before BC tries to send the Purchase Order report by e-mail
  • Codeunit Document-Print:OnDoPrintPurchaseHeaderToDocumentAttachmentOnBeforeRunSaveAsDocumentAttachmentopen_in_new
    • This one is triggered while BC is trying to attach the PO to the PO itself

With this, no matter if you use the standard out-of-box report, or if you use a custom report on the Report Selections, our block will most likely work as expected, when you trigger does actions from the PO Card or the PO List.

Settings

To enable this BC Idea, visit the BC Idea Feature Management page and search for the original title on the list.

Once you enable it, you will find a new setting under Purchase & Payables Setup (under FastTab BC Ideas Features):

  • Disable Printing Unreleased POs
    • This setting will be enabled by default when you activate the feature, and it will prevent users from printing/emailing/attaching the PO document, if its status is not released.


Purchase & Payables Setup

To disable this, you can either disable the setting on the P&P Setup, or you can disable the BC Idea feature altogether.

If you need to set permissions on who can enable or disable this feature, you need to restrict this permission on the Purchase & Payables setup.

Disclaimer

If you do enable this BC Idea, please use it at your own risk. Truthfully there’s not a lot of risk here but you have to be mindful of any potential conflicts with other existing extensions in your environment. Also, don’t forget to always try these features in a Sandbox environment first, and have users test it before really deploying to Production.

That’s it! 🎉

If you liked this idea, this development, or if you have questions or comments about this, don’t hesitate to react and/or post on the discussion below (you will need a GitHub account).