Re: Purchase Orders for Utilities, etc.

[Stanley A. Klein]

In my view, the issue of whether GNUe should require purchase orders in
processing accounts payable is a business process issue in which GNUe
should be neutral but should be prepared to support all alternatives.  It
is not for GNUe to determine whether any particular business process should
be followed.

The business processes of any enterprise using GNUe should be left to the
enterprise to determine.  We should give users the tools and guidance for
implementing their own decisions.

We should not get into the same situation as other enterprise software
providers who take the attitude that "if your business doesn't match our
product, change your business."  :-)

In thinking about what business processes to support, it may be useful to
consider the categories of enterprises I identified in the draft security
framework.  In a sense, business process issues are related to security
issues because security is the means by which enforcement of the business
processes is assured. 

For a very small business, there may not be a need for purchase orders.
The owner of a very small business (e.g., a one-person business) knows what
has been ordered, and the main purpose of a "purchase order" may be if it
helps the business process at the supplier or is useful for legal "battle
of the forms" purposes related to terms and conditions pre-printed on forms.  

For a medium size business there may be a need for purchase orders related
to accounts payable processing.  For a large business, I have seen
processes where there is not only a purchase order but also a purchase
request.  Only the purchasing department can produce the purchase order.
The purchase request comes from the person who wants the item purchased and
must be approved against budgets and filed with the purchasing department
before a purchase order can be issued.  When the item arrives, there is
either an incoming inspection done by the quality control department or an
approval form that goes to the original requester and must be approved
before payment is made.  Sometimes the process depends on whether the item
is a regularly purchased item or a "one time" purchase.  All these
processes relate to the "separation of function" which is a key principle
of security in the area of integrity, and indeed was adapted from common
business practices that counter embezzlement.

So GNUe shouldn't be "insisting" on anything, but should be surveying the
practices of enterprises, structuring itself to support the practices it
observes, and providing the flexibility and tools for an enterprise to
implement its own processes and practices.


Stan Klein



At 06:58 AM 3/27/2003 -0500, Peter Sullivan <address@hidden> wrote:
>Picking up on a conversation from IRC yesterday...
>
>Actually, there is a good case for making people raise Purchase 
>Orders (either call-off/blanket POs in advance, or specific POs 
>retrospectively) even for things like utilities and rent. It has 
>nothing to do with the system per se, but reflects the fact that 
>systems get used by people (i.e. fallible human beings). 
>
>If you have a business process where some AP invoices need to be
>matched to POs, and some where the AP invoice is input direct, 
>then you create a "corridor of uncertainty"* within the minds 
>of your AP input clerks, and the scope for them to get things 
>wrong. At its worst, this may result in them doing just the 
>most perfunctory of checks for a matching PO, before concluding 
>that "this must be an invoice that doesn't *need* a PO" despite 
>clear external evidence to the contrary (e.g. description of 
>goods as clearly PO-able). So they input it as a direct AP 
>invoice, rather than matching it to a PO.
>
>This then means that the commitment record in the General Ledger
>(for Orders Raised Not Received) never clears, which the 
>budget manager for that cost centre may or may not notice, 
>depending how keen they are on commitment accounting anyway. 
>Multiply this over time by hundreds or thousands of POs, and 
>you have an out-of-control situation.
>
>This is not just a theoretical problem. I spent quite a bit of 
>time with at least two clients of my last employer trying to 
>unpick this, and one of them eventually had to write off all 
>outstanding POs more than six months old, on the grounds that 
>they "must have been delivered, but the invoice input wrong."
>And when we were doing site visits for the ERP system we are 
>implementing at my current job, one of our reference sites 
>had exactly the same problem. (I deliberately haven't named 
>either system, as it's not the fault of either system.)
>
>By insisting that every AP must have a PO, you force people to 
>do sensible checks before firing the invoice back to the 
>originator and asking why a PO wasn't done for it. (Depending 
>on your company procedures, there may be varying degrees of 
>"acceptable excuse" here.) Ending up with 'non-intuitive' 
>POs for things like Utilities and Rents is the lesser evil 
>here.
>
>The other alternative, I suppose, is to put some intelligence 
>into the system, so that each account code within General 
>Ledger has a flag on it that says whether a PO is required 
>for AP invoices to that code. If the flag was set, which 
>should probably be the default, the system would refuse to 
>allow a direct-input AP invoice to cost there, but would 
>require it to be matched to a PO instead. If the flag was 
>not set (for example, on Payroll, Utilities and Rents codes)
>then direct input AP invoices would be OK. Having said this, 
>I am not aware of any system that does this as of time of 
>writing, so I wonder if there is an obvious flaw with this 
>that I've not spotted.
>
>-------------------------------------------------------------
>
>* My apologies to Geoffrey Boycott (now *there's* a phrase I 
>never thought I'd type) for (ab)using his cricket-related 
>metaphor.
>-- 
>Peter Sullivan
>