The audit trail from data entry of AP invoices, also generates an AP general
ledger journal batch. If your GL journal settings have allowed for details,
the entries spell out the account which gets the variance between old
standard and new actual, what item vendor invoice triggered that variance.
When no variance, no entry to GL. Look at layout of GJD record, to see
which fields are item vendor invoice, then use that to list in whatever
sequence you prefer, to identify which vendor invoices had price changes.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Al
Sent: Monday, November 07, 2011 9:37 PM
To: 'BPCS ERP System'
Subject: Re: [BPCS-L] A/P P.O. Price VS invoice price
The actual keying of the invoices to be paid generates an audit trail.
That audit trail details what info goes to what Gen Led accounts, including
what is done because the invoice price does not agree with our standard
cost.
That audit trail comes from the very person who keys in the AP invoices.
It is a huge cluttered report. Our personnel generally only interested in
seeing the cases where the vendor has changed the price on us again, but
that data is buried in mountains of data where there is no problem.
There are in fact multiple BPCS reports in which info we need is buried in a
mountain of valid data. You could ask your IT dept (unless that is you)
about naming conventions associated with stuff added, which did not come
with BPCS.
As far as I know, there is no simple report which comes with BPCS that does
what you are looking for. It has to be something that someone added.
We use a query/400. The C transaction goes into ITH inventory history,
showing item # actual cost, other info. We can then list items where the
invoice from vendor has a suspicious pricing.
The actual cost does not flow automatically into the standard cost.
A human being has to transcribe the change.
We used to do this at time of price change.
We now do it annually, because standard cost is not supposed to fluctuate
during the year.
If it is flowing automatically for you, then you either are using a program
(which did not come with BPCS) to do it, or your tailoring settings are
different from ours.
At our company, the issue is not that the price is wrong, but that we HAVE
to enter the price from the invoice, so we can pay the invoice.
If the price is wrong, the invoice should never be keyed in.
Someone has to get with the vendor, and have them replace the invoice.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Jeff Elam
Sent: Monday, November 07, 2011 11:00 AM
To: 'BPCS ERP System'
Subject: Re: [BPCS-L] A/P P.O. Price VS invoice price
We are also on V4.05CD (Sorry, I should have mentioned that before).
Our issue is when the invoice price entered doesn't match the PO price.
That's the report I'm looking for. Our AP person keys the wrong price in
from the invoice etc. That blows through Actual Cost then gets transferred
to Standard cost. According to one of our current AP individuals she's seen
that report in the past but has no clue as to how it was ran and the person
that ran it is no longer here.
Thanks,
Jeff
-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Al
Sent: Monday, November 07, 2011 9:59 AM
To: 'BPCS ERP System'
Subject: Re: [BPCS-L] 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
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message email:
BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/bpcs-l.
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message email:
BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/bpcs-l.
midrange.com
