× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This is great information and I thank you very much for the detail.  UML 
(Unmatched Liability) is what you are calling unvouchered.  From your 
research and findings - was there a screen or field you could reference to 
see how the PO receipt will be valued prior to the receipt transaction 
occurring? 

Our "ACP500 lady" has also expressed the same experiences you described 
and she recently took over the AP position from an hourly person who 
processed "like a robot" - unfortunately I need more process thinking in 
this position, supply chain management of AP.  Well, in the course of this 
transition, our A/P accounts, which has never been the problem, developed 
a couple of million dollar difference between the aging report in BPCS and 
the G/L.  This has never happened, I have always been able to rely on this 
account being in balance, if not the UML or unvouched material account. So 
now all my A/P accounts are out of balance and although I see the problem, 
macros are systematic in nature, I cannot find anymore in the alias, 
macro, events, what the system is referencing for the calculations. 

I will review these other threads.  We are an automobile supplier 
manufacturing company and we have detailed bill of materials, a 6800 
account that seems to be a "black hole" for production reporting which the 
balance is just put back into inventory each month, an MRP system that is 
managed with external Excel spreadsheets and I have been a champion of 
creating a work environment that forces employees to input accurate data 
into BPCS, we've had a great company Unbeaten Path come train us, 
management is visual on the financial implications of misunderstanding of 
BPCS, yet I cannot yet that complete understanding I need in order to 
reconcile our payables and inventory correctly.  We are doing quarterly 
physical inventories this year so we limit our inventory variances and 
catch them quicker.  I know it stems from many issues here, in processes, 
but in order to provide guidance I have to know what I am talking about 
with BPCS and these exceptions I find do not help.  But don't get me 
wrong, the improvements we have made in "BPCS reimplementation project" 
has improved many things, I just need more understanding of the G/L 
effects.  I appreciate BPCSs AS400 environment and try to write as many of 
my own query reports, etc. but even my IT support has troubles giving me 
direction with the AP issues and costing and I believe my IT support is 
very knowledgeable.  So we will just keep trying and do some of the 
exercises you have illustrated below.  Thank you very much.




Al Mac <macwheel99@xxxxxxxxxxx> 
Sent by: bpcs-l-bounces+trisha.brock=showaaluminum.com@xxxxxxxxxxxx
02/13/2007 02:00 AM
Please respond to
SSA's BPCS ERP System <bpcs-l@xxxxxxxxxxxx>


To
"SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
cc

Subject
Re: [BPCS-L] UML and Amount calculation version 6.04






   I believe there were several related threads.
   You might start with http://archive.midrange.com/bpcs-l.
   PO ACTUAL COST middle 2007-Jan
   ACP INVOICE VOIDING early 2007-Jan
   3 WAY MISMATCH in 2006-Dec & 2006-Oct
   FACILITY CODE IN PO 2006-Dec
   CONTENTS OF HPW FILE 2006-Sep

   You might also check INV500 vs. PUR550 and transaction effects.
   In theory, purchase orders are received via PUR550 against a valid PO.
   However, if someone can enter a receipt using INV500, that might be a 
way
   to bypass some checks & balances.
   We do not receive to any inspection area, and currently do not receive 
any
   inter-facility.  My memory is that these use somewhat different rules.

   Hopefully I'm not repeating myself too much.
   My background is in IT & I been working in BPCS almost 20 years, with 
next
   to no involvement in the accounting side until about 6 months ago, when
   there has been an explosion of requests of me to help figure out why 
some
   accounting stuff is allegedly "not in balance".  Seems to me it has not
   been in balance for years, but changing management interests means it 
is
   now very important to figure out and fix.

   You ask "How can this be changed?" which i think is an excellent 
question.
   We are at the point of "What the heck is going on?"; "How come this 
gets
   out of balance so often?"; "What can we be doing differently to catch 
the
   problems with less human effort?"

   I have added a ton of work files and reports to track the involvement 
of
   commodity pricing fluctuations, which for us is like gasoline pricing 
on
   steroids.

   I have made some modifications of reports to help figure some of this
   stuff out, such as a GLD230 variant that is Excel-friendly and expands 
on
   reference fields to reverse engineer customer / vendor source of input 
to
   GL.

   I had suggested we switch our receiving (U) transaction to its own 
Journal
   Source (GLD119) detailed instead of summarized like general "IN" 
inventory
   (INV355) but there's lots of resistance here to changing BPCS rules 
when
   not everyone effected has a good understanding of their implications.

   I am seeing costs in various fields of "U" and "C" transactions in ITH
   inventory history & I would love it if I could reconcile those with 
what
   is going into GL.

   The cross-hairs of my radar screen is reconciling costs going into 
General
   Ledger thanks to Purchases & Payables, with Customer exceptions being a
   close second.  Basically there are various standard BPCS reports on
   Payables, Purchases, Receivables, etc. which have certain totals, and
   there's an expectation that the totals of these reports should agree 
with
   the totals in General Ledger for the corresponding topics.

   We are 405 CD & possibly some of our tailoring options different than
   yours.
   I do not know what UML is.
   We have very little involvement in Unit of Measure conversions, but 
have
   had to fix some BPCS software that has U/M bugs.

   We have tech support that is first rate & my philosophy is that if
   something is happening that seems to be weird, and it is not obvious 
how
   come from a cursory inspection of what passes for the documentation,
   reviewing the data, programs etc. then probably tech support can get an
   answer in an hour, and if it is wrong we can stop doing it wrong.  My 
boss
   philosophy is that we must first exhaust every possible way to figure 
out
   something, before calling tech support, so if we doing something wrong, 
we
   will continue doing it wrong, perhaps for months, before figuring it 
out.

   When I first learned BPCS, I was impressed with all the tailoring 
rules,
   but I asked how reliable this stuff is & the instructor said about 85% 
...
   meaning the rules in BPCS say do this, do that ... change a rule and
   expect BPCS to immediately start following the new rule, well about 15% 
of
   the time it does not.

   I encounter another exception about once every other month or so.
   BPCS documentation, education, tailoring etc. says one thing, but
   something else is happening..
   Our system parameters (SYS800) say that all activity is to go into 
General
   Ledger at Standard Cost.  Well this whole area is exception to that 
rule,
   big time.  I wonder what other areas are also exceptions.

   We had some disputes between different people looking at data, trying 
to
   figure out what was happening.

   e.g. The gal who keys in ACP500 explained how, showing various screens,
   that it is impossible to key in payables for something we have not
   received.  Other people were convinced that must be happening.  So I
   created a work file ... summary total quantity & $ total by
   vendor-PO#-item
   one work file for all the "U" receiving transactions last 6 months or 
so
   another work file for all the "C" same time period except start a week
   later to allow for invoices in transit in snail mail
   Then I compared the two work files, listing all cases where we had more
   "C" received or paid for than "U" received,
   then when I had the PO# item #, I went after the detail.
   When I started this exercise, I was in the camp of "This cannot 
possibly
   be happening, but now I have to do some frigging test to prove a
   negative."
   Wow, we had all over the place, what the ACP500 lady had asserted was
   impossible, and what had also seemed highly unlikely to me, when I 
checked
   out what she was showing us..
   I located almost $ 100,000.00 in duplicate billing by vendors, vendor
   errors with unit-of-measure pricing, billing us for stuff we never
   received, stuff we received but BPCS was never told, errors in how the
   data had got keyed into BPCS..

   So we have a series of one person or another (including me) asserting 
this
   is how BPCS is supposed to work, then we have to figure out how to 
prove
   it.

   Proving it from the BPCS data is one challenge.
   Proving it to other people using the paperwork from which BPCS got its
   data, is another challenge.

   One series of tests were done over a weekend, when no one entering 
normal
   transactions ... leave certain items POs at standard, change some to
   expected, change standard cost outside of PO, carefully screen print
   before doing U transaction, what the actual standard expected cost is, 
all
   3 being different costs, just do the one transaction, get it into GL, 
see
   what cost arrives in GL.  Now do same thing with A/P ... have item with
   different cost actual standard expected, post A/P, post to G/L, see 
what
   cost ends up in G/L. Package with print-outs for all & sundry people to
   see exactly what's happening.  Well several of us were mistaken on 
exactly
   what was happening.  Now back all of that out, so correct data again in
   POs, Inventory, A/P, G/L.

   We have a test environment, but some people like to see audit trails of
   how tests came up with what results.

   What we found from this exercise was
     * The "U" receipt transaction goes into BPCS using the "expected 
cost"
       from the PO.  There are two GL accounts ... value of inventory, and
       something we call unvouchered, meaning material we have received 
but
       not yet vendor invoice.
     * The "expected cost" in the PO starts its life as a copy of the
       standard cost, but then the Purchasing Manager sends PO by fax to 
the
       vendor, and then when vendor replies with date, price of delivery, 
he
       updates PO to show expected cost & expected date.
     * When we run PUR210, it shows inventory received but not yet 
invoiced,
       in which the cost there is expected cost, but there is a bug in the
       math, so we have our own version of this report.
     * The Payables can update several accounts ... Grand total of what we
       owe the Vendor into A/P total, there may be freight-in costs, 
actual
       cost of inventory comes out of the unvouchered, we also have a
       material variance account for the difference between standard cost 
and
       actual cost affecting our total inventory valuation.  So at this
       point, difference between standard-expected cost, and actual vendor
       cost is not clearing the GL unvouchered account.
     * BPCS copies various pieces of information when some record is 
created
       ... changing the original story has zero impact on the copies ... 
so
       if we change our pricing, that has no effect on existing customer
       orders, if we change our terms, that has no effect on existing
       invoices, and at year end when we changed our standard costs for a
       large number of raw material items, that had no effect on the many 
POs
       out there for those items.
    you wrote:

     Do you happen to know where this recent thread was called?  I'd like 
to
     go
     back and read this - how "can it be changed" - we recently had 
training
     in
     this area and I was under the impression that the PO receipt is 
always
     journalized at standard and when the invoice is entered the system
     "automatically" reverses the standard amount in UML and the 
difference
     is
     journalized to PPV.  I'm having issues with our UML sub-ledger and
     understanding how to tell which is used - I see exceptions of raw
     material
     getting "received" at PO (or expected cost) and other times it is
     "received" at standard cost.

     If you happen to recall the subject line - I try to keep all these
     emails
     for reference.  Thank you.

     Al Mac
     Re: [BPCS-L] UML and Amount calculation version 6.04

     There was another recent thread on this.
     In 405CD the amount in POs starts as standard, then can be changed to
     "expected cost", something that exists only in PUR module.
     Then when the payables posted, it goes in as actual cost.
     So the material variance ends up added to received but not yet 
payabled,
     in
     G/L.

     Al Mac

     >Can someone tell me how the amount on PO receipts gets calculated 
for
     the
     >G/L?  I am trying to find the field that tells the system which 
price
     to
     >use - Standard versus PO?  The Macros set up in our system are for
     account
     >segment only, not determination of amount to be journalized.
     >
     >
     >Trisha Brock, CPA
     >Accounting/IT Manager
     >Showa Aluminum Corporation of America
     >10500 O'Day-Harrison Rd., Mt. Sterling, Ohio  43143
     >Phone: 1.740.869.5021
     >FAX:  1.740.869.3309
     >Email:  Trisha.Brock@xxxxxxxxxxxxxxxxx
     CONFIDENTIALITY NOTICE: This e-mail message was sent to a discussion
     group

     on the Internet whose archives are accessible to anyone who knows how 
to
     use a search engine.   There is some protection there.  Check them 
out.

   -
   Al Macintyre
   http://en.wikipedia.org/wiki/User:AlMac
   http://www.ryze.com/go/Al9Mac
   BPCS/400 Computer Janitor ... see
   http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.