A Packaging Manufacturer Turns ERP-to-Vendor Integration Into Configuration With Files.com

A multinational packaging manufacturer makes the rigid plastic crates, containers, and components that other companies’ supply chains run on, at plants across North America and Europe.

A business built around other companies’ supply chains lives on its counterparties. The manufacturer’s operations run on an in-house ERP, and that ERP has to exchange operational data with a large ecosystem of outside vendors and service providers: payroll files, EDI documents, daily feeds from clients. Nearly all of it moves as files, and nearly all of it moves to and from systems the manufacturer does not own, cannot change, and cannot ask to behave differently. That is the fact this story turns on. Files.com gave the manufacturer a repeatable exchange layer, turning each new counterparty into a configuration task rather than a desktop, firewall, and development problem.

An FTP Client on Every Desk and a Firewall Exception for Every Vendor

Before Files.com, vendor exchange ran through employee desktops. Any employee who needed to reach an external vendor’s FTP server got an FTP client installed on their own computer, and IT opened a firewall exception to let that machine out to that vendor’s server. With many users and many vendors, the exceptions multiplied: every new counterparty meant another round of desktop installs and another set of firewall changes for IT to open, document, and keep track of.

The ERP itself had no path at all. Any data moving between the manufacturer’s systems and a vendor’s system was handled by a person, by hand.

The diagnosis underneath both symptoms is the same: The manufacturer had no repeatable way to add a counterparty. For a manufacturer whose daily operations depend on exchanging files with vendors, that was the standing condition, and the desktops were simply where it showed. As the vendor ecosystem grew, the workaround grew with it, and each new project that needed outside file exchange started the cycle again.

The Direct Integration That Couldn’t Be Built

The obvious fix was to cut people out of the path and integrate the ERP with vendor systems directly. The manufacturer’s team attempted it and could not make it work.

The problem was genuinely hard, because neither end of the exchange was theirs to change. The FTP servers on the far side belong to the vendors. Worse, the vendor ERPs behind them consume a file the instant it arrives and require it to be complete at the moment of upload, while the manufacturer’s own ERP produces files the opposite way: it writes to disk, then renames the file once it is finished. Push files straight from one to the other and sooner or later a half-written file lands in a system that processes it immediately.

So whatever replaced the desktop workaround had four requirements. It had to speak the protocols the vendors already ran. It had to give employees a path to vendor servers that touched neither their desktops nor the firewall. It had to connect the ERP without bespoke development for each counterparty. And it had to guarantee that only finished files ever left. The manufacturer selected Files.com to be that exchange layer.

One Exchange Layer Between the ERP and Everyone Else

Files.com became the single point where the manufacturer’s systems meet everyone else’s, and it faces both directions at once.

On the vendor-facing side, the manufacturer runs a partner portal on its own branded domain. For each project, IT creates a folder and vendor accounts; vendors connect over SFTP or work in a browser, with no software for the manufacturer to install on employee desktops. The IT team configured the portal without outside help.

On the ERP side, the manufacturer used the Files.com Agent to connect its on-prem file servers to Files.com. Each vendor’s FTP system was configured as a remote server, and one-way syncs carried files out on a fixed schedule.

That schedule is the answer to the file-finality problem. Because the manufacturer’s ERP writes a file and then renames it when complete, the scheduled sync only ever picks up files already in their final form. A vendor ERP that consumes on arrival never receives a partial file.

The firewall sprawl collapsed the same way. Every connection to every vendor now originates from Files.com’s dedicated IP pair, replacing the manufacturer’s expanding set of desktop-to-vendor exceptions with a standing firewall rule and giving vendors fixed source addresses to whitelist. The company then rolled its locations onto the ERP-based workflow in sequence, with data in most cases flowing directly to vendors.

Every New Counterparty Is Now a Configuration Task

With the Files.com workflows in production, the manufacturer replaced desktop installs, firewall tickets, and hand-carried files with one governed exchange layer. Daily CSV feeds from different clients now run end to end with nobody handling a file.

What began as one project’s vendor exchange is now the company’s integration hub: ADP payroll files, EDI to the ERP vendor, and connections for SnapLogic, IFS Cloud, Plytix, and SuccessFactors all move through the same layer.

The expansion is what compounds. Adding the next vendor or business system is a remote server connection and a scheduled sync: configuration, not a development project, and not a firewall change.

The Integration the Manufacturer Never Had to Build

The manufacturer never did get a direct ERP-to-vendor integration working. It turned out not to need one. Today, connecting to a system nobody at the manufacturer controls is routine work for the IT team: the vendor keeps its FTP server exactly as it is, the ERP keeps writing files the way it always has, and Files.com sits between them and reconciles the two. A new counterparty used to arrive as a round of desktop installs and firewall holes; now it arrives as a folder, an account, and a sync. The manufacturer didn’t integrate its ERP with each vendor. It gave every integration one place to happen, and that is how one project’s file transfer became the exchange layer the manufacturer runs its vendor ecosystem through.