ERP system development
in Santa Monica

Every order, invoice, purchase and shipment inside an ERP needs a number. That number has to mean the same thing wherever it appears. Sales sees an order number. Warehouse sees a pick list number. Accounting sees an invoice number. If those are not linked cleanly, tracing one transaction across departments turns into a manual hunt.

A custom ERP gives a team the freedom to design its own numbering scheme, rather than accept whatever a packaged system assumes. That freedom is useful. It is also where mistakes creep in quietly. A sequence that resets every year, every month, or never, changes how easy old records are to find years later.

Prefixes carry more information than they look like they do. An invoice numbered with a year and a location code tells a person something useful at a glance, before they even open the record. A plain running number tells them nothing. It only says it came after the one before it.

Gaps in a sequence raise questions. This matters most in finance, where a missing invoice number can look like a missing invoice rather than a cancelled draft. Deciding early whether numbers get reused, skipped, or marked void when a document is cancelled avoids an awkward conversation with an auditor much later.

Multiple systems generating numbers at once is where custom ERP work gets genuinely difficult. If a website and an in person sales tool both create orders, and both assign numbers on their own, duplicates are only a matter of time. One place should own the sequence. Numbering usually needs to live there, with every other system asking for the next value.

Linking related documents matters as much as numbering each one correctly. An invoice that references the purchase order and the shipment it came from turns three separate lookups into one screen. That link should be a stored reference, not a guess. Nobody should reconstruct it later by matching dates and amounts by eye.

Renumbering an existing set of records, because an old scheme ran out of room or never had a location code, is a project of its own. Every report, every archived document, and every external reference built on the old numbers has to keep working, or be updated in step with the change.

None of this is glamorous work. It rarely shows up in a sales pitch for a new system. It is, however, one of the first things a finance team tests. Getting it right the first time costs far less than fixing it once years of records already depend on the old pattern.

Most of the conversation around a custom ERP concerns the people inside a company who use it every day. There is a smaller, real need too. A vendor checking a purchase order, or a customer checking an invoice, needs a narrow window into the same data, without a phone call.

Email and phone calls are the default way this information moves today. They do not scale well. A vendor asking whether a payment went out, or a customer asking for a copy of an old invoice, becomes a task for a staff member every single time. The answer already sits in the database.

A portal solves this by exposing one thin slice of the ERP to an outside party, built for a narrow set of questions rather than general use. A vendor might see open purchase orders and payment status. A customer might see order history and current balance. Nothing more. Neither needs a view into anything beyond that.

Permissions here are stricter than anything used internally. An employee role might be broad, because the person is trusted and accountable inside the company. An external login has to be scoped down to exactly the records that belong to that one vendor or customer, with no path, accidental or otherwise, into data belonging to anyone else.

Authentication for outside users deserves its own design, rather than reusing the internal login system. A vendor does not need a full staff account. It does not need a password reset flow tied to a company mailbox, or access to internal tools. A separate, lighter login built for external access keeps that boundary clean.

Data freshness is worth deciding on deliberately, rather than leaving it to chance. Some portals show a live view straight from the ERP. Others show data refreshed on a short delay. That is simpler to build. It is often good enough, since a vendor checking a payment status rarely needs it to the second.

A portal also changes what support looks like. Instead of a person manually pulling a record and emailing it out, the request becomes self service. Staff time shifts elsewhere. It moves toward the cases a portal cannot answer on its own, which tend to be the ones that actually need a human anyway.

Rolling a portal out to one group first, vendors or customers rather than both at once, keeps the early version small enough to fix quickly. Expanding to the second group once the first is stable is usually smoother than designing for both audiences in a single launch.