RE: Purchase Orders for Utilities, etc.

[Dan Karwatka]

I've been lurking for some time. I thought I could throw my opinion in here
because we use all of the mentioned features in our current accounting
system.

1. I believe if you want you can "lock" the business process by having
selectable module default settings such as "AP invoices require a PO (y/n)".
This can be carried further by applying this type of setting to a vendor so
POs would be required for specific vendors.  A similar type of setting could
also be used to override a system default.

2. We create requests from items that are backordered in Order Entry and
from our Inventory Replenishment module.

3. Our system is structured that most POs are created by Requests (Purchase
Requisitions).  These are allowed to build, until there the requirements are
met to order from a particular vendor, then they are placed onto a PO.

4. POs can be created manually or from Requests.  POs can also be manually
edited so as to add or subtract items.

5. All inbound shipments go through a Receiving process.  This designates
the qty received against the expected qty from the PO.  This also posts to
Inventory and an AP Holding GL Account since this is a payable but no
invoice has arrived yet.

6. When vendor invoices are received they are created by retrieving what is
expected to be invoiced by what has already been received.  At this point
only the qty, pricing, freight tax, etc are checked against invoice and a
Payable is Created ($ are moved from Payable Holding to Payables).

7. For non-saleable goods, services, rent we create a payable using an AP
Document which directly specifies the GL accounts.  No sense in creating a
vendor and a PO for a one time purchase of Girl Scout Cookies.

Throughout the system we try not to type in any information more than once.
This goes for item codes (part numbers or SKUs) that are picked up from the
Order Entry system or from our Inventory Control system and carried through
Requests into POs.  It also goes for Quantities, Costs, Freight etc.

Additionally, we try to keep people away from GL account numbers whenever
possible because most people don't know which way is up when it come to the
GL.

By breaking up the processes, specific goals are applied to each step. This
inherently builds in cross checks especially when done by different people.

Daniel Karwatka
IS Manager
Union Electronic Distributors

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of Derek Neighbors
> Sent: Thursday, March 27, 2003 12:22 PM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: Purchase Orders for Utilities, etc.
>
>
> Stanley A. Klein said:
> > 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.
>
> I think this discussion was cross posted between GNUe and GNUe-SB.  I
> would like to clarify that things and decisions that apply to GNUe may not
> necessarily apply to GNUe-SB.
>
> > 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.
>
> Absolutely.  In GNUe-SB especially in early versions, there will not be
> the "intelligence" in all instances to accomodate this.  It is part of the
> "get somethign out the door" approach we are using and have made our peace
> with.  GNUe Proper should have the let the enterprise choose as its
> cornerstone of implementation however.  This is one reason why GNUe-SB was
> started.  We didnt want people to thing GNUe Proper was changing its
> ideals.
>
> > 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.
>
>
> GNUe Proper should definitely not be insisting on anything, but by no
> fault of its own, GNUe SB might do dictation in some areas in order to get
> something working with out over complicating it.
>
> -Derek
>
>
>
>
> _______________________________________________
> Gnue mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue