A Safety Equipment Manufacturer Lands Supplier EDI Straight on Its Epicor Server With Files.com

A safety equipment manufacturer makes the equipment that keeps people alive at height: harnesses, lanyards, anchors, dropped-object prevention, and custom-engineered fall-arrest systems.

Almost none of that product reaches a job site directly. The company sells through distribution partners, and the commerce of that model, from purchase orders to invoices to acknowledgements, moves as EDI. The company's systems of record run on Epicor ERP, fed by an EDI system on an Azure server that translates every trading partner's documents into Epicor's terms and back again. A manufacturer that sells through trading partners lives on document exchange with counterparties it does not control, and that is the exchange the company wanted to see from end to end. With Files.com, a supplier's upload and the EDI server's file became the same event, with no intermediary hop between the trading partner and the translation layer.

An Acknowledgement Path Built on Intermediaries and Polling

The company's trading-partner connectivity was built the way most EDI estates are: on intermediaries and polling. Some documents moved through VANs, the value-added networks that act as P.O. boxes between trading partners. For direct connections, scheduled SFTP jobs on the company's own EDI server reached out into each counterparty's SFTP endpoint to see what was sitting in their folders and bring it back.

That architecture set the requirement, and the requirement was acknowledgements. Every EDI document the company receives generates a functional acknowledgement that must travel back to the counterparty, and when a partner connects to one system, that system hands off to another, and the company's server picks files up from folders on a schedule, the acknowledgement crosses several hops that the company does not run. The company wanted the document and its acknowledgement to travel one path it could see end to end, so that delivery is a matter of record on the company's own server.

Monitoring alone does not get there. A hop run by someone else stays outside the company's control however closely it is watched, and the polling model added work at the margin: every new counterparty meant another scheduled job on the company's server reaching into infrastructure the company did not run.

A Push Model Needed an Endpoint the Manufacturer Could Hand Out

The requirement came to a head when the company's supplier connections began shifting to a push model: instead of the company's server reaching out to retrieve files, suppliers would deliver EDI documents to the manufacturer. That required something the company did not have: a hosted, credentialed endpoint it could hand to each supplier.

The endpoint had to keep every supplier isolated from every other. It had to put inbound files where the EDI translation layer actually reads, rather than creating one more mailbox for the company to poll. And it could not become another piece of infrastructure to patch and secure. The obvious route was to run their own SFTP server, and the company had already been down it: the company's IT systems engineer prototyped exactly that in Azure and rejected the direction before it reached production.

The manufacturer selected Files.com to be that hosted endpoint.

The Mailbox and the Server Became the Same Place

Files.com hosts the endpoint suppliers connect to, over SFTP with a client or through the web interface. The company built a supplier directory with an inbound and outbound subfolder per vendor, and per-user permissions confine each supplier's credential to its own folders, so no counterparty can see what any other counterparty is trading.

The part that removes the hops is on the other side. The company installed the Files.com Agent as a system service on the Azure VM that runs its EDI system, and a Files.com Remote Server Mount joins the supplier directory to that server's own filesystem. The Agent connects outbound only, so the EDI server accepts no inbound connection from the internet and there is no inbound firewall rule to maintain.

The consequence of that design is immediate delivery to the translation layer. The moment a vendor writes a document into its Files.com folder, the file is on the disk the Epicor-connected EDI system reads, and translation into Epicor's specifications proceeds from there. Outbound works in mirror image: the EDI system translates Epicor documents into the counterparty's specifications and writes them to the supplier's outbound folder, where the same write instantly becomes the file the supplier retrieves with the same credential. There is no mailbox between the trading partner and the translation layer, because the mailbox and the server became the same place.

One Credentialed Hop, Visible End to End

With the supplier path in production, the company established a single credentialed hop it can see from end to end. The clearest operating payoffs are the transfer infrastructure and polling jobs it no longer has to run, and a supplier-onboarding pattern that repeats without rework.

• The company runs no transfer infrastructure for the exchange: no SFTP server to patch and no scheduled retrieval jobs to maintain. Files.com carries the transport.
• Onboarding the next supplier is a folder pair and a credential. The same pattern repeats without rework, with no new job added to the company's server and nothing new for the EDI team to operate.
• A supplier's document lands directly on the server the EDI system reads, with no VAN mailbox and no company-side polling job in between. Every hop on this path is one the company can see.
• Acknowledgements travel back over the same path, and the round trip lands within the roughly one hour the company's EDI team set as its tolerance for business-critical documents.

Transport That Is No Longer the Manufacturer's Job

The company's EDI team asked for a specific division of labor: files appear in their folders, and everything upstream of that is a platform someone else runs. That is what Files.com now does for the supplier exchange. The team's work is translation and trading-partner logic, the part that actually requires EDI expertise, while the movement of the documents themselves happens without anyone at the company scheduling, watching, or retrieving anything.

The distance travelled is easiest to see in what an acknowledgement is now: a file written to the same disk the EDI system reads, with nothing between the two. The company did not add monitoring to a path with several hops. It used Files.com to take the hops out.