|
DaveWe are at 4.0.05 CD which also may be different, plus the financials are not one of my strong suits, but I too have been occasionally called upon to do trouble shooting there, and have found some problem areas which may impact you.
Summary:* Stuff may have been correct when you closed out each month, but the notion of closing a month is a fantasy held by people who work in management and accounting. In BPCS this is unenforceable. * Theory of accounting dictates that debits must equal credits. That is an ivory tower concept that does not really work in the real world of human error and fragile hardware.
THEORY: You can tell everyone in the company what the fiscal calendar is, and trust them not to post transactions into completed months. FACT: Very few people outside accounting have any comprehension of the importance of fiscal dates. Let's suppose you close out a fiscal month, but have a few final accounting adjustments to make. If like us, you only print the error lists of postings to GL, you don't get to see the thousands of other transactions made by other people into the prior fiscal months. For example ... we have end of month on a weekend. On Friday, the gal who normally keys in labor tickets via JIT600 is off sick, so that work is postponed until Monday. Well guess what, they back date the input to Friday. Even though Friday was in previous fiscal month, BPCS posts the transactions as if they had gone in the prior fiscal month. Opening Balance for the new month is recomputed. All sorts of totals associated with end fiscal month totals are now different from what they were in the end month reports. We have a rule "Thou shalt not back date transactions ... input using the date the transaction is keyed in" Reason for the rule is to avoid messing up end fiscal. With turnover, people forget this rule, so lots of corrections can get made dated when the error being corrected was done. Other people forget about this & run reports for some week range and find errors that they think need to be corrected, but they have already been corrected, so we get extra corrections, which hopefully get spotted and reversed.
THEORY: You can update the GL any old time from the transactions which have been posted so far. FACT: If you try that while people are running programs that generate records that need to go into the GL, you are going to get duplicate batches, and out of balance input to GL. Suppose someone is keying in A/P ... this is generating input that will end up in a GL Journal Batch that corresponds to the batch someone is keying via ACP500. But that batch is unfinished, so our post to GL creates a journal batch that is incomplete. Then the next time we try to post to GL, it will say that A/P batch already exists..
THEORY: BPCS will not let you post stuff into a fiscal period which has been closed. THAT'S A MYTH. What happens is a great variety of different types of transactions get posted using dates that accounting has closed, so you end up with tons of unposted stuff in the various GL files, for past fiscal periods. Example: We enter Customer Returns as soon as they are issued, but it may be a later month or so before QC has got tracked down the problems, which may be with a supplier, or we have manufactured repairs, or whatever needs to be done. Accounting closure of the RMA is the last step. Let's suppose we got an RMA in 2005 December, and do the accounting closure in 2006 March. It gets dated 2005 December, whether or not we have closed 2005 fiscal year. This means that whole categories of transactions do not make it into the GL when accounting is only posting the current period, except for some past period adjustments, and we are failing to enforce rules about not back dating transactions into prior fiscal periods. When I analysed what we had for unposted GL transactions for dead fiscal periods, most of them are from Inventory transactions and Billing.
We did some modifications where you know when people are keying in batches, the first screen for next item has pretty much cleared most fields. Our people did not like what was thought of as excess keystrokes so we altered the subroutine that clear fields of various input programs to leave copy of some stuff from prior input, where date starts off defaulted to today date. Well guess what? If someone accidentally keys a bogus date into one transaction, and not notice it, that bogus date is now in all the rest of the batch, and also headed towards GL, but the date is not a valid GL fiscal period.
THEORY: Total debits have to equal Total credits.FACT: I wish. Reality is that people are posting things, and their PC goes down, or the communications line goes down, or there is a power outage, or whatever. We now have a broken batch. The end user gets their PC going again, goes back into the same program, breathes a sign of relief, Nothing for them to have to fix. Well nothing that they can see, but what we now have is garbage input.
- 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
Paul, At 4.02 we don't have GSB and GSX files. Yesterday I suggested they run trial balances for each month of 2005 in hopes of finding a entry that got made for the wrong month or something. This morning they tell me that there are trial balances for about five months of 2005 where the debits don't equal the credits. That had to have been equal when they closed out the month and they tell me that they were equal in January of 2006. Now I get to find the needle(s) in the haystack. Arghhhhh!!! At this point I'm going to ignore the FRS and concentrate on what's going on with the trial balance. Dave Parnin -- Nishikawa Standard Company Topeka, IN 46571 daparnin@xxxxxxxxxxxxxxPaul.Bogle@xxxxxxxxxx Subject: Re: [BPCS-L] GLD Trial balance doesn't equal FRSReporting? Dave - we run version 6.04 client server so what I saw may be off the mark but many processes stay the same in BPCS. Trial balances are generally based on the GSB file whereas the FRW reports (a later version of FRS) that we could use are based on the GSX file. The GSX file is just a copy of GSB that has to be manually updated in v6.04 (using a process called 'Year to date rollup') and it may be that this process has not been carried out. I would have expected though the 'Trial Balance' to be correct and the FRS report to be wrong. Paul Bogle Business Systems Manager +44 7979 745404 daparnin@niscosea ls.com Subject [BPCS-L] GLD Trial balance doesn't 21/03/2006 18:18 equal FRS Reporting? BPCS Version 4.02. Our accounting department is trying to close out 2005. They tell me at one point everything balanced but they have since made some adjusting entries for the month of December. Now they when they run the Trial Balance (GLD240) it doesn't agree with the FRS Report Processing (GLD700). They say that FRS is correct but the trial balance isn't. The trial balance for December looks OK. Does anybody have any ideas? My background is more on the manufacturing side instead of the financials. I pretty much have to dig through the programs to see what they are doing. Any advice would be appreciated. Dave Parnin -- Nishikawa Standard Company Topeka, IN 46571 daparnin@xxxxxxxxxxxxxx
<snip> - 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.
midrange.com
