Edifact Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for EDI ingestion. EDIFACT is the message format behind most B2B supply-chain traffic (ORDERS, ORDRSP, DESADV, INVOIC, etc.). This bundle is a data point in the "adopt an existing parser" branch of that decision — but a weak one given zero stars, zero dependents, and the legacy *Bundle naming that signals Symfony 2/3-era code.
• Roadmap scoping for supplier/customer onboarding. If a roadmap item is "accept EDI orders from logistics partners," the PM needs an estimate of parsing effort. This package helps frame the parser layer as a smaller, contained piece — the real cost is usually mappings, validation, acknowledgments (CONTRL), and partner-specific dialects, not the raw parse.
• Prioritizing message-type coverage. EDIFACT support is not binary; teams need per-message-type coverage. Evaluating packages like this clarifies which message types are table stakes for a first release vs. later phases.
• Prototype vs. production classification. This is a reference/PoC candidate, not a production dependency. That distinction directly affects whether engineering time is spent integrating it or writing a spike against it.
• Make-vs-maintain risk on legacy stacks. If the product still runs an older Symfony version, the PM must decide whether to keep investing in that stack or treat EDI work as a trigger for platform modernization.

When to Consider This Package

Consider it when:

• You are on a legacy Symfony 2/3 codebase and need basic EDIFACT parse/serialize capability quickly.
• The goal is a proof of concept, internal tool, or spike to validate EDI flows before committing to a real integration.
• You already depend on the underlying progrupa EDIFACT library and just need the Symfony service wiring.
• You need a readable reference implementation to brief engineers on EDIFACT structure (segments, elements, composites, UNA/UNB/UNZ envelopes).
• Volume is low, messages are few, and no SLA or external audit is attached.

Look elsewhere when:

• You are on modern Symfony (5/6/7) or PHP 8+ and need maintained, tested dependencies.
• You require production support, security patching, or a vendor to call.
• You need broad message-type coverage, validation profiles, or CONTRL/acknowledgment handling out of the box.
• Compliance, auditability, or high message volume is in scope — a commercial EDI gateway or a purpose-built parser is the safer call.
• You need documentation, an active issue tracker, or a community to lean on. Zero stars and zero dependents is the signal: no one is maintaining this for you.

Due diligence before any commitment: last commit date, PHP/Symfony version constraints, test coverage, license, and whether the underlying edifact library is a better entry point than the bundle itself.

How to Pitch It (Stakeholders)

For executives: EDIFACT is the standard plumbing for B2B supply-chain data — orders, dispatch advice, invoices. This package is a legacy Symfony wrapper around an existing PHP EDIFACT parser. It is a usable reference and a fast way to prototype, but with zero stars and zero dependents it is not a strategic or production-grade asset. Recommendation: use it to de-risk estimates and validate flows, but budget for either an in-house parser built on the underlying library or a commercial EDI provider before committing to customer-facing volume.

For engineering: Treat it as a spike dependency, not a foundation. Expect Symfony 2/3-era patterns, thin test coverage, and no support. The durable value is the underlying progrupa EDIFACT library, which we can adopt directly and own. The bundle itself should be evaluated against modern alternatives and only kept if our stack forces it.

Bottom line for the roadmap: the decision this package informs is not "should we use this bundle" — it's "how much of the EDI problem is parsing, and how much is mapping, validation, and partner onboarding." Framing that split correctly is worth more than the package itself.