ERP system development
in Quincy

A drop ship order never touches a warehouse the business runs itself. A customer order comes in. The ERP generates a linked purchase order to a supplier, who ships straight to the customer address. The business never holds the item, never picks it, never packs it. Only the paperwork passes through its own system.

That link between the two orders has to hold. Quantity on the purchase order should match quantity on the sales order. Ship to address on the purchase order should be the customer address, not the warehouse. A mismatch here is not a small clerical slip. It ships the wrong quantity to the wrong place, on a shipment nobody at the business ever sees before it leaves.

The sales order stays open until the supplier confirms shipment, and that confirmation is where many setups quietly break down. A supplier without a system connection emails a shipment notice, or does not send one at all until someone asks. Someone then has to key that information back into the sales order by hand, and a busy day means that step slips for a day or two.

Tracking information faces the same gap. A customer expects a number to watch, same as on any other order. If the supplier only emails a tracking link to a general inbox, getting that link onto the customer facing order becomes a manual chore repeated on every single shipment, which does not scale past a handful of orders a week.

Invoicing timing depends on the business relationship with the customer. Some invoice the moment the order confirms, well before the supplier ships. Others wait for supplier confirmation of shipment, which is safer but slower. A few wait for proof of delivery. Each choice trades speed against the risk of billing for something that has not actually moved yet.

Cost is often an estimate at first. The sales order needs a cost figure for margin reporting the moment it books, but the real number only exists once the supplier invoice arrives, sometimes weeks later. A true up entry corrects the estimate once the actual bill lands, the same pattern used for freight on an imported shipment, just applied item by item instead of shipment by shipment.

Inventory reports miss drop ship activity by default. That surprises a new user every time. The item never sat in a bin the ERP tracks, so a standard on hand report shows nothing for it at all. A separate open drop ship report, tracking orders placed with a supplier but not yet confirmed shipped, fills that blind spot.

Returns complicate the picture further. A damaged item usually has to go back to the supplier directly, not to a warehouse the business never used in the first place. Support staff need a process that routes a return correctly on the first call, rather than asking a customer to ship an item to an address that will only forward it along anyway.

Supplier reliability matters more here than on a normal purchase order. Control is limited. The business has no direct say over how carefully an order gets packed or how quickly it leaves the dock. Tracking on time ship rate by supplier turns a vague sense of who is dependable into a number worth reviewing before renewing an agreement.

The price on a supplier invoice is never the full cost of an imported item once it reaches a shelf. Freight, insurance, customs duty, a broker fee and inland trucking all add to that number before the item is available to sell. An ERP that ignores those additions understates the true cost of every unit on that shipment.

Landed cost is the term for that fuller number. It is built by adding every cost tied to getting a shipment from a supplier to a warehouse door, then spreading the total across the units it covers. Fair spreading matters. A container carrying six different products needs that shared cost allocated fairly, not dumped onto whichever line happens to be entered first.

Allocation method matters more than it looks. Spreading freight by weight favors light, expensive items and can quietly understate their true cost. Spreading it by value favors heavy, cheap items instead. Neither answer is universally correct. Neither is wrong either. The right choice depends on what actually drives the shipping cost for a given business: weight, volume or a flat per carton rate.

Timing is the other hard part. A purchase invoice arrives almost immediately. A freight bill does not. Nor does a duty assessment or a broker invoice, which often land weeks later, sometimes after the goods are already on a shelf and partly sold. An ERP built for this uses an estimated landed cost at receipt, then posts a true up entry once the real freight and duty numbers arrive.

That true up entry matters for margin reporting even when the gap looks small. A product that looks profitable using only the purchase price can look thin, or even lose money, once its share of freight and duty is added in properly. A business pricing from the wrong number will not notice the difference until year end.

Currency adds a further layer whenever a supplier bills in a currency other than the one the books are kept in. The exchange rate used for the purchase price and the rate used for a freight invoice paid weeks apart rarely match. Even the base cost before allocation can shift between the order date and the day the bill is paid.

Duty classification decides the rate applied to a shipment. Done wrong, it either overpays on every unit or creates a liability that surfaces later during a review. That classification is a business decision. It gets made with a broker or a customs specialist, not by the software alone from a product description.

Done properly, landed cost turns a rough purchase price into a number a manager can trust when setting a sale price. It also helps when deciding whether a supplier switch would actually help the margin on a whole product line, rather than guessing from the invoice total alone. Small shipments deserve the same discipline as large ones.

Consistency across shipments matters as much as accuracy within any single one. If one container gets a careful allocation and the next gets a rough estimate because someone was short on time, margin comparisons between the two batches stop meaning anything. A fixed method, applied the same way every time, beats a more precise method applied only when convenient. That is a discipline problem more than a software one, though the software should make the fast path and the correct path the same path.

A full physical inventory, the kind that closes a warehouse for a day while every item gets counted, is disruptive and expensive to run often. A cycle count spreads that same work across the year instead, counting a slice of the item list on a rolling schedule so operations never has to stop for it.

Frequency should not be the same for every item. Not every item carries the same risk. A small group of high value or fast moving items deserves a count every few weeks, since an error there hits the books hardest and fastest. Slow, low value items can sit on a count cycle measured in months without meaningful risk to the accuracy of the overall inventory value.

A blind count strengthens the result. Rather than showing a counter what the system expects to find on a shelf, a blind count only records what is physically there. No hints first. The figure gets compared to the system afterward. Showing the expected number first tends to bias a rushed counter toward confirming it rather than actually counting.

Variance is where the useful work starts, not where it ends. A gap between the counted quantity and the system quantity should get a reason attached before anyone posts an adjustment: a receiving error, a picking error, a miscount, theft, or damage never logged. A count program that only fixes the number without asking why teaches nothing.

Adjustments flow through to the financial books the moment they post. That is easy to forget on the warehouse floor. A large unexplained adjustment on a valuable item is a financial event as much as an operations one. It changes reported inventory value. Depending on timing, it can shift a margin figure for the period it lands in.

Accuracy itself becomes a number worth tracking over time. A count program that logs every variance can report an accuracy rate for the whole warehouse, or for one difficult zone. A falling trend is a warning sign. It means a process upstream, receiving, picking or put away, has started to break down somewhere.

The connection to planning is often missed. A reorder point calculation trusts the quantity the system reports on hand. Bad counts corrupt that trust. If the number is wrong because counts are rare or sloppy, the reorder logic built on top of it will order at the wrong time, no matter how carefully the formula itself was tuned.

None of this requires stopping work for a count to matter. A counter can work one small zone during a normal shift while picking continues elsewhere in the building. The system just needs to lock that zone against new transactions for the short window the count takes, so a pick mid count cannot throw the result off.

An outside auditor eventually asks how inventory value was verified during the year. A running cycle count program, with dated records and variance reasons attached, answers that question directly. A business that only counts once a year, right before the audit, has no such history to show, and a first count under audit pressure tends to surface every problem at once instead of catching them early.