Symfony 1C Import Laravel Package

Product Decisions This Supports

• Market/feature bet: 1C catalog integration. CommerceML exchange is the de facto format for merchants running 1C:Enterprise (common across CIS/Eastern European retail and distribution). This release lets us decide whether "sync from 1C" becomes a supported onboarding path for a merchant segment, rather than a one-off custom project.
• Build vs. buy on plumbing. Streaming XML parsing (XMLReader), ZIP handling, exchange authorization/session management, and Messenger-based worker orchestration are the unglamorous, bug-prone 60–70% of any CommerceML integration. Buying that lets us spend engineering budget on the 30–40% that is actually differentiating.
• Customization cost model, now much clearer. v2 makes CatalogImporter and OffersImporter extensible and adds CustomImporter as an extension point for extra XML files. That converts "every customer needs slightly different product/offer mapping" from a fork-per-customer problem into an app-layer subclassing problem — a direct input into support cost and per-tenant configurability pricing.
• Catalog-size and sync-frequency roadmap. Streaming parsing means memory scales with record size, not file size. That supports committing to larger catalogs (hundreds of thousands of SKUs) and to scheduled or near-real-time offer/stock refreshes without a dedicated big-memory worker tier.
• Explicit scope boundary — the most important product fact in these notes. The bundle is infrastructure and handlers only. Product persistence, pricing rules, media handling, category mapping, and conflict resolution remain ours. Any estimate that treats this as "import solved" is wrong; treat it as "transport and parsing solved."
• Framework fit decision. Despite the PHP framing, this is a Symfony bundle, not a Laravel package. If our stack is Laravel, adoption implies either running Symfony-style service wiring alongside Laravel or wrapping the importers behind our own job/queue layer. That is a real cost and should be decided deliberately, not discovered mid-sprint.
• Operational decisions surfaced by the release. New docs on Messenger workers, security, production deployment, and file cleanup imply a concrete ops checklist: queue worker supervision, temp-file retention policy, and access control on the exchange endpoint. These become platform requirements, not afterthoughts.

When to Consider This Package

Adopt when most of the following hold:

• Symfony 6.4 / 7.x / 8.x on PHP 8.2+, with ext-xmlreader, ext-simplexml, ext-zip available — or a willingness to build an adapter layer from a Laravel app.
• 1C is the merchant's system of record for catalog and offers, and CommerceML (XML/ZIP over an exchange endpoint) is the agreed transport.
• Inbound-only sync is acceptable. The notes describe import; bidirectional write-back is not in scope and would be custom work.
• You will own the business logic anyway. You have (or will build) product/offer persistence, pricing, and mapping — and you want that in your domain, not in a vendor's schema.
• You need to handle multiple large XML files, including non-standard ones — the CustomImporter extension point is the reason to pick v2 over rolling your own parser.
• You can operate async infrastructure (Messenger workers, temp file cleanup, monitored queues).

Look elsewhere or build in-house when:

• The stack is Laravel-first and the team has no Symfony service-container appetite. No first-party Laravel integration exists; budget for glue or reconsider.
• You need a managed/off-the-shelf product, not infrastructure — a PIM/middleware vendor with support SLAs, or a 1C-side connector, may beat maintaining this.
• You need bidirectional or event-level sync, delta/webhook semantics, or sub-minute stock accuracy guarantees.
• PHP 8.2+ or a modern Symfony version is not available on the target platform.
• Vendor-risk tolerance is low. A single-maintainer package undergoing a major version bump is a dependency you must be prepared to fork or pin, especially since v2.0.0 signals breaking changes versus any 1.x usage. Verify license terms, changelog depth, and recent commit activity before committing.

How to Pitch It (Stakeholders)

For executives — one paragraph. This release turns 1C catalog integration from a bespoke engineering project into a supported capability. The package handles the fragile parts — streaming large XML catalogs without memory blowups, ZIP handling, exchange authentication, and background job orchestration — while we keep control of product data, pricing, and merchandising logic, which is where our differentiation lives. The commercial upside is onboarding merchants who run 1C without paying for a custom integration each time; the cost is one integration effort plus ongoing ops (queue workers, file cleanup). It is a Symfony bundle, so the effort estimate depends on confirming stack fit before commitment. Recommended next step: a timeboxed spike on a real customer's CommerceML export to validate catalog size, file variety, and the true remaining scope in persistence and pricing.

For engineering — the short version. faustddd/symfony-1c-import v2.0.0: Symfony bundle, PHP 8.2+, Symfony 6.4/7.x/8.x, requires xmlreader/simplexml/zip. Provides streaming XMLReader-based parsing over ZIP exchange archives, improved exchange auth/session handling, explicit ZIP-open failure handling, and extension points — subclass CatalogImporter and OffersImporter, or use CustomImporter for additional XML types. It deliberately does not persist products or apply pricing; that is ours. v2 is a major release, so treat any 1.x artifacts as requiring a migration review. Before adopting: confirm our framework wiring path (Symfony bundle vs. Laravel adapter), size the persistence/pricing/mapping work explicitly, and plan queue worker supervision and temp-file retention from day one. Expanded docs/ (architecture, streaming parsing, handlers, security, deployment, workers, cleanup) is the fastest way to de-risk the estimate.