Why is cost per site but price is per warehouse?

Kinetic ERP
1

Given the hierarchy company > site > warehouse, why can I can control price at the warehouse level but cost only at the site level? The field help says, " Use the Warehouse sheet to establish the warehouses to which this price list applies. By default, the price list applies to all warehouses in the site." (so helpful) but in fact the the price list applies to every warehouse in the company, because price lists are not site specific.

I don’t get the reasoning. Wouldn’t it be more logical to assign pricing to the site? Or cost at the warehouse? Don’t most people align their prices and their costs to maintain margin?

2

We had a “refurb” warehouse where the price was reduced over the new product in other warehouses. That worked for us, but I do see your point. Maybe cost should be by warehouse too? :thinking:

3

Wouldn’t that be amazing. I can understand why you can’t have costs per warehouse though, the trigger for costs to updated is a transfer order. If you just move inventory from one warehouse to another, how would cost get updated?

1 Like
4

I’m not necessarily complaining about it, I just don’t understand it. Like wouldn’t it make more sense that price lists are site specific and THEN you pick which warehouses? Selecting warehouses directly on something that is company-wide just doesn’t make sense to me.

5

Just talking to myself here but it seems like even though you can specify pricing per warehouse, if you have two releases, only the warehouse specified on the first release drives the price selection on the order line. Which means its not truly warehouse specific pricing.

6

https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-4017

7

Wow, that is rough.

I mean, we have no need to do different pricing by warehouse, so I can’t relate in that way. But this does seem really incongruous.

I can’t say I am fan of moving the price to the release - more of a “moving my cheese” reason more than anything. But I do sympathize with this being a double standard.

My pet peeves are usually company settings that should be site-specific:

  • It’s really nice for each site to have POs that have a different range (PO for site A starts with a 1; site B starts with a 2, etc.). This helps us and the carriers also. (Our other site has a VERY similar address.) But PO numbering is company-wide, unless you do a BPM to override it, which I did, but it doesn’t work on actioning PO suggestions, for example.
  • Part transaction GL controls are part-specific (or part-class specific, or company-wide), but a part can be inventoried in one site and not in another. Typically those are different GL accounts (inventory hits inventory GL, but non-inventory hits expense).
  • And probably more.
8

What if it was like the dates, where it can be set at one level but overridden at the lower level (but not required at the lower level)?

9

Sure, it’s probably the best solution and like you said follows the date logic.

IDK, it’s a shift, for sure.

I mean, at that point, then, is a line any different from a release?

I guess the only thing that would be unique to the line is the part number?

Not arguing, just trying to envision this.

I hate to start a :dumpster_fire:, but I wonder what other ERPs do with lines and releases.

FYI, my mind assumes that you are needing to apply this logic to POs also.

And to that end, how will that play with your customer’s ERP, if you have different pricing on the releases?

10

Yes these are the same questions I am thinking about. You can already have different ship dates, quantities, ship from, and ship to locations on a release. Logically you should be able to have a different price too, or else price shouldn’t vary based on any of those things.