{Disarmed} Cost Roll Up

Yahoo Archive
1
I thought once you issue at std cost no matter when or how many you
issue, it will be at std cost and the variances would hit the GL. There
have been no labor or material transactions, so that is why I assumed
the cost would have been closer. I know your actual will never be the
same as your estimate, but your job should be close to the method if no
transactions. I will take a look at resource set-up.

Thanks.



Mdg

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of robertb_versa@...
Sent: Thursday, June 03, 2010 10:18 AM
To: vantage@yahoogroups.com
Subject: {Disarmed} Re: [Vantage] Cost Roll Up





Job actual costs rarely exactly match std. Mtl costs represent cost
captured in parttran at time of issue. (At least thru 8.03.405a) elapsed
times between start/end activity for direct labor is buggy and randomly
miscalculated (and even if not miscalc'ed - who always experiences an
exact match of est MoM based time? There is almost always some
variance).
Finally: If your resources are set to split burden - burden $'s often
won't match std rolled burden (and the elapsed time bug miscalc applies
here as well).
That's why you have GL variance accts.
Rob

--- Original Message ---
From:"Millicent" <Millicent.George@...
<mailto:Millicent.George%40us.saabgroup.com> >
Sent:Thu 6/3/10 9:54 am
To:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subj:[Vantage] Cost Roll Up

We have completed a cost roll (std cost) and our job cost does not match
the cost from the method. The job was pulled from the current method so
we do not understand why we are seeing the differences. The cost from
the job is actually higher that the cost we are seeing for the bill. We
are using costing lot sizes and we checked the box pull as an assembly.
We do have sub-assemblies, set-up time included, and scrap. Does anyone
have any idea as to what may be causing our differences?





[Non-text portions of this message have been removed]
2
According to my notes on version 6.1, when a cost roll up is performed, it looks at the latest APPROVED effective date on a bom. If the bom is not approved, it will go to the next one on the list.

Is this a correct statement? I tested this statement and it did not work.

What is the correct method during a cost roll up?

Thanks,
Jasper



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

What we have found is not consistent with that statement. It only looks
at the effectivity date and does not consider the approval check box.
When performing a cost roll up you need to be aware of the date you are
doing the roll-up and the effectivity date of the revision. In our case
what was happening, Engineering was creating a new revision leaving it
not approved but putting in an expected effectivity date and leaving the
previous revision as approved. If the engineer would not have the
project completed by the expected effectivity date and not change the
effectivity date to the new expected date and we would do a cost roll or
print the costed BOM report or view costs, IT WOULD INCLUDE THE MOST
RECENT REVISION BASED ON THE COST ROLL DATE OR AS OF DATE AND NOT TAKE
INTO CONSIDERATION THE APPROVAL CHECK BOX.



Engineering is now aware and they move the effectivity dates out when
the project is not completed and approved.



Allan S. Zuleger CMA, CFM, CPIM

Controller

Marvel Manufacturing Company, Inc.





________________________________

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Jasper Recto
Sent: Wednesday, April 04, 2007 8:13 AM
To: Vantage Groups (E-mail)
Subject: [Vantage] Cost Roll Up



According to my notes on version 6.1, when a cost roll up is performed,
it looks at the latest APPROVED effective date on a bom. If the bom is
not approved, it will go to the next one on the list.

Is this a correct statement? I tested this statement and it did not
work.

What is the correct method during a cost roll up?

Thanks,
Jasper


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





[Non-text portions of this message have been removed]
4
This is what I was afraid of. According to the Vantage documents I received from Epicor, it is supposed to reference the approval check box.

Thanks for the clarification. I'll make sure this is understood by our Engineering department.

Thanks,
Jasper

-----Original Message-----
From: Zuleger, Allan [mailto:azuleger@...]
Sent: Wednesday, April 04, 2007 9:56 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Cost Roll Up



Jasper,

What we have found is not consistent with that statement. It only looks
at the effectivity date and does not consider the approval check box.
When performing a cost roll up you need to be aware of the date you are
doing the roll-up and the effectivity date of the revision. In our case
what was happening, Engineering was creating a new revision leaving it
not approved but putting in an expected effectivity date and leaving the
previous revision as approved. If the engineer would not have the
project completed by the expected effectivity date and not change the
effectivity date to the new expected date and we would do a cost roll or
print the costed BOM report or view costs, IT WOULD INCLUDE THE MOST
RECENT REVISION BASED ON THE COST ROLL DATE OR AS OF DATE AND NOT TAKE
INTO CONSIDERATION THE APPROVAL CHECK BOX.

Engineering is now aware and they move the effectivity dates out when
the project is not completed and approved.

Allan S. Zuleger CMA, CFM, CPIM

Controller

Marvel Manufacturing Company, Inc.

________________________________

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com [mailto: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com] On Behalf
Of Jasper Recto
Sent: Wednesday, April 04, 2007 8:13 AM
To: Vantage Groups (E-mail)
Subject: [Vantage] Cost Roll Up

According to my notes on version 6.1, when a cost roll up is performed,
it looks at the latest APPROVED effective date on a bom. If the bom is
not approved, it will go to the next one on the list.

Is this a correct statement? I tested this statement and it did not
work.

What is the correct method during a cost roll up?

Thanks,
Jasper

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

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







[Non-text portions of this message have been removed]
5
We have completed a cost roll (std cost) and our job cost does not match the cost from the method. The job was pulled from the current method so we do not understand why we are seeing the differences. The cost from the job is actually higher that the cost we are seeing for the bill. We are using costing lot sizes and we checked the box pull as an assembly. We do have sub-assemblies, set-up time included, and scrap. Does anyone have any idea as to what may be causing our differences?
6
Job actual costs rarely exactly match std. Mtl costs represent cost captured in parttran at time of issue. (At least thru 8.03.405a) elapsed times between start/end activity for direct labor is buggy and randomly miscalculated (and even if not miscalc'ed - who always experiences an exact match of est MoM based time? There is almost always some variance).
Finally: If your resources are set to split burden - burden $'s often won't match std rolled burden (and the elapsed time bug miscalc applies here as well).
That's why you have GL variance accts.
Rob

--- Original Message ---
From:"Millicent" <Millicent.George@...>
Sent:Thu 6/3/10 9:54 am
To:vantage@yahoogroups.com
Subj:[Vantage] Cost Roll Up

We have completed a cost roll (std cost) and our job cost does not match the cost from the method. The job was pulled from the current method so we do not understand why we are seeing the differences. The cost from the job is actually higher that the cost we are seeing for the bill. We are using costing lot sizes and we checked the box pull as an assembly. We do have sub-assemblies, set-up time included, and scrap. Does anyone have any idea as to what may be causing our differences?