ERP system development
in Brookline

A vendor record inside an ERP looks simple from the outside. A name, an address, a payment term. In practice it anchors purchasing, accounts payable, and reporting all at once. A sloppy vendor file causes problems that surface weeks later, in places that have nothing obviously to do with procurement.

Payment terms are the clearest example. A supplier set up as net thirty, when the actual agreement is net sixty, will trigger early payment runs. It will strain cash planning and create a mismatch the finance team eventually has to chase down manually. The record should carry the negotiated term exactly. That includes any early payment discount. Not a default value applied at setup and never revisited.

Duplicate vendor records are a quieter version of the same issue. The same supplier gets entered twice under a slightly different name. Sometimes a different address or bank detail is attached to each copy. Spend that should appear as one relationship gets split across two records instead. Reporting on supplier concentration, or negotiating volume discounts, both depend on that spend sitting in one place, not scattered by an inconsistent entry habit.

Approved vendor status deserves its own field, rather than living only in the memory of one person. An ERP can restrict purchase orders to approved suppliers. That matters for procurement categories where insurance, certification, or a signed agreement is a condition of doing business at all. Removing approval should block new orders immediately. Open orders keep going, though. There should be no all or nothing switch that stops work mid delivery.

Bank and payment details attached to a vendor record are a common fraud target. A request to change a bank account, arriving by email and looking routine, is one of the more effective scams aimed at accounts payable departments. The ERP should log every change to payment details, with a timestamp and the user who made it. Ideally a second approval is required. It should happen before the new detail becomes active for the next payment run.

Supplier performance is worth tracking inside the same record, rather than in a separate spreadsheet nobody remembers to update. On time delivery, defect rates on received goods, and how often an order arrives short all belong on the vendor file. A buyer should see them first. Not rely on memory. Not wait for a complaint from someone in the warehouse weeks after the fact.

Tax and compliance documents attached to a vendor record, such as a signed tax form or an insurance certificate, tend to expire quietly. A field tracking the expiry date helps. So does an alert before it lapses. Together they prevent a payment from going out to a supplier whose paperwork is no longer current. Otherwise that only gets noticed during an audit, months after the fact.

None of this requires an elaborate module. It requires the vendor record to be treated as shared infrastructure, not a convenience field filled in once during onboarding. Procurement, accounts payable, and whoever signs off on new suppliers all read from the same record. Keeping it accurate saves each of them from separately chasing the same missing detail, instead of duplicating the same phone call to the same supplier three times over.

A business can easily buy an item by the pallet, store it by the case, and sell it by the individual unit, all for the same product. Every one of those is a different unit of measure. An ERP has to move between them cleanly. Otherwise numbers that should agree quietly stop matching.

The starting point is a stocking unit. That is the single unit every other measure converts back to for inventory and cost purposes. If the stocking unit is the individual piece, then a case of twenty four and a pallet of forty eight cases both have to resolve to a fixed count of pieces behind the scenes, no matter which unit appeared on the original document.

Conversion factors sound simple until packaging does not divide evenly. A case of twenty four splits cleanly into pieces. A drum of bulk liquid, repackaged into bottles of an odd size, does not split as neatly. Rounding has to land somewhere. Left unresolved, that rounding gap accumulates quietly across thousands of transactions, until a stock count no longer matches what the system expects.

Purchasing and selling often use different units for the same item, and that is normal, not a problem to eliminate. A supplier ships by the pallet. A customer orders by the each. The ERP needs a purchasing unit and a selling unit that can both differ from the stocking unit, each with its own conversion factor, rather than forcing every document into one shared unit that fits nobody well.

Cost has to follow the stocking unit, not whatever unit a transaction happened to use. A pallet purchased at one price has to translate into a cost per piece that stays consistent across every sale, regardless of whether that sale was quoted by the case or by the single unit. Get this wrong and margin reports quietly drift, even though every individual transaction looked correct in isolation.

Repacking and kitting push the conversion logic further. Splitting a pallet into cases for one customer, and into shrink wrapped bundles for another, means the same stocked item has to support more than one packaged output. The ERP should record that repack as its own transaction, consuming the stocking unit and producing the new packaged unit. It should not silently adjust a quantity on hand with no trace of what happened.

Some products need a second, independent unit alongside count, most often weight. A box of produce might be counted by the case for ordering but weighed at receipt, since actual weight varies box to box. Weight is not derived from count here. The ERP needs to hold both figures, count and weight, without forcing one to be calculated from the other. For priced-by-weight goods, that calculation runs exactly backward.

Get unit of measure wrong and the damage spreads quietly. A reorder quantity calculated in the wrong unit orders far too much or far too little. A pick list in the wrong unit sends a warehouse worker to grab cases instead of pallets. None of these errors look dramatic in isolation. The mismatch is small. The consequence often is not. Each one traces back to a conversion factor nobody checked carefully when the item was first set up.

A return is more complicated than a sale in reverse. It touches inventory, finance, and customer service at the same time. An ERP built only as a mirror image of an order usually gets at least one of those three wrong.

The first decision is authorization. Skipping this step is a mistake. Letting a customer or a field technician send an item back without any approval invites returns that do not match what was actually purchased, or items sent to the wrong location. A return authorization number, issued before the item ships back, lets the warehouse expect it, match it to the original order, and avoid the problem of unidentified inventory arriving with no paperwork.

What happens to a returned item once it arrives depends on condition. The ERP needs more than one bucket to sort it into. Resellable stock goes back to available inventory. Damaged stock needs a separate status, so it does not get shipped to the next customer by mistake. Items awaiting inspection sit in a third state. Someone has to actually look at them first. There should be no defaulting to either extreme before that check happens.

Warranty claims add a layer returns alone do not have. The system needs to know whether a specific unit is still inside its warranty period. That depends on the original ship date or purchase date tied to the serial number, not a blanket rule applied to the whole product line. A claim filed on day one of coverage is one case. One filed the day after it lapses is another. They should not be treated the same.

The financial side of a return has its own rules. A refund, a store credit, and a straight exchange are three different transactions. Each carries different tax and accounting treatment. The ERP should route each one correctly, without a person manually adjusting the ledger afterward. A restocking fee, where one applies, needs to be calculated consistently, not negotiated case by case at the counter.

Root cause tracking turns individual returns into useful information. A return coded only as returned tells nobody anything six months later. A return coded as wrong size, arrived damaged, or defective on arrival, tied to the specific batch or supplier involved, tells a different story. It lets a business see a pattern forming before it becomes a much larger problem across an entire product line.

Repair and refurbishment workflows, where they exist, need their own tracking. Keep them separate from a straightforward return. A unit sent in for repair, fixed, and shipped back to the same customer is not the same transaction as a return followed by a brand new replacement unit. Mixing the two in reporting makes both warranty cost and repair turnaround time look worse than they actually are.

A well built returns and warranty process inside an ERP shortens the time between an item coming back and a decision getting made about it. That speed matters to the customer waiting on a resolution. It matters just as much internally, where slow moving returned inventory quietly ties up warehouse space and skews stock counts until someone finally works through the backlog.