Available for projects & agency overflow · Quick reply, from the person who does the work

E-commerce development for industry and technical equipment

On an industrial store the catalogue is not owned by the site: it belongs to the ERP. The store is an ordering front end, and nearly every difficulty in the project follows from that division of roles.

Describe my issue Send a message

The store is not the item master

Price, stock, outstanding balance and the customer record live in the ERP. The store displays a copy and sends orders back. Stating that plainly changes everything else: the question to settle before the first line of code is the direction of synchronisation, field by field, and who arbitrates when the two systems disagree on the same value.

That decision is made in writing, with the people who use the ERP daily, not at the first conflict spotted in production. A table stating, for each field, who writes and who reads, avoids the classic case where a correction made in the store is overwritten at the next sync — and where nobody can say which value is the right one.

Symptoms of roles never settled

  • A price correction entered in the store disappears at the next sync, with no trace and no alert.
  • An availability date shown by the site is contradicted by the ERP at picking time.
  • The same item exists under two codes because the coding scheme was rebuilt by hand on the store side.
  • Negotiated rates never reach the basket: the logged-in customer sees the list price.
  • Technical documentation is a folder of files dropped on the server, with no version and no link to a reference.
  • The mandatory quantity step is not enforced: an order arrives with a quantity production cannot make.
  • The order produces only a PDF, with no structured data the invoicing system can use.

Coding, documents and pack sizes

An industrial reference is defined by a combination of physical characteristics: material, diameter, length, thread, surface treatment. The item code is computed from those characteristics rather than chosen. The product page therefore has to let a buyer narrow down to the exact variant from those criteria, without generating hundreds of near-identical pages that compete with one another.

Industrial buyers often look for the document before the product. Drawings, data sheets, material certificates, multilingual manuals, test reports: these must be versioned, attached to the reference, sometimes restricted to identified accounts, and above all findable by the internal search engine. A document search does not return is a document that does not exist for the buyer.

Then come pack sizes and lead times. Sale by batch, minimum order quantity, imposed quantity step, a replenishment lead time specific to each reference, made-to-order items: these are rules carried by the item and enforced in the basket, not decorative notes. An availability date announced and then contradicted costs more than no date at all.

What I settle before development

  1. The field ownership table

    For each piece of data — price, stock, lead time, item code, customer details — who writes, who reads, how often, and who wins in a conflict. That document becomes the reference whenever a discrepancy shows up.

  2. The item code rule

    Coding follows from the characteristics. I formalise it so a newly imported item gets the right code automatically, rather than depending on manual entry that will eventually drift.

  3. Behaviour when there is no public price

    Many references have no displayed price. The catalogue must be able to hide an amount, show a price-on-request label, and raise a quote request that lands in the sales tool with the basket context attached.

  4. Structured order output

    Buyer identifiers, order and contract references, mandatory statements: I check at scoping that the order produces something more than a printable document, because the whole invoicing chain depends on it.

Connected work

Frequently asked questions

Should store and ERP be synchronised in both directions?
Rarely for every field. Usually the ERP writes price, stock and lead time, while the store writes orders and sometimes delivery details. Deciding field by field prevents silent overwrites and simplifies development considerably.
How do you avoid hundreds of near-identical pages in one family?
By publishing one page per technical family, with a selector that narrows to the exact variant from the characteristics: material, diameter, length, thread. The variant stays orderable and identified without becoming another indexable page.
Can prices differ per customer?
Yes, provided the price grid comes from the ERP and is applied after sign-in, per customer and per product family. You also need to handle the anonymous visitor, who should see neither the negotiated price nor the outstanding balance.
Where should drawings and material certificates be stored?
Attached to the reference, with a version number and a date, and an access rule separating what is public from what is restricted to identified accounts. The internal search engine must index their metadata, otherwise buyers never find them.
How is a per-reference lead time handled?
As item data coming from the ERP, recalculated in the basket from the longest line, and shown with its nature: in stock, on replenishment, or made to order. Announcing nothing beats announcing a date that turns out to be wrong.

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

outil
api
sens
frequence (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.