Re: A/P P.O. Price VS invoice price

The names of BPCS programs can vary with BPCS version. We are 405CD.

BPCS PUR INV AP GL come with assumptions which can be invalidated by a
company's practices, and too many cooks not doing a good job of
intercommunicating the role of what everyone sees in the flow chart of
information flow.

Is your standard cost considered to be standard, it never changes except
when new item entered, and annual review? Or do you change standard
whenever vendor changes prices? When is it acceptable for vendor to change
price?

We fax PO to vendor, including date of delivery, unit price involved. We
ask them to return the fax signed or corrected, so we know what to expect.
If they sign agree to price, then invoice us different, we call them on it.

Do you have an end fiscal report showing total inventory according to
on-hand times cost is $2 million, but the total in GL is $20 million?
Do you have wild GL accounts where the grand total swings wildly in
different directions month to month?
Do you have GL accounts where the grand total seems to grow to infinity?
If so, then how you are handling CST PUR ACP could be at the root of it.

We have new items, which ought to be cost entered before any transactions,
but sometimes delayed, as lead times shrink. When the cost fixed has impact
on General Ledger, inventory valuation, and what we call unvouchered
payables (where we have received goods but not yet received an invoice).
There's your scenario. There's timing of vendor price increases.

Some people use the terminology "uncosted" for "unvouchered."

We also have unit of measure errors. If the variance shows that the
difference between actual and standard cost is one is like 10 times the
other, that is probably a unit of measure error. If not, the next suspect
is a partial shipment, where full invoice paid, but only for a partial
delivery.

What can happen also depends on your system parameters, and end fiscal month
choices for jobs like PUR900 and ACP900. We use standard cost for rollups.
This is unaffected by wrong costing in vendor invoices, whose price goes
into actual cost. There's what General Ledger accounts this flows into.

Suppose an item has wrong standard cost at time of inventory receiving from
PO. This puts wrong value into unvouchered GL. Suppose that cost is fixed
before invoice paid. Your inventory valuation reports will now be correct,
but there's still garbage in unvouchered.

Suppose an item has wrong standard cost at time of AP invoice entry. That
causes bogus material variance results. Resolving this kind of thing is
complicated by partial shipments.

Suppose after receiving, we discover a problem with some shipment and try to
return it to the vendor. If the PO was received in full, it is now closed,
and BPCS won't let us credit it. This then drives a big mess matching
credits against vendor invoices. If you have significant returns to
vendors, you need to be vigilant making sure you get proper credit. BPCS
won't catch it for you.

PUR and AP come with some reports, and we can add to the collection via
query and programs. We can run list of inventory on-hand, recent
acquisitions, where standard vs. actual cost has a variance.

We run a query list of POS not yet received whose standard and actual costs
are missing. POS have an expected cost.

Most important, at time of invoice entry, there's reports on variations,
where the price paid is contrary to the price expected, or standard vs.
actual for purchased items.

There's a report listing 3 way mis-match. In theory, we order specific
items from specific vendors for specific prices, we receive what we ordered,
we pay what we expected. In reality there is a hell of a lot of mismatch.
There's a BPCS report listing the mismatches. We did not like the sequence
of that report, or how the cost was calculated, so we modified it to make it
more intelligible.

PO receiving generates (for us) a U transaction, which we post to GL as a UP
transaction. This contains item, vendor, PO, quantity, standard cost.

AP invoicing generates a C transaction, with related info to GL. This
contains item, vendor, PO, quantity, actual cost.

We can match the U and C activity, or the GL equivalent, to total up by item
vendor PO activity over several weeks, to find where there are patterns of
discrepancies, of great significance.

This exercise showed us that a lot of the BPCS documentation, about what is
going on, is in fact bogus, with lots of holes. For example, BPCS lets us
pay for the same vendor shipment more than once, so when we are dealing with
crooked or incompetent vendors, or improperly accounted for returns, or how
to manage partial shipments, we can end up paying for the same shipment
three times over, and BPCS won't catch it, unless we are very careful with
the report analysis.

For example, a vendor uses the same invoice # billing us for partial
shipments. BPCS says that invoice has been paid (we paid for an earlier
partial shipment), so we enter invoice # 12345 as 12345B or 12345C.
However, when our payment crosses in the mail with their copy of an invoice
they claim we have not yet paid, the accounting clerk thinks it is the same
kind of scenario as partial shipment, and pays the invoice again via 12345C.

You can have monthly payments for services. The services end, the billing
does not. BPCS won't catch this for you. There needs to be good
communications between the accounting personnel and depts., getting the
services, to know when the obligation to pay, ends.

-
Al Mac


-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Jeff Elam
Sent: Monday, November 07, 2011 6:31 AM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] A/P P.O. Price VS invoice price

We had a situation last week where we found an invoice price had been costed
incorrectly and didn't match the original PO price. Obviously this affected
our cost after roll ups etc. I was asked how this could be caught in the
future. It was mentioned that an employee no longer with the company used
to run a report that displayed discrepancies such as this. Unfortunately
nobody could remember which report it was. Any ideas?



Thanks,



Jeff