|
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 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.