Re: 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