Hidden Costs

>From Al Macintyre e-back again after major home PC upgrade & struggling to 
learn Win 9x stuff that is old hat to everyone else.

We have a bunch of Query/400 reports that were written by different people 
with different degrees of understanding for our BPCS 405 CD mixed mode V4R3 
then the reports get run by other people who sometimes question their 
veracity & there are also some standard vanilla BPCS reports that are off of 
actual cost, when many employees are more interested in standard cost.

The CFO wanted me to convert someone's Query report based on a file 
containing total ACTUAL costs for a month's activity to get STANDARD cost, so 
first I linked to CMF cost master & totaled up based on cost set cost bucket 
of relevance but it became obvious that I could not make it look nice in a 
single threaded query, so I went after IIM.ISCST instead.  He randomly 
compared my figures for costs of items on the report, which showed some zero 
while INV300 had what the CFO thought was a good figure.

Ok, how come ISCST is zero for some items & where does INV300 get cost?  I 
found CST590 & decided that this was a bit too convoluted to put into a query 
- I know also that if I find a solution, a bunch of co-workers will try to 
copy it into other queries & real complexity invites human error.  The CFO 
now has what he wanted via an SQLRPG program that I wrote.

There is also a ZERO record in CMF ... is this the total of all the other 
buckets & is it consistently maintained at time of individual bucket update, 
or is it only refreshed at time of CST600?

We are a make-to-order job shop in which periodically there are customer 
model lines identified that we'll never make anymore.  We bring on-hand 
unique components to zero, purge any orders, remove BOM & routings, take cost 
out, then item can go away, except sometimes there are snags.

Sporadically when trying to make item go away with INV100, there's an error 
message about a cost in the way, which they were sure they removed, and sure 
enough when they go in with CST100 there is nothing there.  Now it occurs to 
me that there might be a security problem - if the person doing CST100 is not 
allowed to see everything by BPCS security, they will not see what needs to 
be removed so that the item can go away.

Where we are at is a need for a report to list what needs to be cleaned up on 
items we want to go away.  I suggested a Query of CMF for all hits on that 
item ... if none then the problem may be INV100 wherever there are flas & 
values from the last CST600, which we run twice a week.

Where does INV100 get the story that a cost exists?
Are we missing a step?

CST100 has a non-functional Cmd 11 so cost removal is quite tedious.
Is there a BMR on Cmd 11?

> Subj:  Year End Advice & tracking WIP
>  Date:    99-11-04 16:16:58 EST
>  From:    ScotConslt@aol.com
>  
>  Hello all,
>  
>  I am working with a client who just went live on BPCS V6.0.04 in June.  
>  Everything is running smoothly but one task that has them baffled is year 
> end processing.  
>  I am trying to gather information to hand off to them.  Any 
>  information that anyone has as far as a job schedule, what needs to run, 
> what should be run etc would be very helpful.

Our consultants gave us a document listing all the end-month jobs & what 
sequence they ought to be run in ... ie. close some applications before 
others.  There have been earlier threads in BPCS_L where people suggested 
what are appropriate year-end job sequence, month-end sequence, weekly reorgs 
& so forth,

>  Also, they are having problems reconciling WIP at the end of the month.  

We are having troubles knowing cost of WIP in middle of month - any old time.

When we do our physical, we use handwritten tags for WIP in which someone 
figures out what materials have gone into this WIP through prior shop order 
reporting ... we close out all our shop orders prior to the EOM in which the 
physical gets dumped in right after INV900, then subsequent MRP refigures 
shop orders needed based on revised inventory.  We manually create shop 
orders for the WIP, and we do "Z" transactions to back out the inventory that 
went into the WIP before the physical, knowing that completion of those 
orders will re-report the consumption.  Those handwritten WIP TAGs are never 
keyed into BPCS.

Assuming you trust & understand BPCS data & consider any sub-set of history 
to be reasonably complete, check out the stuff in FLT labor history file.  We 
use it to get reports on percentages actual vs. standard rates reported, then 
people want the percentage scrap reports to have the cost of scrap added, and 
then the fun begins.

>  Before going live, they did not do a physical inventory so they understand 
>  that "some" (probably all) of their inventory balances are screwed.  

How did their inventory balances get into BPCS?  Some kind of conversion?  
Was the conversion done as of EOM?

> The last time they did a physical was about 5 years ago!  

This implies that their ACTUAL inventory - irrespective of what ended up in 
BPCS must have been very accurate ... we have inventory in the high 90 
percentiles but our auditors insist on annual physicals any place it is below 
100% in either a prior year audit or in their spot checks in which they raid 
us & we do not know in advance which 25 items they will check & the last few 
years when they did that the resulting warehouses got to skip physical for a 
year.

When we converted to BPCS/400 we did a physical a month later in one facility 
then a month later in another & so forth.  You do not have to do a physical 
at the same time as cut-over.

>  Any quick ways to track WIP 
>  at the end of the month and tie back to shop orders?

There are various door stop reports but they only show cost of currently open 
shop orders, some of ours date back to 3 months of activity, depending on 
time duration of the work & how backlogged the production paperwork 
department manages to get, and we also have shop orders that appear & 
disappear within a week or so, which do not show up in the vanilla reports 
itemizing the status of open shop orders.
>  
>  TIA
>  
>  Jeff

>  </XMP>

Al Macintyre
+---
| 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
+---