|
Are you governed by SOX or any other GAAP?Sometimes the simple solution is to clean the clock of the system's bad data and start fresh, but depending on your kind of company, auditors can highly disapprove
If you gonna kill some records, right after that do a reorg of all the files you mucked with, better yet do as much reorg as you can do that is safe to do in middle of month, because all kinds of running totals places like IIM, that will now need to be fixed
There was other recent threads on reorg, and this also is highly sensitive to your version of BPCS and the applications you have implemented.
For example, if you have outside operations that go thru purchase orders, some might still be open because the shop orders not completed, and if you are using PRF, the shop orders might not be done yet because you missed a PRF step.
If you going to be mucking with totals, better check on the running totals in AVM vendor master file
Another important purchasing file is HVH ... we did a modification to clear the statistics at end year, so we could get performance story on each vendor, then start fresh for new year statisitcs
Check your system parameters ... do you have some place where you decide how long you going to keep old POs? I do believe there are places where someone could have said they are to be kept for infinity.
If you have multi-facility, check how stuff is moved from facility to facility. There is the right way, the wrong way, the army way, and our way Depending on how you doing this* you can end up with millions of dollars of inventory that has not been paid for (it should never have gone through purchasing) * you can end up with costs several multiples of what they should be (transfers should not be used between facilities that have different cost structures) * you can end up with costs that are off a few thousand fold (someone made a keying error in the 3 way match) and hundreds of items not reconciled (3 way match human errors)
there are reports you can, and should run, showing totals of what has not been matched up, since your accounting department has fiduciary responsibility to do something about product you have received but not yet paid for, or product you have contracted for but the pricing is other than the contract.
We are on BPCS 405 CD Our month end process: * Standard cost rollup before running any reports that include standard costs * Generate a mountain of dead tree reports * Backup (allow 2 hours for this) * GLD105 make sure next fiscal period is open * ACP900 * ACR920 * GLD make sure everything has got posted that needs to go in * INV900 (allow 2-5 hours for this)* If this is NOT a month with physical inventory, and if we have AMPLE time, run one or more of certain kinds of purges
* Generate a second mountain of dead tree reports * PUR900** we say 1-yes close month, date end of this period, 0 no do not purge uncosted POs, 0 no do not print purged requisitions, 1 yes print purged POs but in actuality we put this in an OUTQ with a bunch of end month reports, many either not printed at all, or we only print the last few pages to get their totals, 1-batch run 0-no do not purge completed drop shop requests ... I just transcribed this off a screen print I have ... for each step in end fiscal we have a screen print how to fill in prompt screen for that end month step, because if you do fiscal, it can take a bunch of hours, and there is a risk of fatigue driven mistakes ... I also modified some end fiscal CL to feed into the prompt screens to reduce our keying needed
* Generate a third mountain of dead tree reports * Run some more 900 jobs * another backup * off site rotation involved* load up the JOBQ with MRP and a fifth mountain of dead tree reports and some other job streams associated with our modifications
I am computer janitor, spending lots of my time cleaning up BPCS messes, which come about because * Rules are made to be broken, especially business rules that lack ISO standard documentation
* BPCS audit trails are not designed to help validate input* BPCS is amply supplied with something for which there is no politically correct way to say this ... bugs and design flaws, sometimes called features ... of course no longer being on OSG means we have opted out at getting more fixes, except to deal with certain emergencies when we need a fix outside the bounds of what can come from SSA, such as mini-conversions * With personnel turnover, each newbie can only be taught the basics, and then we never seem to get around TUIT on providing more in-depth BPCS education, so any problem is rediscovered millions of times by new people, with each of them coming up with solutions, that people who have long since left the company had previously figured out was not the optimal thing to do * If hardware connection gets disrupted, and user gets back into what they were doing, and it seems to be working, then don't sweat it * Past management decided to save money by not getting AS/Set, but expect me to modify programs generated by AS/Set
* Not even the computer janitor knows everything about our BPCS , you wrote:
We have thousands of POs in our HPH/HPO files as far back as 1998. Currently our month-end procedures do not make use of PUR900 and I am going to rectify this. Implementing that program should delete all the relevant POs with a status of 2 or 3. However that will still leave thousands of POs with status 1, no close date and record id = 'PH'. Looking at the HPO records for these POs there are detail lines that need to be closed. These records are in various states: - Several hundred with no quantity received or costed - A couple of hundred with a qty received but no qty costed - The remainder with both qty received and costed The funny thing about the latter is that I expected to find matching APH/APO records for these but only a handful exist. What is the correct procedure for closing these Pos in BPCS? Could I create a one off program to do this (if so what files need to be considered apart from HPH/HPO) or should it be a manual process? Any help with this matter would be greatly appreciated. -- This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/bpcs-l or email: BPCS-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l. Delivered-To: macwheel99@xxxxxxxxxxx
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
