VANTAGE 8.03.409C SQL COSTING PROBLEM-Opinion

Hi Bob,

Prior to consulting I was metals fab plant
manager with a Teamster's work force.

Employee pay was skills based and dependent on what they did.

A Shear operator could shift over to Shear Setup
Tech and his rate went up accordingly.

My welders were comped based on the welding
technology they were working with but they could
shift between TIG, MIG, and Gas.....all different
rates. If Cert weld was required, that was another set of rates.

There were about 60 rates in force.

BC

At 05:43 PM 12/2/2010, you wrote:
>
>
>Id have to support that as well.... I have yet to work at a shop that
>pays variable per hour based on the type of activity an employee is
>engaging in throughout the day. That would be a nightmare to manage in
>my mind. If you pay that employee a consistent rate per hour then using
>his labor rate really represents one of the three cost components in
>your COGS (labor, burden and overhead).
>
>Rob Bucek
>
>Production Control Manager
>
>PH: (715) 284-5376 ext 311
>
>Mobile: (715)896-0590
>
>FAX: (715)284-4084
>
><<http://www.dsmfg.com/>http://www.dsmfg.com/>
>
>(Click the logo to view our site)
><<http://www.dsmfg.com/>http://www.dsmfg.com/>
>
>From:
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
>[mailto:vantage@yahoogroups.com] On Behalf
>Of saab_barracuda
>Sent: Thursday, December 02, 2010 4:05 PM
>To: <mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
>Subject: [Vantage] Re: VANTAGE 8.03.409C SQL COSTING PROBLEM-Opinion
>
>Not trying to be augmentative but at most companies this is only one pay
>rate per employee no matter what work they do. The labor cost is
>supposed to represent what it costs to pay the employee(s) to run the
>operation. And actuals are meant to represent actual costs. I do not see
>how charging a generic rate based on the resource would be better. We
>may have to agree to disagree on this one.
>
>And actually, the burden costs is calculated from the resource burden
>percentage and the employee labor rate. So it is consistent in this
>particular case. I absolutely agree Vantage has some serious quirks but
>I don't think this is one of them.
>
>--- In
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
><mailto:vantage%40yahoogroups.com> ,
>Robert Carlson <rcarlson@...> wrote:
> >
> > Hi Chris,
> >
> > I understand your point but I disagree that the
> > labor rate for the production hour should come
> > from the Shop Employee file and not the Resource file.
> >
> > The Burden costs calculation in a Labor
> > transaction draws it's rate from the Resource,
> > not the Shop Employee.....it presents
> > inconsistent logic.......oh wait a minute, it's Vantage.
> >
> > By using the resource as the source of the labor
> > rate you could have "skills" based labor rates
> > instead of "one rate fits all work by an employee".
> >
> > I think for many your comments provide a direction to pursue.
> >
> > Thanks,
> >
> >
> >
> >
> > At 09:26 AM 12/2/2010, you wrote:
> > >
> > >
> > >Bob,
> > >This is correct and it's been that way since
> > >I've been working with Vantage back to Ver 6. It
> > >actually makes sense if you think about it.
> > >Estimates are based on the resource and actuals
> > >are based on the employee labor rate that
> > >actually performs the work. This way you end up
> > >with a variance if for example a higher paid
> > >employee works a lower level job. Any other
> > >scheme would hide the true cost. You don't want
> > >the job costs to look peachy only to have the
> > >CFO to find problems with the balance sheet.
> > >
> > >The resource rates and employee rates should be
> > >tied closely together though. I go through once
> > >a year and update the resource rates based on a
> > >time weighted average of actual employee pay
> > >rates that worked in each resource. Note, the
> > >employee's "labor rate" is a separate field in a
> > >separate table from the "pay rate". But again,
> > >this should be closely monitored and adjusted as well.
> > >
> > >Regards,
> > >Chris Clunn
> > >
> > >--- In
> > ><mailto:vantage%40yahoogroups.com><mailto:van
> tage%40yahoogroups.com>vantage@yahoogroups.com
><mailto:vantage%40yahoogroups.com> ,
> > >Robert Carlson <rcarlson@> wrote:
> > > >
> > > >
> > > > The words I get from support are these:
> > > >
> > > > the production labor rate in the job labor
> > > > transaction is drawn from the labor rate field of
> > > > the shop employee....it is not drawn from the Resource
>Group/Resource.
> > > >
> > > > I have proved that the condition existed before
> > > > the introduction of 8.03.409C so it's not resultant from the SP &
>PA.
> > > >
> > > > I have changed the rates in the Shop Employee
> > > > Master File and have a BAQ to look at Employee
> > > > labor transactions. It appears that Support was
> > > > correct. The Costing Manual also says that Job
> > > > Labor Costing is based on the rate in the Shop Employee Master
>File.
> > > >
> > > > Seems counter-intuitive since it limits you to
> > > > one rate per employee vs using the RG approach
> > > > where you can have different rates based on the
> > > > Resource. The explanation of the RG rates are
> > > > that they are for "estimating" purposes only, not for reporting
>purposes.
> > > >
> > > >
> > > > Bob Carlson
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > At 04:50 PM 12/1/2010, you wrote:
> > > > >
> > > > >
> > > > >In my case, crew size was OK in the resource groups.
> > > > >But... we found that some templates for methods
> > > > >had a zero for the crew size... so new methods
> > > > >based on these had $0 labor in quotes, PDRs etc...
> > > > >Crew size is probably something different than what you have
>going on.
> > > > >
> > > > >Anyway we had (and still have) job costing issues...
> > > > >Some of it has to do with various combination's
> > > > >of stock, NonStock, backflush, autoreceive and costing methods.
> > > > >
> > > > >If you have the time, I'd like to know more details about the
>jobs.
> > > > >
> > > > >We're on 8.03.409C/Progress
> > > > >
> > > > >
> > > >
> > > > Robert (Bob) Carlson
> > > > rcarlson@
> > > > Mobile: 603-883-8093
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> >
> > Robert (Bob) Carlson
> > rcarlson@...
> > Mobile: 603-883-8093
> >
> > [Non-text portions of this message have been removed]
> >
>
>[Non-text portions of this message have been removed]
>
>

Robert (Bob) Carlson
rcarlson@...
Mobile: 603-883-8093

[Non-text portions of this message have been removed]
Has anyone on Vantage 8.03.409C SQL or Progress run into a job costing problem with Job Cost not using the Production Labor Rate from Resource Group/Resource to cost production time? $0.00 is used for the labor rate instead of the labor rate from the Resource involved.

The telltale is that you get a Job Op Transaction Burden cost transaction but no Production Cost for the same transaction.
Do you refer to "estimates" as in Quoting or to
the expected crew size in Resource Maintenance?

Bob Carlson

At 02:13 PM 12/1/2010, you wrote:
>
>
>Just wondering...
>Do you have crew sizes on your operations?
>Zero crew size was a problem on some of our estimates.
>
>--- In
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com,
>"Bob Carlson" <rcarlson@...> wrote:
> >
> > Has anyone on Vantage 8.03.409C SQL or
> Progress run into a job costing problem with
> Job Cost not using the Production Labor Rate
> from Resource Group/Resource to cost production
> time? $0.00 is used for the labor rate instead
> of the labor rate from the Resource involved.
> >
> > The telltale is that you get a Job Op
> Transaction Burden cost transaction but no
> Production Cost for the same transaction.
> >
>
>

Robert (Bob) Carlson
rcarlson@...
Mobile: 603-883-8093

[Non-text portions of this message have been removed]
I have seen strange behavior like this, but was never really able to pin
down or recreate. It seemed to me this happened if an employee was
clocked out of an operation and onto another in the same minute that
this would occur. I believe (not sure) this was tied in with operations
that were flagged as "use estimates" too.



I didn't get anywhere with tech support on this issue so I just left it
alone.



Bruce B.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Carlson
Sent: Wednesday, December 01, 2010 2:02 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: VANTAGE 8.03.409C SQL COSTING PROBLEM





Do you refer to "estimates" as in Quoting or to
the expected crew size in Resource Maintenance?

Bob Carlson

At 02:13 PM 12/1/2010, you wrote:
>
>
>Just wondering...
>Do you have crew sizes on your operations?
>Zero crew size was a problem on some of our estimates.
>
>--- In
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
<mailto:vantage%40yahoogroups.com> ,
>"Bob Carlson" <rcarlson@...> wrote:
> >
> > Has anyone on Vantage 8.03.409C SQL or
> Progress run into a job costing problem with
> Job Cost not using the Production Labor Rate
> from Resource Group/Resource to cost production
> time? $0.00 is used for the labor rate instead
> of the labor rate from the Resource involved.
> >
> > The telltale is that you get a Job Op
> Transaction Burden cost transaction but no
> Production Cost for the same transaction.
> >
>
>

Robert (Bob) Carlson
rcarlson@... <mailto:rcarlson%40robcar.mv.com>
Mobile: 603-883-8093

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
The words I get from support are these:

the production labor rate in the job labor
transaction is drawn from the labor rate field of
the shop employee....it is not drawn from the Resource Group/Resource.

I have proved that the condition existed before
the introduction of 8.03.409C so it's not resultant from the SP & PA.

I have changed the rates in the Shop Employee
Master File and have a BAQ to look at Employee
labor transactions. It appears that Support was
correct. The Costing Manual also says that Job
Labor Costing is based on the rate in the Shop Employee Master File.

Seems counter-intuitive since it limits you to
one rate per employee vs using the RG approach
where you can have different rates based on the
Resource. The explanation of the RG rates are
that they are for "estimating" purposes only, not for reporting purposes.


Bob Carlson





At 04:50 PM 12/1/2010, you wrote:
>
>
>In my case, crew size was OK in the resource groups.
>But... we found that some templates for methods
>had a zero for the crew size... so new methods
>based on these had $0 labor in quotes, PDRs etc...
>Crew size is probably something different than what you have going on.
>
>Anyway we had (and still have) job costing issues...
>Some of it has to do with various combination's
>of stock, NonStock, backflush, autoreceive and costing methods.
>
>If you have the time, I'd like to know more details about the jobs.
>
>We're on 8.03.409C/Progress
>
>

Robert (Bob) Carlson
rcarlson@...
Mobile: 603-883-8093

[Non-text portions of this message have been removed]
Bob,
This is correct and it's been that way since I've been working with Vantage back to Ver 6. It actually makes sense if you think about it. Estimates are based on the resource and actuals are based on the employee labor rate that actually performs the work. This way you end up with a variance if for example a higher paid employee works a lower level job. Any other scheme would hide the true cost. You don't want the job costs to look peachy only to have the CFO to find problems with the balance sheet.

The resource rates and employee rates should be tied closely together though. I go through once a year and update the resource rates based on a time weighted average of actual employee pay rates that worked in each resource. Note, the employee's "labor rate" is a separate field in a separate table from the "pay rate". But again, this should be closely monitored and adjusted as well.

Regards,
Chris Clunn

--- In vantage@yahoogroups.com, Robert Carlson <rcarlson@...> wrote:
>
>
> The words I get from support are these:
>
> the production labor rate in the job labor
> transaction is drawn from the labor rate field of
> the shop employee....it is not drawn from the Resource Group/Resource.
>
> I have proved that the condition existed before
> the introduction of 8.03.409C so it's not resultant from the SP & PA.
>
> I have changed the rates in the Shop Employee
> Master File and have a BAQ to look at Employee
> labor transactions. It appears that Support was
> correct. The Costing Manual also says that Job
> Labor Costing is based on the rate in the Shop Employee Master File.
>
> Seems counter-intuitive since it limits you to
> one rate per employee vs using the RG approach
> where you can have different rates based on the
> Resource. The explanation of the RG rates are
> that they are for "estimating" purposes only, not for reporting purposes.
>
>
> Bob Carlson
>
>
>
>
>
> At 04:50 PM 12/1/2010, you wrote:
> >
> >
> >In my case, crew size was OK in the resource groups.
> >But... we found that some templates for methods
> >had a zero for the crew size... so new methods
> >based on these had $0 labor in quotes, PDRs etc...
> >Crew size is probably something different than what you have going on.
> >
> >Anyway we had (and still have) job costing issues...
> >Some of it has to do with various combination's
> >of stock, NonStock, backflush, autoreceive and costing methods.
> >
> >If you have the time, I'd like to know more details about the jobs.
> >
> >We're on 8.03.409C/Progress
> >
> >
>
> Robert (Bob) Carlson
> rcarlson@...
> Mobile: 603-883-8093
>
> [Non-text portions of this message have been removed]
>
We use an average wage for the shop employee labor rate based on the
shop employees who work in a particular resource group. To track real
rates we used an user defined field for that figure.



What prompted this course of action for us, is our use of temporary
employees combined with a percentage based burden rate. Temporary
employees are typically paid a higher hourly rate (say $25 / hr) than
our hourly employees ($20 / hr). With a burden rate of 200% a payroll
employee working on an operation is burdened $40 while a temporary
employee is burdened $50.



This is the extreme example. Ideally, we wanted to wash out all
"untrue" variances caused by variations in burden application.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of saab_barracuda
Sent: Thursday, December 02, 2010 8:26 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: VANTAGE 8.03.409C SQL COSTING PROBLEM





Bob,
This is correct and it's been that way since I've been working with
Vantage back to Ver 6. It actually makes sense if you think about it.
Estimates are based on the resource and actuals are based on the
employee labor rate that actually performs the work. This way you end up
with a variance if for example a higher paid employee works a lower
level job. Any other scheme would hide the true cost. You don't want the
job costs to look peachy only to have the CFO to find problems with the
balance sheet.

The resource rates and employee rates should be tied closely together
though. I go through once a year and update the resource rates based on
a time weighted average of actual employee pay rates that worked in each
resource. Note, the employee's "labor rate" is a separate field in a
separate table from the "pay rate". But again, this should be closely
monitored and adjusted as well.

Regards,
Chris Clunn

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
Robert Carlson <rcarlson@...> wrote:
>
>
> The words I get from support are these:
>
> the production labor rate in the job labor
> transaction is drawn from the labor rate field of
> the shop employee....it is not drawn from the Resource Group/Resource.
>
> I have proved that the condition existed before
> the introduction of 8.03.409C so it's not resultant from the SP & PA.
>
> I have changed the rates in the Shop Employee
> Master File and have a BAQ to look at Employee
> labor transactions. It appears that Support was
> correct. The Costing Manual also says that Job
> Labor Costing is based on the rate in the Shop Employee Master File.
>
> Seems counter-intuitive since it limits you to
> one rate per employee vs using the RG approach
> where you can have different rates based on the
> Resource. The explanation of the RG rates are
> that they are for "estimating" purposes only, not for reporting
purposes.
>
>
> Bob Carlson
>
>
>
>
>
> At 04:50 PM 12/1/2010, you wrote:
> >
> >
> >In my case, crew size was OK in the resource groups.
> >But... we found that some templates for methods
> >had a zero for the crew size... so new methods
> >based on these had $0 labor in quotes, PDRs etc...
> >Crew size is probably something different than what you have going
on.
> >
> >Anyway we had (and still have) job costing issues...
> >Some of it has to do with various combination's
> >of stock, NonStock, backflush, autoreceive and costing methods.
> >
> >If you have the time, I'd like to know more details about the jobs.
> >
> >We're on 8.03.409C/Progress
> >
> >
>
> Robert (Bob) Carlson
> rcarlson@...
> Mobile: 603-883-8093
>
> [Non-text portions of this message have been removed]
>





[Non-text portions of this message have been removed]
I have always suggested that the labor rate should be approximately 150%
of the pay rate. This accounts for employee burden such as employer
payroll taxes, workers comp, overtime premium, etc. Employee overhead
should be reviewed on a regular basis Just as Chris said and applied
accordingly.



Many companies use the pay rate as the labor rate and figure employee
burden as part of the burden. I have always argued that because the
burden is based on machine hours and not labor hours, that the correct
way to do it is through labor rate and then the employee burden is
calculated into the WIP through labor.



There is more than one way to skin a cat, however.



Charlie Smith, Sr. Business Consultant

2W Technologies LLC

www.2WTech.com <http://www.2wtech.com/>



2W Tech on Facebook
<http://www.facebook.com/#!/pages/Chicago-IL/2W-Technologies-LLC/1391945
69432409>



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of saab_barracuda
Sent: Thursday, December 02, 2010 9:26 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: VANTAGE 8.03.409C SQL COSTING PROBLEM





Bob,
This is correct and it's been that way since I've been working with
Vantage back to Ver 6. It actually makes sense if you think about it.
Estimates are based on the resource and actuals are based on the
employee labor rate that actually performs the work. This way you end up
with a variance if for example a higher paid employee works a lower
level job. Any other scheme would hide the true cost. You don't want the
job costs to look peachy only to have the CFO to find problems with the
balance sheet.

The resource rates and employee rates should be tied closely together
though. I go through once a year and update the resource rates based on
a time weighted average of actual employee pay rates that worked in each
resource. Note, the employee's "labor rate" is a separate field in a
separate table from the "pay rate". But again, this should be closely
monitored and adjusted as well.

Regards,
Chris Clunn

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
Robert Carlson <rcarlson@...> wrote:
>
>
> The words I get from support are these:
>
> the production labor rate in the job labor
> transaction is drawn from the labor rate field of
> the shop employee....it is not drawn from the Resource Group/Resource.
>
> I have proved that the condition existed before
> the introduction of 8.03.409C so it's not resultant from the SP & PA.
>
> I have changed the rates in the Shop Employee
> Master File and have a BAQ to look at Employee
> labor transactions. It appears that Support was
> correct. The Costing Manual also says that Job
> Labor Costing is based on the rate in the Shop Employee Master File.
>
> Seems counter-intuitive since it limits you to
> one rate per employee vs using the RG approach
> where you can have different rates based on the
> Resource. The explanation of the RG rates are
> that they are for "estimating" purposes only, not for reporting
purposes.
>
>
> Bob Carlson
>
>
>
>
>
> At 04:50 PM 12/1/2010, you wrote:
> >
> >
> >In my case, crew size was OK in the resource groups.
> >But... we found that some templates for methods
> >had a zero for the crew size... so new methods
> >based on these had $0 labor in quotes, PDRs etc...
> >Crew size is probably something different than what you have going
on.
> >
> >Anyway we had (and still have) job costing issues...
> >Some of it has to do with various combination's
> >of stock, NonStock, backflush, autoreceive and costing methods.
> >
> >If you have the time, I'd like to know more details about the jobs.
> >
> >We're on 8.03.409C/Progress
> >
> >
>
> Robert (Bob) Carlson
> rcarlson@...
> Mobile: 603-883-8093
>
> [Non-text portions of this message have been removed]
>





[Non-text portions of this message have been removed]
Hi Chris,

I understand your point but I disagree that the
labor rate for the production hour should come
from the Shop Employee file and not the Resource file.

The Burden costs calculation in a Labor
transaction draws it's rate from the Resource,
not the Shop Employee.....it presents
inconsistent logic.......oh wait a minute, it's Vantage.

By using the resource as the source of the labor
rate you could have "skills" based labor rates
instead of "one rate fits all work by an employee".

I think for many your comments provide a direction to pursue.

Thanks,




At 09:26 AM 12/2/2010, you wrote:
>
>
>Bob,
>This is correct and it's been that way since
>I've been working with Vantage back to Ver 6. It
>actually makes sense if you think about it.
>Estimates are based on the resource and actuals
>are based on the employee labor rate that
>actually performs the work. This way you end up
>with a variance if for example a higher paid
>employee works a lower level job. Any other
>scheme would hide the true cost. You don't want
>the job costs to look peachy only to have the
>CFO to find problems with the balance sheet.
>
>The resource rates and employee rates should be
>tied closely together though. I go through once
>a year and update the resource rates based on a
>time weighted average of actual employee pay
>rates that worked in each resource. Note, the
>employee's "labor rate" is a separate field in a
>separate table from the "pay rate". But again,
>this should be closely monitored and adjusted as well.
>
>Regards,
>Chris Clunn
>
>--- In
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com,
>Robert Carlson <rcarlson@...> wrote:
> >
> >
> > The words I get from support are these:
> >
> > the production labor rate in the job labor
> > transaction is drawn from the labor rate field of
> > the shop employee....it is not drawn from the Resource Group/Resource.
> >
> > I have proved that the condition existed before
> > the introduction of 8.03.409C so it's not resultant from the SP & PA.
> >
> > I have changed the rates in the Shop Employee
> > Master File and have a BAQ to look at Employee
> > labor transactions. It appears that Support was
> > correct. The Costing Manual also says that Job
> > Labor Costing is based on the rate in the Shop Employee Master File.
> >
> > Seems counter-intuitive since it limits you to
> > one rate per employee vs using the RG approach
> > where you can have different rates based on the
> > Resource. The explanation of the RG rates are
> > that they are for "estimating" purposes only, not for reporting purposes.
> >
> >
> > Bob Carlson
> >
> >
> >
> >
> >
> > At 04:50 PM 12/1/2010, you wrote:
> > >
> > >
> > >In my case, crew size was OK in the resource groups.
> > >But... we found that some templates for methods
> > >had a zero for the crew size... so new methods
> > >based on these had $0 labor in quotes, PDRs etc...
> > >Crew size is probably something different than what you have going on.
> > >
> > >Anyway we had (and still have) job costing issues...
> > >Some of it has to do with various combination's
> > >of stock, NonStock, backflush, autoreceive and costing methods.
> > >
> > >If you have the time, I'd like to know more details about the jobs.
> > >
> > >We're on 8.03.409C/Progress
> > >
> > >
> >
> > Robert (Bob) Carlson
> > rcarlson@...
> > Mobile: 603-883-8093
> >
> > [Non-text portions of this message have been removed]
> >
>
>

Robert (Bob) Carlson
rcarlson@...
Mobile: 603-883-8093

[Non-text portions of this message have been removed]
Hi Charlie,

In effect we follow what you and Chris have
advised.....what caught us by surprise was that
the HR Department controls the Shop Employee
Master File and it was either HR or Accounting
who decided to make some Production Employee's
rates $0.00 and it took 6 months for us to discover the fact.

We have a "Daily Data Watchdog" set of dashboards
that watch all sorts of Vantage data for
discrepancies: Make directs, negative
inventories, overlooked shippers, Job Final Ops &
Auto recv checks, Unpriced SO Lines, Unpriced PO
Lines, Open but unapproved PO's, and so forth.

There is now a new dashboard to watch Shop
Employee Rates......good thing there is no change
log on that file, some one would be in the unemployment line now if there were.

Bob C.

At 11:09 AM 12/2/2010, you wrote:
>
>
>I have always suggested that the labor rate should be approximately 150%
>of the pay rate. This accounts for employee burden such as employer
>payroll taxes, workers comp, overtime premium, etc. Employee overhead
>should be reviewed on a regular basis Just as Chris said and applied
>accordingly.
>
>Many companies use the pay rate as the labor rate and figure employee
>burden as part of the burden. I have always argued that because the
>burden is based on machine hours and not labor hours, that the correct
>way to do it is through labor rate and then the employee burden is
>calculated into the WIP through labor.
>
>There is more than one way to skin a cat, however.
>
>Charlie Smith, Sr. Business Consultant
>
>2W Technologies LLC
>
>www.2WTech.com <<http://www.2wtech.com/>http://www.2wtech.com/>
>
>2W Tech on Facebook
><<http://www.facebook.com/#>http://www.facebook.com/#!/pages/Chicago-IL/2W-Technologies-LLC/1391945
>69432409>
>
>From:
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
>[mailto:vantage@yahoogroups.com] On Behalf
>Of saab_barracuda
>Sent: Thursday, December 02, 2010 9:26 AM
>To: <mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
>Subject: [Vantage] Re: VANTAGE 8.03.409C SQL COSTING PROBLEM
>
>Bob,
>This is correct and it's been that way since I've been working with
>Vantage back to Ver 6. It actually makes sense if you think about it.
>Estimates are based on the resource and actuals are based on the
>employee labor rate that actually performs the work. This way you end up
>with a variance if for example a higher paid employee works a lower
>level job. Any other scheme would hide the true cost. You don't want the
>job costs to look peachy only to have the CFO to find problems with the
>balance sheet.
>
>The resource rates and employee rates should be tied closely together
>though. I go through once a year and update the resource rates based on
>a time weighted average of actual employee pay rates that worked in each
>resource. Note, the employee's "labor rate" is a separate field in a
>separate table from the "pay rate". But again, this should be closely
>monitored and adjusted as well.
>
>Regards,
>Chris Clunn
>
>--- In
><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
><mailto:vantage%40yahoogroups.com> ,
>Robert Carlson <rcarlson@...> wrote:
> >
> >
> > The words I get from support are these:
> >
> > the production labor rate in the job labor
> > transaction is drawn from the labor rate field of
> > the shop employee....it is not drawn from the Resource Group/Resource.
> >
> > I have proved that the condition existed before
> > the introduction of 8.03.409C so it's not resultant from the SP & PA.
> >
> > I have changed the rates in the Shop Employee
> > Master File and have a BAQ to look at Employee
> > labor transactions. It appears that Support was
> > correct. The Costing Manual also says that Job
> > Labor Costing is based on the rate in the Shop Employee Master File.
> >
> > Seems counter-intuitive since it limits you to
> > one rate per employee vs using the RG approach
> > where you can have different rates based on the
> > Resource. The explanation of the RG rates are
> > that they are for "estimating" purposes only, not for reporting
>purposes.
> >
> >
> > Bob Carlson
> >
> >
> >
> >
> >
> > At 04:50 PM 12/1/2010, you wrote:
> > >
> > >
> > >In my case, crew size was OK in the resource groups.
> > >But... we found that some templates for methods
> > >had a zero for the crew size... so new methods
> > >based on these had $0 labor in quotes, PDRs etc...
> > >Crew size is probably something different than what you have going
>on.
> > >
> > >Anyway we had (and still have) job costing issues...
> > >Some of it has to do with various combination's
> > >of stock, NonStock, backflush, autoreceive and costing methods.
> > >
> > >If you have the time, I'd like to know more details about the jobs.
> > >
> > >We're on 8.03.409C/Progress
> > >
> > >
> >
> > Robert (Bob) Carlson
> > rcarlson@...
> > Mobile: 603-883-8093
> >
> > [Non-text portions of this message have been removed]
> >
>
>[Non-text portions of this message have been removed]
>
>

Robert (Bob) Carlson
rcarlson@...
Mobile: 603-883-8093

[Non-text portions of this message have been removed]
Not trying to be augmentative but at most companies this is only one pay rate per employee no matter what work they do. The labor cost is supposed to represent what it costs to pay the employee(s) to run the operation. And actuals are meant to represent actual costs. I do not see how charging a generic rate based on the resource would be better. We may have to agree to disagree on this one.

And actually, the burden costs is calculated from the resource burden percentage and the employee labor rate. So it is consistent in this particular case. I absolutely agree Vantage has some serious quirks but I don't think this is one of them.


--- In vantage@yahoogroups.com, Robert Carlson <rcarlson@...> wrote:
>
> Hi Chris,
>
> I understand your point but I disagree that the
> labor rate for the production hour should come
> from the Shop Employee file and not the Resource file.
>
> The Burden costs calculation in a Labor
> transaction draws it's rate from the Resource,
> not the Shop Employee.....it presents
> inconsistent logic.......oh wait a minute, it's Vantage.
>
> By using the resource as the source of the labor
> rate you could have "skills" based labor rates
> instead of "one rate fits all work by an employee".
>
> I think for many your comments provide a direction to pursue.
>
> Thanks,
>
>
>
>
> At 09:26 AM 12/2/2010, you wrote:
> >
> >
> >Bob,
> >This is correct and it's been that way since
> >I've been working with Vantage back to Ver 6. It
> >actually makes sense if you think about it.
> >Estimates are based on the resource and actuals
> >are based on the employee labor rate that
> >actually performs the work. This way you end up
> >with a variance if for example a higher paid
> >employee works a lower level job. Any other
> >scheme would hide the true cost. You don't want
> >the job costs to look peachy only to have the
> >CFO to find problems with the balance sheet.
> >
> >The resource rates and employee rates should be
> >tied closely together though. I go through once
> >a year and update the resource rates based on a
> >time weighted average of actual employee pay
> >rates that worked in each resource. Note, the
> >employee's "labor rate" is a separate field in a
> >separate table from the "pay rate". But again,
> >this should be closely monitored and adjusted as well.
> >
> >Regards,
> >Chris Clunn
> >
> >--- In
> ><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com,
> >Robert Carlson <rcarlson@> wrote:
> > >
> > >
> > > The words I get from support are these:
> > >
> > > the production labor rate in the job labor
> > > transaction is drawn from the labor rate field of
> > > the shop employee....it is not drawn from the Resource Group/Resource.
> > >
> > > I have proved that the condition existed before
> > > the introduction of 8.03.409C so it's not resultant from the SP & PA.
> > >
> > > I have changed the rates in the Shop Employee
> > > Master File and have a BAQ to look at Employee
> > > labor transactions. It appears that Support was
> > > correct. The Costing Manual also says that Job
> > > Labor Costing is based on the rate in the Shop Employee Master File.
> > >
> > > Seems counter-intuitive since it limits you to
> > > one rate per employee vs using the RG approach
> > > where you can have different rates based on the
> > > Resource. The explanation of the RG rates are
> > > that they are for "estimating" purposes only, not for reporting purposes.
> > >
> > >
> > > Bob Carlson
> > >
> > >
> > >
> > >
> > >
> > > At 04:50 PM 12/1/2010, you wrote:
> > > >
> > > >
> > > >In my case, crew size was OK in the resource groups.
> > > >But... we found that some templates for methods
> > > >had a zero for the crew size... so new methods
> > > >based on these had $0 labor in quotes, PDRs etc...
> > > >Crew size is probably something different than what you have going on.
> > > >
> > > >Anyway we had (and still have) job costing issues...
> > > >Some of it has to do with various combination's
> > > >of stock, NonStock, backflush, autoreceive and costing methods.
> > > >
> > > >If you have the time, I'd like to know more details about the jobs.
> > > >
> > > >We're on 8.03.409C/Progress
> > > >
> > > >
> > >
> > > Robert (Bob) Carlson
> > > rcarlson@
> > > Mobile: 603-883-8093
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
>
> Robert (Bob) Carlson
> rcarlson@...
> Mobile: 603-883-8093
>
> [Non-text portions of this message have been removed]
>
Id have to support that as well.... I have yet to work at a shop that
pays variable per hour based on the type of activity an employee is
engaging in throughout the day. That would be a nightmare to manage in
my mind. If you pay that employee a consistent rate per hour then using
his labor rate really represents one of the three cost components in
your COGS (labor, burden and overhead).



Rob Bucek

Production Control Manager

PH: (715) 284-5376 ext 311

Mobile: (715)896-0590

FAX: (715)284-4084

<http://www.dsmfg.com/>

(Click the logo to view our site) <http://www.dsmfg.com/>





From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of saab_barracuda
Sent: Thursday, December 02, 2010 4:05 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: VANTAGE 8.03.409C SQL COSTING PROBLEM-Opinion





Not trying to be augmentative but at most companies this is only one pay
rate per employee no matter what work they do. The labor cost is
supposed to represent what it costs to pay the employee(s) to run the
operation. And actuals are meant to represent actual costs. I do not see
how charging a generic rate based on the resource would be better. We
may have to agree to disagree on this one.

And actually, the burden costs is calculated from the resource burden
percentage and the employee labor rate. So it is consistent in this
particular case. I absolutely agree Vantage has some serious quirks but
I don't think this is one of them.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
Robert Carlson <rcarlson@...> wrote:
>
> Hi Chris,
>
> I understand your point but I disagree that the
> labor rate for the production hour should come
> from the Shop Employee file and not the Resource file.
>
> The Burden costs calculation in a Labor
> transaction draws it's rate from the Resource,
> not the Shop Employee.....it presents
> inconsistent logic.......oh wait a minute, it's Vantage.
>
> By using the resource as the source of the labor
> rate you could have "skills" based labor rates
> instead of "one rate fits all work by an employee".
>
> I think for many your comments provide a direction to pursue.
>
> Thanks,
>
>
>
>
> At 09:26 AM 12/2/2010, you wrote:
> >
> >
> >Bob,
> >This is correct and it's been that way since
> >I've been working with Vantage back to Ver 6. It
> >actually makes sense if you think about it.
> >Estimates are based on the resource and actuals
> >are based on the employee labor rate that
> >actually performs the work. This way you end up
> >with a variance if for example a higher paid
> >employee works a lower level job. Any other
> >scheme would hide the true cost. You don't want
> >the job costs to look peachy only to have the
> >CFO to find problems with the balance sheet.
> >
> >The resource rates and employee rates should be
> >tied closely together though. I go through once
> >a year and update the resource rates based on a
> >time weighted average of actual employee pay
> >rates that worked in each resource. Note, the
> >employee's "labor rate" is a separate field in a
> >separate table from the "pay rate". But again,
> >this should be closely monitored and adjusted as well.
> >
> >Regards,
> >Chris Clunn
> >
> >--- In
> ><mailto:vantage%40yahoogroups.com>vantage@yahoogroups.com
<mailto:vantage%40yahoogroups.com> ,
> >Robert Carlson <rcarlson@> wrote:
> > >
> > >
> > > The words I get from support are these:
> > >
> > > the production labor rate in the job labor
> > > transaction is drawn from the labor rate field of
> > > the shop employee....it is not drawn from the Resource
Group/Resource.
> > >
> > > I have proved that the condition existed before
> > > the introduction of 8.03.409C so it's not resultant from the SP &
PA.
> > >
> > > I have changed the rates in the Shop Employee
> > > Master File and have a BAQ to look at Employee
> > > labor transactions. It appears that Support was
> > > correct. The Costing Manual also says that Job
> > > Labor Costing is based on the rate in the Shop Employee Master
File.
> > >
> > > Seems counter-intuitive since it limits you to
> > > one rate per employee vs using the RG approach
> > > where you can have different rates based on the
> > > Resource. The explanation of the RG rates are
> > > that they are for "estimating" purposes only, not for reporting
purposes.
> > >
> > >
> > > Bob Carlson
> > >
> > >
> > >
> > >
> > >
> > > At 04:50 PM 12/1/2010, you wrote:
> > > >
> > > >
> > > >In my case, crew size was OK in the resource groups.
> > > >But... we found that some templates for methods
> > > >had a zero for the crew size... so new methods
> > > >based on these had $0 labor in quotes, PDRs etc...
> > > >Crew size is probably something different than what you have
going on.
> > > >
> > > >Anyway we had (and still have) job costing issues...
> > > >Some of it has to do with various combination's
> > > >of stock, NonStock, backflush, autoreceive and costing methods.
> > > >
> > > >If you have the time, I'd like to know more details about the
jobs.
> > > >
> > > >We're on 8.03.409C/Progress
> > > >
> > > >
> > >
> > > Robert (Bob) Carlson
> > > rcarlson@
> > > Mobile: 603-883-8093
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
>
> Robert (Bob) Carlson
> rcarlson@...
> Mobile: 603-883-8093
>
> [Non-text portions of this message have been removed]
>





[Non-text portions of this message have been removed]