|
Like Rick, our main problems was invoices appearing on statements. We have a large volume of invoices going through each day, so we do all invoice printing and posting overnight in day-end jobs - no-one has access to these options from the menu. This way it is easy to hold the invoice job queue at month-end and release it when the new period has been opened. Helen Duncan Direct line: 0141 307 4887 e-mail: duncanh2@bp.com -----Original Message----- From: Rick Allen [mailto:rick.allen@sandvik.com] Sent: 19 December 2001 21:00 To: jbausers-l@midrange.com Subject: Re: JBA ML - Month end procedures I agree with Jeff. Since implementing S21 back in '97 we have used basically the same process - run inventory manually at EOM and disable the invoicing tasks until AFTER AR is closed. However the reasoning we used was so that these invoices did not appear on statements and thus confuse any customers. Either way, same process. However, we used to simply remove the interactive program from the OE invoicing tasks (and in our case JC also), this got rather boring going through all the tasks and deleting the IA pgm and then having to retype it back in again later. Next advancement (it takes us IT guys a while to catch on to things to save ourselves work although we seem to achieve it for others!) was to simply set up a couple of macros in client access and that has worked well for longer than I can remember. Now, however, we are just about to try and shed the majority of EOM tasks back to users. No way are users getting AM access to play with the tasks so we have had to take another quantum leap (small frog hop!) and we now use a CLP which simply does a rename of the 'interactive' objects from the invoicing tasks for OE and JC by adding a suffix of 'EOM'. We then have another CLP which RNM's them back again after the AR is closed. Another trick is that we have a bespoke menu onto which ALL the EOM tasks are put (including options for the RNM CLP's) so we just 'follow the numbers' each month, being careful NOT to run the specific end year tasks associated with IN and SA. BR Rick Allen IT Manager VA EIMCO Australia To: jbausers-l@midrange.com cc: Jeff_Klipa/Harvard@harvardind.com Subject: Re: JBA ML - Month end procedures Sent by: jbausers-l-admin@midrange.com 20/12/01 03:23 Please respond to jbausers-l Since all A/R transactions are date stamped based on the current period in the Inventory Calendar, the Month-End Closing must begin by closing the Inventory Calendar and incrementing that calendar to the Next Period... (Inventory is the only application that requires you to do the Year-End Close manually (3/INC)... All the others applications are "smart" enough to calculate when the year should roll forward during the normal Month-End close...) Since the IT Department is responsible for running our Inventory Month-End Close, we wrote some routines to automate our Inventory Month-End Close... I grew very tired very quickly of running the close by hand for 14 plants every month... And now I see in a recent release GEAC have made 2/INC eligible to run in Machine Manager... Thank goodness... Please note here that once the Inventory calendar has been incremented to the next period, all inventory transactions obviously can continue uninterrupted regardless of whether or not any of the financial applications have closed/opened yet or not... Even AFI extracts can be performed without fear of posting to the wrong G/L period... It is based on the Inventory Calendar period at the time the transaction is originally posted... For some reason A/R postings don't go to the future period they go to the currently open A/R period... At least that's what I was told... All I know for sure is they don't want their A/R numbers changing while they are trying to close A/R... Since A/R uses the Inventory Calendar one of the next logical steps is to Close A/R and Open A/R in the next period... OUR Inventory Close usually runs late evening on the last Sunday of every month (we operate on a 4-4-5 fiscal calendar)... But the A/R, A/P, C/S and G/L closings take the better part of the rest of the week to finalize... During that time period the only transactions that WE have to prevent users from running on our system are INVOICE POSTINGS to A/R... (Until the A/R calendar is rolled forward...). (There are actually 4 specific tasks we "DISABLE" - see below.) That's OUR system, YOUR system may have different restrictions... We cannot trust the users to remember NOT to Print/Post A/R Invoices so we had to come up with a bullet proof way to make sure nobody Oopsed an Invoice into A/R between the time we incremented the Inventory calendar and before accounting had a chance to close/open the A/R calendar... Here's what I have been doing... I set up an automated job to go into the file IPGAMF4/APG35PHY and change the Version number on 4 custom tasks I created from 93 to 03... This will effectively disable the user options which let them perform the restricted tasks in JBA... These tasks will be changed back to 93 from 03 after the Finance department says that the next A/R period is open and ready for use... (I gave them a menu option to "Re-Enable Invoicing)... The program to call on these task definitions is called DISABLED and simply displays a screen informing the users that the task they are trying to run is temporarily disabled and lists a phone # to call if they want to discuss it with someone... (We have a help desk # we publish)... Here are the tasks involved... They are the same task # as the vanilla task's so they will be run in place of vanilla when their version # = '03' and they will not run when their version number reverts back to '93'... Thus re-enabling the vanilla tasks... APSR35 APPL35 RLSL35 FUNC35 CUSC35 MNDS35 O OE 93 3030 XXX Invoice Print (DISABLED) O OE 93 3040 XXX Invoice Reprint (DISABLED) O SL 93 1010 XXX Post invoices / credit notes O SL 93 1040 XXX Post sales / nominal journals (Environment code XXX would be your default environment code...) So it's all automagic for us... I simply monitor the closes from home on Sunday evenings to make sure no errors occur and the rest is automated (and bullet proof)... If you have other tasks you need disabled you can use the same method... The logic may seem strange to the uninitiated but believe me it works like a charm... I'd be happy to answer any questions you might have about this method... Hth, Good luck... Jeff Klipa Harvard Industries, Inc. jaklipa@harvardind.com ----- Original Message ----- From: <Jim_Hawkins@tsss.com> To: <jbausers-l@midrange.com> Sent: Wednesday, December 19, 2001 4:58 AM Subject: JBA ML - Month end procedures > Our accountants have been relying on people not entering new transactions > while they run reports and perform month end closes. Since this is > basically an honor system, frequently someone forgets and enters something. > There must be a better way. > > What procedures are others doing to keep transactions from being posted > during the month end close process? Suggestions. > > > Thanks > > Jim Hawkins > IBM Certified Specialist AS/400 RPG IV Programmer > Programmer/Analyst > Eimo Americas _______________________________________________ This is the GEAC/JBA System 21 Users (JBAUSERS-L) mailing list To post a message email: JBAUSERS-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/jbausers-l or email: JBAUSERS-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/jbausers-l. _______________________________________________ This is the GEAC/JBA System 21 Users (JBAUSERS-L) mailing list To post a message email: JBAUSERS-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/jbausers-l or email: JBAUSERS-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/jbausers-l.
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
