Inconsistency in the way costs are handled for a component part

Yahoo Archive
1
One thing along this line that we have discovered was that the cost lot size needs to match off to the mfg lot size or multiple being used.

we also have sheets of steel that got setup as an EACH UOM (no decimal allowed) and yet can be used as a partial in production. This does odd things to costs as well because the full cost of a sheet gets applied to a job if the job qty is less than the sheet yeilds in production.

Brad Boes
Metalworks


--- In vantage@yahoogroups.com, "b_ordway" <cooner_55421@...> wrote:
>
> >>issued to a job at 1.03 and later received
> >>from the same job within its parent with a value of 10.43?
> Is this from the Production Detail Report?
> What version? etc...
>
> I've run into some cost puzzles before but I don't recall what you've described.
>
>
> >>So far Epicor has their fingers in their ears on this one
> Yeah, I think unraveling costing issues gets too involved and time consuming for basic support.
>
>
>
> --- In vantage@yahoogroups.com, "stanchmura" <schmura@> wrote:
> >
> > In the BOM cost report under a parent part number FTITP18809 I have a component part number 154972 that's showing a value of $10.43. This part has a BOM and is marked as manufactured/average cost method. It's std cost found in part tracker is $10.43283; the average is $1.02847.
> >
> > In the details for a job run against the parent part, the component was estimated and was issued at its average cost of $1.03 the way it should. But the receipt of the parent to inventory was at the cost shown in the parent's Cost report of $15.42; where the component is valued at the standard cost of 10.43. This is clearly a conflict of cost methods for the component. How can it be issued to a job at 1.03 and later received from the same job within its parent with a value of 10.43?
> > Has anyone else encountered this? (So far Epicor has their fingers in their ears on this one)
> >
>
2
In the BOM cost report under a parent part number FTITP18809 I have a component part number 154972 that's showing a value of $10.43. This part has a BOM and is marked as manufactured/average cost method. It's std cost found in part tracker is $10.43283; the average is $1.02847.

In the details for a job run against the parent part, the component was estimated and was issued at its average cost of $1.03 the way it should. But the receipt of the parent to inventory was at the cost shown in the parent's Cost report of $15.42; where the component is valued at the standard cost of 10.43. This is clearly a conflict of cost methods for the component. How can it be issued to a job at 1.03 and later received from the same job within its parent with a value of 10.43?
Has anyone else encountered this? (So far Epicor has their fingers in their ears on this one)
3
>>issued to a job at 1.03 and later received
>>from the same job within its parent with a value of 10.43?
Is this from the Production Detail Report?
What version? etc...

I've run into some cost puzzles before but I don't recall what you've described.


>>So far Epicor has their fingers in their ears on this one
Yeah, I think unraveling costing issues gets too involved and time consuming for basic support.



--- In vantage@yahoogroups.com, "stanchmura" <schmura@...> wrote:
>
> In the BOM cost report under a parent part number FTITP18809 I have a component part number 154972 that's showing a value of $10.43. This part has a BOM and is marked as manufactured/average cost method. It's std cost found in part tracker is $10.43283; the average is $1.02847.
>
> In the details for a job run against the parent part, the component was estimated and was issued at its average cost of $1.03 the way it should. But the receipt of the parent to inventory was at the cost shown in the parent's Cost report of $15.42; where the component is valued at the standard cost of 10.43. This is clearly a conflict of cost methods for the component. How can it be issued to a job at 1.03 and later received from the same job within its parent with a value of 10.43?
> Has anyone else encountered this? (So far Epicor has their fingers in their ears on this one)
>