[In this series, we’re looking at quick fixes to improve GP security.]
When people hear “three-way” in a conversation, inventory is usually not the first thing that comes to mind. When someone says “Three way match” in an accounting system, they are typically referring to the purchasing process where the receipt of goods is matched to a purchase order and the invoice is then matched to the receipt, i.e. three matching points so a three way match.
The idea behind this process is to ensure that the supplier provides and invoices goods that were ordered, at the ordered quantity and price. If preventing supplier fraud was all that mattered, this would be easy. However, the inventory process lends itself to lots of opportunities to either defraud the organization or defraud investors. The Crazy Eddie fraud provides a classic example.
In the case of GP, separating purchasing, receiving, and invoicing provide additional defense against inventory fraud. For example, if a user has access to create a P.O. and receive goods they could order items for personal use and have the company pay for it via the purchasing process. The problem would wash out as a missing item in the inventory count and as a long as the fraud didn’t occur too often, it might never be found.
The inventory process should be full of compensating controls like P.O. approvals, physical inventory control, inventory counts/cycle counts, etc. Often though, these controls loosen up over time, so a regular review of controls is important.
P.O.s are controlled via the Purchase Order Entry window. This window is present in the default task TRX_PURCH_001*. The primary receiving window, Receivings Transaction Entry, is in TRX_PURCH_004* and Purchasing Invoice Entry, the main invoice entry window is TRX_PURCH_005*.
That seems simple enough except that both TRX_PURCH_004* and TRX_PURCH_005* give access to enter receiving and perform invoice matching. The descriptions on the tasks are deceiving and these tasks are combined in multiple roles. All of this works agains segregating supply chain elements. Separating these elements into multiple tasks and splitting them into individual roles is a great place to start getting control of the purchasing and inventory process.
There is one more quirk in GP purchasing. The Receivings Transaction Window allows receipt of a shipment of goods, a combined shipment/invoice, or an intracompany transfer. Securing the shipment/invoice process, where a shipment and invoice are entered at the same time is a challenge in GP. Field Level Security is tough to use here because this is a required field, but there are some options.
To secure shipment/invoice functionality, a password can be applied using Field Level Security that essentially locks the field to shipment. A password is then required to select a different option. This works well, until companies need to receive intracompany transfers and don’t want to give out the password. Other options include using VBA to control selections on this field or Modifier to change the name of shipment/invoice to something else. Changing shipment/invoice to “select to get fired” would probably be mostly effective, but there would still need to be a review to follow through on that threat.
This thread on the Dynamics Community site has additional details on the options to control shipment/invoice: https://community.dynamics.com/gp/f/32/t/155836
You can find all of the fixes in this series at GP Easy Security Fixes.