Unconfirmed Purchase Orders ready to Receive, awaiting pricing from vendor

[Chrisw (Chris Were)]

Our purchasing dept creates a lot of POs where we do not get a pricing confirmation from the vendor ahead of receipt, and some of the pricing may vary wildly PO to PO (eg we are charged per “trolley load” for things like powdercoating, then pro-rata this over the parts in the order).

The problem is the parts arrive while the PO is unconfirmed, and need to be received quickly as some are needed on jobs, but we need to wait for the invoice to arrive to correct the PO pricing, to confirm it so it can be received.

If we just confirm with the wrong pricing there’s variances all over the show as the received parts go onto jobs etc.

Is there any way to allow receipt of POs and to apply the correct pricing after receipt when it is known,and have these variances automatically adjust stock values/job costs etc after receipt?

Our old system (MAGI) had a means for handling this. I think it tracked receipt lots and would go through and make adjustment transactions where needed (that’s how its been described to me at least).

We aren’t using Lot Tracking yet in Epicor, would this help or is it intended for another purpose?

Thanks,
Chris

[Chad_Smith]

@Chrisw

but we need to wait for the invoice to arrive to correct the PO pricing, to confirm it so it can be received.

You have no way to know the cost of the goods you are buying until the invoice shows up? Do you need any new suppliers by chance? I’d like to sign up!

In all seriousness, what you are describing is really a process problem and not a systems problem. The system is doing what is supposed to do.

Out of curiosity, what’s your valuation method on these purchases? Is it only the subcontract ones that are a problem? Based on what you are describing, you’re also consuming the parts before you know the costs. I’m not sure there’s going to be a clean and easy way to deal with that.

[aosemwengie1 (Alisa Osemwengie)]

If your parts are average costed then no Epicor doesn’t have a way to deal with this. We have the same problem. I don’t see how lot tracking would help.

[dcamlin (David Camlin)]

We see this from time to time (especially on subcontract).

We will mark the Packslip as “arrived” but won’t mark it as “received” until the invoice arrives with the proper value.

We’ll update the price on the receipt… then receive… then issue the material to the job. Yes, all after the fact.

There’s nothing stopping you from physically taking them to production so they can keep moving forward. Your cost will just not be up-to-date until the parts are finally received and then issued in the system.

We feel this is… inconvenient (having to wait for the invoice to arrive)… but still a better scenario than issuing material to the job with the wrong cost. In those cases, we would return the material from the job, do a cost adjustment, then re-issue to the job. Adds a bunch of transactions, but you end up with the correct cost and no variance that way.

[Mark_Wonsil]

Totally agree with @Chad_Smith here. This is a timing issue - especially if one doesn’t use Standard costing. If something gets issued at zero to a job and that job is issued to something else, good luck tracking that. I’d love to see how the MAGI calculated that kind of movement - especially if tracking average cost.

[JMPCONJ (John Magee)]

@Mark_Wonsil

I’d love to see how the MAGI calculated that kind of movement

With gold, frankincense, and myrrh.

Seriously, @dcamlin pretty well covered it. Issuing material with the wrong cost (or issue/return/CST-ADJ/reissue) is no bueno.

[dcamlin (David Camlin)]

@Chad_Smith

You have no way to know the cost of the goods you are buying until the invoice shows up?

I think this is an overstatement in scenarios such as this. You know (in general) what the cost is going to be… but like @Chrisw noted, this is often for subcontract “batch” operations. Sending a bunch of parts out to one vendor for heat treating… or black oxide coating… etc. If you send a couple parts out, the price per part is higher. If you can send a whole “furnace load”, you get a better price per part. So, you know who the vendor is, know their pricing is acceptable… you just don’t know the ACTUAL cost per part until the invoice shows up.

My company uses FIFO costing… so, thinking about this a bit, I’m wondering if I could create a function that when updating the cost of a given Part & FIFO sequence, whether it could then look at any jobs that part was issued to and update the costs on the job. Whether that would be via a job cost adjustment, or even automate the return/cost adjust/re-issue process.

Again, for us, the timing isn’t THAT critical, so we just let the parts sit in the “arrived” states until the unknowns are known… then we play catch-up.

[dcamlin (David Camlin)]

@JMPCONJ

@Mark_Wonsil

I’d love to see how the MAGI calculated that kind of movement

With gold, frankincense, and myrrh.

nice

[JMPCONJ (John Magee)]

@dcamlin

Again, for us, the timing isn’t THAT critical, so we just let the parts sit in the “arrived” states until the unknowns are known… then we play catch-up.

Better safe than sorry…just seems like the neatest cleanest way of handling the costs. It’s troublesome enough even with the most basic of costing scenarios like we have…standard/average, simple BOMs, occasional landed cost complications.

[Mark_Wonsil]

@dcamlin

whether it could then look at any jobs that part was issued to and update the costs on the job.

And the jobs that was issued to, or a shipment, or a NC, or another other downstream inventory transaction. Sure, if things move slowly, you could probably catch up, but in faster scenarios it would be much more difficult as there are more places to “catch up.”

on batch jobs like heat treat and plating. They are a PITA for sure.

[Chrisw (Chris Were)]

As @dcamlin said it happens on subcontract pos all the time: powdercoating, anodising etc. Some for example charge by the half-trolley load, so yes price from recognized vendors is known to be acceptable but variable depending what is sent.

[Chrisw (Chris Were)]

MAGI (Manufacturing Action Group Inc, magierp.com, if you are curious) had a monthly process that would run through and automatically unreceive/re-receive POS and unissue/reissue parts to jobs based on their actual invoiced costs (this also handled additional freight burdens, and occasional minor but urgent POs where the costs were unknown but known to be small). It would track all received parts by lot/serial numbers of each receipt through their other transactions I guess. This may have been a customization we had written for us.

[Chrisw (Chris Were)]

Thanks David,
So we can mark parts on an uncomfirmed PO as arrived, but not yet received? I’ll run that up the flagpole with purchasing and stores to see if it helps.

[dcamlin (David Camlin)]

Another thing to consider: Again, since we do this often, we have this setting selected in Company Config > Materials > Shipping Receiving:

This keeps the “Supplier Price” field active on Receipt Entry.

Our steps in these cases:
Your receiving team can still receive against the PO. They can create a packing slip when parts arrive, add the received lines to the Packing Slip and adjust quantities … just don’t mark them as received.

Save the Packing Slip and they’re done… for now.

On the Receipt Entry Landing Page, they can easily find these again later if they use the “Arrived” view option.

When the invoice arrives… our AP team will actually send a copy of that to our receiving team. The Receiving Team will then:

• Open up that “Arrived” receipt…
• Open the Pack Line
• update the Supplier Price (unit cost) on the Receipt…
• Click “Received” on the Pack Line

So, yes, extra steps. But, doing it this way allows users to still know parts have “arrived” when they show up.

However, IF you use Epicor for incoming inspection (for example)… I don’t think you can move forward with that step unless parts are in the “received” state. So, that may or may not be a roadblock for you/your company.

We actually go off-book when it comes to inspections. We found Epicor’s inspection/DMR process too cumbersome. We actually use the above process for ANYTHING we receive that goes through incoming inspection (which is most parts we receive).

Parts arrive, we create the packing slip like above, leaving them in the “arrived” state. The parts get moved to incoming inspection… once inspected, they get moved back to the receiving department and they officially “receive” them. If they fail inspection, we adjust the received quantity to only account for what was “accepted” and/or delete the receipt if all of a specific line item fails. We’ll then Misc. Ship them back to the vendor with corrective action or request for replacement. Again, we do this in order to side step Epicor’s inspection/DMR process. At the end of the day, if a part comes in and is bad, it is simply never received into Epicor at all.

[JMPCONJ (John Magee)]

@Chrisw

MAGI (Manufacturing Action Group Inc, magierp.com, if you are curious) had a monthly process that would run through and automatically unreceive/re-receive POS and unissue/reissue parts to jobs based on their actual invoiced costs…

Ah, yes. The gift of the Magi.

(ba-dum-bump…two shows Saturday…tip your servers.)

[aosemwengie1 (Alisa Osemwengie)]

@dcamlin

Save the Packing Slip and they’re done… for now.

Right, but if your goal is to then be able to turn around and ship those parts out or issue them to a job, they aren’t in inventory yet, which means the average cost hasn’t updated yet. So if you ship them now and receive them later the cost calc is still out of whack.

[dcamlin (David Camlin)]

@aosemwengie1

if you ship them now and receive them later the cost calc is still out of whack.

The point of this whole thread is dealing with costs that are KNOWN to be out of whack. In these cases we’re “receiving” parts when we don’t even know the true cost yet. So, we KNOW the cost in the system is wrong to begin with. You can either receive them and issue them and back them out and correct them later… or handle with adjustments later… or find a different solution. In my company’s approach, we just to step outside the box for a few days while we wait for a piece of paper to arrive.

@aosemwengie1

… if your goal is to then be able to turn around and ship those parts out or issue them to a job

You’re absolutely right but… it’s not. It’s not our goal at all.

@dcamlin

There’s nothing stopping you from physically taking them to production so they can keep moving forward. Your cost will just not be up-to-date until the parts are finally received and then issued in the system.

We will still move these parts internally so work can continue on the job… they just won’t be issued to the job until later.

We won’t SHIP them to a customer until they’re officially received. There’s always scenarios where any process won’t work.

@dcamlin

Again, for us, the timing isn’t THAT critical, so we just let the parts sit in the “arrived” states until the unknowns are known… then we play catch-up.

@dcamlin

… but still a better scenario than issuing material to the job with the wrong cost. In those cases, we would return the material from the job, do a cost adjustment, then re-issue to the job. Adds a bunch of transactions, but you end up with the correct cost and no variance that way.

I’m not saying this is the answer to the ultimate question of life, the universe and everything. (We all know that is “42”). This is the solution that works best for my company. I’m not trying redefine Epicor’s process for everyone.

I was just offering up one approach. Individuals would need to evaluate such a process and determine if it would work for them in cases where costs are unknown upon receipt.

[aosemwengie1 (Alisa Osemwengie)]

@dcamlin

We will still move these parts internally so work can continue on the job… they just won’t be issued to the job until later.

Doing stuff later is a recipe for it not getting done at all imo. I get what you are saying but every approach has its drawbacks. Slow down shipping and production to ensure cost accuracy. Or go ahead and move forward and hope people enter the right transactions after the fact. Or live with the cost discrepancies. I wish there were better solutions.

[Chrisw (Chris Were)]

Thanks David that’s really helpful. Have passed on to those concerned, and lively discussions have ensued

[Hally (Simon Hall)]

I am confused about all of this what about PPV does that have any effect on the costs retrospectively. I thought this was how landed costing worked…

What about unreceived invoice matching? Doesn’t that do the cost adjustment after the fact? I guess you start going down that cascading cost problem people spoke of earlier.