|
Been there, done that. First, in BPCS v4.05CD, the JE reference + the period + year + company is unique. So, it is OK to have IN1207 once per month per company. More than that is not good. Second, regarding your fixer program. I am assuming you are talking about "fixing" the records in GJW. I would suggest making a new JE for each combination of period + year + company, so it is more like std BPCS. Also, there is no link from G/L directly back to the inventory subsystem based on JE #, (the ITH does not carry a JE#), so there is no specific reason that you need to number these INAxxx. I'm not sure of all the potential ramifications, but I suggest you would be much better off using a 2 alpha field + 4 numeric field for your fix. Use std BPCS GLD119 to create a new journal code for the fixes. Then, replace "IN" on the journals in error. Finally, use GLD119 to update the "next journal number" on your new JE source code, so there is no chance someone would use this code & accidentally get the same # you created. Third, regarding GLD540 being stopped in process. Very bad. NEVER cancel a posting program in mid stream. Forget the keyboard problems. There isn't any harm that an "accidental" GLD540 can cause. It posts entries that were already created. You may want to run some queries to verify that the GJD details total each GJH header. You may have to do some "special" fixing if you find this scenario. Remember to link on JE ref (source + 4 digits) + company + period + year. Finally, to make sure this doesn't happen again, there are several things you/your users can do: Use different G/L source codes for different types of inventory transactions (ie: Transfers can be "IT", PO receipts "IP", shop order issues "IS", etc.) Many times, it is easiest to make the JE source code be the same as the inventory transaction type. This makes it very easy to understand what JE's came from what transactions (ie: PO receipts "U", Transfers "T", Shop Order Receipts "R", etc). This will cut down on the number of JE's for any given source code. The "link" from G/L source to inventory transaction is in INV150 - transaction effect maintenance. If they are not on already, turn on the summary flags for the journal source codes used for inventory posting. This is particularly important on the high volume transaction effect codes. Some recent postings in BPCS_L discourage summarize journals in BPCS v6. Fine for v6, but in v405CD we have this limitation of 9999 JE's per month. In the BPCS v405CD world, I have never been at a client where we wanted to duplicate all the entries in ITH with matching detail entries in GJH/GJD. Use the journal summary flags in GLD119 so only entries from inventory will summarize, not all entries to these accounts. NOTE: regardless of what the summary flags say, the highest level of summarization is ONCE per INV920 run. Therefore, if you run INV920 twice per day, you will get two entries for the same source on the same day (vs what the helptext says). Run some queries on ITH to verify that by making the changes listed above, you won't get more than 9999 entries per month per source code based on the rate of transactions. These steps usually fix the problem, If there is still a problem, consider running INV920 less than once per day. If I you need more details, give me a call. Peggy Heritz Senior BPCS Specialist Crowe, Chizek & Company, LLP http://www.crowechizek.com/scg/ phone: 219.236.8698 fax: 219.236.7615 |--------+-----------------------> | | MacWheel99@ao| | | l.com | | | | | | 02/08/00 | | | 04:44 AM | | | Please | | | respond to | | | BPCS-L | | | | |--------+-----------------------> >----------------------------------------------------------------------------| | | | To: BPCS-L@midrange.com (BPCS Users Discussion Group) | | cc: (bcc: Peggy A. Heritz/SB/CroweChizek/US) | | Subject: GJ novice learns fast | >----------------------------------------------------------------------------|
from Al Macintyre 405 CD V4R3 mixed mode - we ran our first end-month fiscal this weekend that was actually run in the year 00 & our users do not believe in testing, but they do believe in asking me to fix mess-ups. 1999 was also our first full year on 405 ... 1998 was 50-50 405 & S/36 multiple data bases, so we have not had prior experience in how much volume to expect in a fiscal year. Unfortunately I am a total novice in General Ledger Journal but I learn fast. Accounting has several thousand GJW journal source codes (e.g. IN1207) which will not post because GJH already has a header on that code. I ran a query to select all GJW records whose journal identification matched one already in GJH & I found IN1207 out there, from the beginning of the 1999 fiscal year. I also found a lot of tiny GJW batches dated 2000-2-7 with different IN####. By GJW & GJH time the journal reference was 6 positions alpha. Suppose I wrote a quick & dirty RPG SQL program to take IN#### in GJW which have a match in GJH, then change the field to INA### in which the letters A-J substituted for the digits 0-9 to give the field something unique that BPCS would not assign ... is this going to work downstream, or does GLD subsequently put the IN#### back into #### numeric field? I recognize this will not solve whatever error they made to create the mess in the first place, but I think it should clear up the thousands of journals they cannot post right now. It seems to me, from only a few hours of looking at this mess, that some mechanism assigns the next journal #, in a cycle of IN0000 to IN9999 then re-assigns the same # again, so that if they post 5 days a week 52 weeks a year for each of 4 facilities of inventory excluding holidays, they are going to run out of unique journal entries. One of the accountants speculated that someone might have been posting inventory transactions to whatever file at the same time as they were posting inventory to Gen Led, much like the problems Billing has if Shipping is making some final corrections after they "said" they were done for the day ... now we have people posting inventory all day long at all sites & the first they would have posted Mon Feb-7 would have been from the factory workers who were in on Sat Feb-5 ,,, now I did not get done with EOM until the wee hours of Fri nite, so it is possible I dated some EOM step as Feb-5 when I should have made it Feb-4. So one question is if there is any conflict between accounting posting inventory transactions to General Ledger at the same time as ordinary inventory input, and what date do relevant programs use when people leave their display stations on perpetually with no sign off. I also saw on DSPMSG QSYSOPR where one of the accountants had cancelled GLD540 off of the JOBQ twice & the explanation given was ... thanks to some PC installation that is in the works, the keyboard map for 5250 emulation got "messed up" and the only person who knows how to do keyboard re-mapping on our staff is totally swamped with work, so the accountant is making some mistakes due to keys not being in the right places, like enter & field exit got reversed, and OOPS I did not mean to run that, so it was cancelled after it started running & I suspect that is part of the problem ... canceling an update job is not good business practice. It would be nice if this accountant could use a different work station for 400 jobs & it will be interesting to see if the Payroll gets done right this week, since it comes from the same keyboard. Question - Do companies normally post inventory transactions to General Ledger at what rate - daily, weekly, monthly? Is this a task that needs to be done when no one is doing inventory transactions? Question - What task should Accounting perform to make old GJH / GJD records go away, when they are done with them? I do not know if they are in fact done with them. Question - What program assigns new journal codes? Does it go thru 0000-9999 then create same #s again, or is there some kind of error message to user to say you cannot post this because you ran out of numbers? - you gotta purge some GL history before you can post more there. Question - what key is unique in journal coding ... can it use the same 6 characters again later in the year - is that what Ref1 Ref2 is for? ... I expect I may need to add a logical over this for my quick & dirty "fix." Al Macintyre ©¿© http://www.cen-elec.com MIS Manager Programmer & Computer Janitor http://www.whma.org = our nitch industry +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---
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
