Four Tochki Orders Laravel Package

Product Decisions This Supports

• Build vs. buy for 4Tochki order flow. If 4Tochki (Russian tyre/auto-parts retail) is a real channel for us — as a reseller, partner, or fulfilment route — this module covers the order-side integration instead of a from-scratch build. That is the single decision it most cleanly informs.
• Market-entry scoping. It anchors a "CIS / RU auto-parts ordering" roadmap item. It does not justify a broader marketplace or localization bet: the package is single-provider, order-scoped, and Russian-language only.
• Vendor dependency posture. 0 stars, 0 dependents, no issue tracker, releases with empty changelogs (v7.4.3 → v7.4.3). Treat it as a reference implementation and schema source, not a foundation. That reframes the decision from "adopt a package" to "buy ~2 weeks of design work at MIT prices."
• Architecture decision input. It is a Symfony bundle built on Doctrine, not an Eloquent-native Laravel package. Choosing it forces a Doctrine/Eloquent hybrid decision on the team — a real, non-trivial cost that belongs in the estimate.
• Effort estimation for planning. The README promises three commands; the real work is Doctrine bootstrap, migration reconciliation, and exception/event translation. Budget the spike, not the README.
• Scope boundary setting. The name is "Модуль заказов" (orders module) — it does not resolve catalog, pricing, inventory, or returns. Those remain open roadmap items and should be scoped separately rather than assumed.
• Ops cost comparison. The baseline alternative is a human reconciling orders from the 4Tochki back office. If that is already 1+ FTE-hours per day, the payback case is easy; if it's a few orders a month, it isn't.

When to Consider This Package

Consider it when:

• 4Tochki is already a live commercial relationship with real order volume, and the manual cost is measurable.
• The application is Symfony, or genuinely Doctrine-based, and on PHP 8.4+.
• We are comfortable owning an effectively unmaintained dependency — forking or vendoring it is acceptable.
• We only need the order domain, and we are willing to extract the API/schema logic into our own service layer rather than depend on the package at runtime.
• The 4Tochki API contract is stable enough that we can pin to it.

Look elsewhere when:

• The stack is Laravel/Eloquent-first. The Doctrine + Symfony Container/EventDispatcher/Console mismatch is a tax with no offsetting benefit at this maturity level.
• The business is outside RU/CIS, or 4Tochki is not an actual partner. This is region- and vendor-specific by construction.
• We need real-time sync, webhook validation, idempotency, or retry semantics with a guarantee. There is no evidence of these, and no one to escalate to.
• We require vendor support, SLAs, security review history, or a community to lean on.
• Multi-vendor or multi-channel order aggregation is on the roadmap — this is single-provider by design and would need replacing.
• We need analytics, forecasting, or configurable reporting on top of orders.

Preferred alternatives, in order: 4Tochki's own API documentation plus a thin in-house client (~1–2 weeks, fully owned); a middleware/iPaaS connector if one exists; or, if we do adopt this, a vendored fork with only the API client and schema retained.

How to Pitch It (Stakeholders)

For executives. "This is a free, MIT-licensed module for the 4Tochki order integration. It can save us weeks of design work, but it has no users, no community, and no support — so I am not proposing we depend on it. I am proposing a two-week, single-engineer spike: audit it, lift the useful parts (API calls and data model), and wrap them in our own code. If the spike succeeds, we get the integration for roughly 20% of a from-scratch build. If it fails, we have a validated estimate and lost two weeks. Either way we are not locked into an unmaintained package."

For engineering. "Symfony bundle, Doctrine ORM, PHP 8.4+, orders domain only, MIT. No stars, no dependents, empty release notes, one PHPUnit group for tests. Plan: do not run it at runtime. Read it, extract the API client and the schema, rebuild behind our own service and event layer, and keep the dependency out of composer.json. Two open questions to answer in the spike: (1) does it handle idempotency, retries, and rate limits, or do we build that? (2) are the migrations portable to our DB, or PostgreSQL-specific? If either answer is bad, we stop and write the client ourselves."

For commercial/operations. "This would let orders from 4Tochki flow into our system without someone re-keying them, cutting manual entry errors and the daily reconciliation step. Before we commit, we need from you: current order volume per week, hours per week currently spent on manual entry, and confirmation of how orders arrive today (back-office export, email, API). Those three numbers decide whether this is worth building at all."

Decision requested. Approve a timeboxed spike with an explicit kill criterion; do not approve production adoption of the package as a dependency.