Part maintenance, buy to order, and stock vs non-stock items

I need some help understanding how EPICOR works in part maintenance for non-stock items so I can setup a few parts correctly to shorten a process. Let me explain. We have three purchased items, 3 different parts, that are non-stock, meaning we don’t stock them for all of our customers, but we actually do stock them. We don’t automatically order them. We only do that upon receipt of an order from our customer/distributor. We receive drop shipment orders against the stock and those orders are subsequently shipped from our system under different sales orders. How should I set the part up so that the original sales order for the bulk purchase is tied to my purchase order so that upon receipt the material is received into stock and the customer can be billed for them? Currently we have to ship the items and then adjust inventory back up after the receipt is posted and I want to eliminate that step. Should this be a stock item with the buy to order option checked? Please help.

The first thing to try and understand is that the “Non-Stock” flag probably doesn’t mean what you think it does. It is predominantly used for manufactured items. The way I interpret it, is parts that you’d rather not have a QOH, but will accept it when necessary.

When it comes to inventory (items in a location, with their qty’s tracked), the flag to use is “Quantity Bearing”(QB).

  • A PO of a part that has the QB set, must be purchased to stock.
  • Upon receipt of a Purchase to Stock PO, QOH of the part will be increased.

I assume these 3 parts are all Qty Bearing.

Not sure I follow you here.

Yes. All three parts are quantity bearing and they are all currently stock items.

To expound on this part, we have a customer that orders a custom part. They are a distributor and sell to end users. This part is for their customers only, so they send us orders that drop ship, that is, the orders are from our customer, but they ship to our customers’ buyer, not to our customer. If it weren’t for this customer, the parts would not exist. Make sense?

I wasn’t aware of that. So in what case would I use that check box for purchased parts, if ever? I am only referring to purchased parts as of right now. The three parts in question are custom flags. We don’t manufacture them. They are made at one of our suppliers sites and then shipped to us for stocking. Once received they are available for shipping as our customer deems fit. I think I need some more help on the quantity bearing check box as well. This would be the indicator for truly stocked items then I assume. When would I use the “Buy to Order” option or would that not fit in here?

Would it be acceptable to make ShipTo’s for your customer’s customers?

The bill to would still be the distributor, But the ShipTo would be the end customer (or retailer).

If the distibutor gave you an order for 100 pc’s (25 to retailer A, 30 to retailer B, and 45 to retailer C), you could enter it as one line with 3 releases. 25 with ShipTo ‘A’, 30 for ‘B’, etc …

We do this already. The issue is this. Our customer sends us a purchase order for the billing part so we can order the flags. Once they arrive, they send us new orders as they get them throughout the year, so we don’t currently tie each additional order to the original sales order. We have ship to’s for all of these or add them as we get new ones.

Qty Bearing means the system will track qty’s as they move about the system. PO Receipts cause QOH to go up, Customer Shipment cause the to go down.

Buy To Order is best for parts that you don’t want to stock, and will only be purchased specifically to fulfill an order Line. There are some strict built-in rules for BTO parts on PO’s. When entering a PO, you specify the OrderNum and line. That will force the PO’s line Qty to be exactly what the Qty on the Order Line was. No more, no less.

Using my example above of a Sales Order with one line (for 100 pc’s) but 3 releases, The PO would have to be for exactly 100 PC’s. When the PO is received, the parts don’t go into inventory (assuming they are not QB). But the cost goes into the inventory GL. When the shipment is made, the costs are relieved from the Inv GL. But the whole time you have them, you have no visibility of how many you have or where they are.

Buy To Order is best for something you will absolutely never inventory, and can always purchase it in the same qty you’ll sell it in. For example: you wouldn’t want to sell individual eggs, as you can only buy them by the dozen. If your customer wanted 10, you’d have to buy a 12, and either give the last two to the customer for free, or scrap them.

This makes sense for another custom part we use and it is tied to the sales order always so the quantities always match. I use the SO and the line as input on the PO so they are linked, and then process the drop shipment entry for those when I receive shipment notification. That action both closes the PO and ships the product out which allows our accounting office to bill the customer. I’m trying to create a similar action with this custom part, but it is a part that will physically sit on a shelf. How do I set this part up so that we don’t have to manually ship it for billing to be processed but still have it in inventory for future orders/shipments? One thing I forgot to mention is this… subsequent orders for this product are not billed per order, only on the first sales order which allows us to bring them in for stock.

You can purchase a Qty Bearing part as a drop shipment, to skipp having it come to you, even when you have QOH on the shelf.

We use cement (in bags) in some of our products, and also sell it for customers to use in installing our equipment. So this part is Qty Bearing, so that we can stock it for use in our production. Instead of paying to ship cement to us, just to then turn around and ship it to the customer, we’ll make a drop Ship PO.

When the cement supplier tells us they shipped to our customer, we create a receipt against the PO, which automatically makes a customer shipment that accounting could invoice against.