The gap this closes: you have product data, your dealer needs EDI, and building the bridge yourself means a project.
A price-and-catalogue spreadsheet, exported as CSV. Choose the dealer it is for, attach it, send. An optional second file describes related products, and the two are validated together as one submission.
The same catalogue can carry different pricing for different dealers, and each dealer receives only their own. The account number inside the file is checked against the account that sent it, so a catalogue cannot be addressed to a partner you are not entitled to.
The result is an ordinary X12 832 price/sales catalogue — styles, colours, prices, effective dates, in a standard envelope. Any trading partner's system reads it.
CSV is the way in today. A direct feed from your ERP is the intended next step, and the conversion behind it is already the same either way.
A refusal names the row, the column and the reason — not "invalid file".
In EDI, a catalogue is the whole list as far as the receiving dealer is concerned. Send three of the eight colours you make in a style, and the other five are discontinued on their side — silently, with nothing anywhere reporting it.
So the counts are read back to you, per style, on the screen, before you walk away. It is the single most useful thing the upload does, and most catalogue tools will not mention it at all.
Errors are reported the same way: located by row and column, with the reason, so a correction is a spreadsheet edit rather than an investigation. Nothing is partially accepted — a submission is taken whole or refused whole.
Every stage carries a timestamp and — unusually — a record of which system observed it.
When something stops, the first question is always whose problem is this. Most systems make you guess. Because each stage records who saw it, you can tell this application's silence from the hub's, and from your dealer's, without opening a ticket.
The stages run from the catalogue arriving, through preparation, conversion and delivery into the dealer's mailbox, then — reported back by the hub — recorded, envelope checked, collected by the dealer, and acknowledged.
Filterable by dealer, document type and status, with the times it was uploaded and acknowledged.
The file you uploaded and the EDI generated from it are both retained against the document, each with a content fingerprint — so you can prove what you sent.
A document that stopped is listed as failed and says where and why. Nothing vanishes quietly, which is the actual risk in an automated pipeline.
The same account signs into this application and the hub's own portal. There is no second directory of users to maintain.
The hub is the other half — the mailbox this application delivers into, and the record of every exchange. See what it does →