Re: Procedure for closing purchase orders

[Al Mac <macwheel99@xxxxxxxxxxx>]

Please add to this thread what version of BPCS you on, because how things 
ought to be done, and what you can do are very dependent on that.

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