RE: What is a # transaction? -- BPCS-L

Al, you wrote: 
.."Figuring out why some part has some cost is manageable. Figuring out
how come all these parts have all these variances is overwhelming..."


I agree! While we only roll frozen standards at year end, we run the
CST600 monthly.  Because we wanted to see "net change" from month to
month, I wrote a couple programs that run at month end right after the
CST600. These files generated detailed cost information for the
then-current BOM and Router of each job. The result is a detailed "CMF"
file that can be compared to the previous month's details to understand
why a standard changed. 

Thank you to everyone who replied to my original question: What is a #
transaction?!

Paul

-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx]
On Behalf Of Alister Wm Macintyre
Sent: Friday, January 23, 2004 3:29 PM
To: SSA's BPCS ERP System
Subject: Re: What is a # transaction?


Thanks for the clarification.
My interest was if I was missing some capability.
I just feel that in the area of BPCS cost management we are doing a
rotten job.

We run CST600 for all items all facilities at least weekly, some times
more 
often.
We also run shop order purge 1-2 times a week.

Now I think it would be useful if people had easy access to seeing which

items had their costs changed by more than a trivial percentage, but we
not 
really interested in seeing info on items that the engineers are in the 
process of adding to our system.

At the moment, we can look at the audit trail ... search for decimal
point 
in position 120 and only hit the lines with a difference.  At one time I

thought I might modify that report to get a variant that only does the 
lines whose difference is over some %, and whose date of origin not
recent, 
but perhaps sending the spool to XL makes more sense.

Before a major change to overhead rates gets CST600 roll-up, we
sometimes 
copy standards to simulated, then have query report on differences.

Also I have some reports showing cost of inventory on hand by type and 
class, with sub-totals, which can be run before and after some roll-up.

Figuring out why some part has some cost is manageable. Figuring out how
come all these parts have all these variances is overwhelming.
:

>Al,
>
>Yes you are right.
>I checked our files and # transactions are only created when records 
>are changed via CST100. We do not refer to these # transactions in our 
>procedure for changing Standards.
>
>Thanks and Regards,
>Vincent
>
>  Al Mac earlier wrote
>
>We are on 405 CD
>We see # when CST100
>We do not see # when CST500 CST600 rollup changes standard cost Is 
>there some system parameter that turns on/off this feature that perhaps

>we missing?
>
>The record looks to me like it is showing the NEW cost.
>To find the OLD cost, find prior # on same item, unless recently had 
>copy into simulated costs. Correct ?
>
>   you wrote:
> >This transaction is created when the value in the Standard Cost or 
> >any other Cost Bucket is changed via CST100/CST500/CST600. It's 
> >merely an indication that the Std was changed on that date. It has no

> >other effect.
> >
> >Regards
> >Vincent
> >
> >
> >"Paul LaFlamme"
> >
> >Hi!
> >
> >Version 4.05cd.
> >
> >I found a # transaction in INV300 - transaction history. The 
> >description of the transaction is Cost Adjustment. Anyone know what 
> >puts that out there?
> >
> >Thanks,
> >
> >Paul


_______________________________________________
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.