Stock publication should usually be based on available stock after reservations and operational buffer, not raw physical stock. That sounds obvious, yet it remains one of the more expensive mistakes in Polish multi-channel commerce. On a store-only setup, scheduled sync may be enough. On Allegro plus store sales for fast-moving SKUs, stock updates should react to order creation, cancellation, and warehouse receipt events, with scheduled reconciliation as a safety layer.
One Polish retail setup selling through its own store and Allegro, with around 8,000 SKUs, initially looked like a performance problem because order import felt slow. The commercially important issue was elsewhere. The storefront published stock from a field that ignored reservations, so sellable stock was overstated during peak periods. Orders imported correctly, but support absorbed the damage through cancellations, customer messages, and manual document cleanup. After the mapping changed to available stock with a small operational buffer and event-driven updates on order creation, the pressure moved out of support and back into the system where it belonged.
Exception handling should be treated as a normal operating condition. ERP locks, duplicate webhooks, delayed payment confirmations, and renamed shipping methods are routine. The integration should queue events, retry transient failures with backoff, and enforce idempotency using a stable external order ID plus channel identifier. If the same event arrives twice, the second one should update or be ignored by rule, never create a second sales document.
Data flow that usually survives real order traffic
The safest pattern is not the most glamorous one. Keep the storefront and marketplace channels as event sources, pass those events through a controllable integration layer, validate mappings there, and only then create or update records in Subiekt GT or nexo PRO. That middle layer does not need to be heavy enterprise middleware, but it does need memory, logs, and rules.
A durable order flow often looks like this:
- Order created in store or marketplace.
- Integration layer receives the event and assigns a unique external reference.
- Validation checks SKU, warehouse, payment, shipping, VAT, and customer rules.
- If validation passes, the ERP document path is selected by channel and payment state.
- If validation fails, the order is parked in an exception queue with a readable reason.
- Stock and status updates are returned to the selling channel after the ERP action succeeds.
That sequence matters because many failed projects reverse it. They create ERP documents too early, then try to repair bad mappings after the fact. Once accounting-sensitive documents exist, cleanup becomes slower, riskier, and more political.
For teams building a custom integration layer, even a simple idempotent handler is better than blind document creation:
def import_order(event):
key = f"{event.channel}:{event.external_order_id}"
if already_processed(key):
The code is not the point. The operating rule is. Never let duplicate events or unmapped values create accounting-side artifacts silently.
Validation rules that deserve explicit ownership
Teams often talk about “sync” as if all fields were equal. They are not. Some fields are informational. Others decide whether the warehouse ships the right goods and whether accounting closes the month without manual repair.
At minimum, validate these before document creation:
- SKU identity: one external SKU must resolve to one ERP product and one unit logic.
- Warehouse routing: the order must know which stock pool it is allowed to consume.
- Payment mapping: storefront and marketplace methods must map to ERP dictionaries without fallback guessing.
- Delivery mapping: courier and pickup methods must resolve to known fulfillment rules.
- VAT path: tax treatment must align with document type and customer context.
- Customer deduplication: repeated orders should not create fragmented customer records unless the business explicitly wants that behavior.
If a vendor cannot explain where those rules live, who changes them, and how failures are surfaced, the integration is underdesigned. I have seen teams spend more time debating API access than deciding who owns the payment dictionary. The second problem causes more real damage.
Go-live and ownership: keep the first release narrow
Testing should follow the real commercial path, not the clean demo path. One successful prepaid order proves almost nothing. You need prepaid and COD, marketplace orders, duplicate events, missing SKU, changed VAT mapping, partial cancellation, and return handling. If bundles or customer-specific prices exist, test them before launch, not after the first complaint.
Go-live should be blocked unless three conditions are true: failed events are visible, duplicate documents are prevented, and support can trace what happened without asking a developer to read raw logs. If that visibility is missing, the integration is not production-ready.
Keep the first release narrow. Catalog sync, stock sync, order import, and document or status feedback are enough for phase one. Older environments benefit from staged rollout discipline similar to de-risking a legacy migration, even when the ERP itself is staying in place.
Post-launch ownership should be explicit before the switch is flipped. The store team should own storefront configuration. The ERP partner should own ERP-side settings and document logic. The integration owner should own mappings, retries, queues, and monitoring. Without a coordinator, incidents bounce between vendors while the business absorbs the delay.
The first month needs a short KPI set, not a giant dashboard: rejected order rate, stock mismatch incidents, duplicate customer creation, sync delay for stock-critical events, and mean time to resolve exceptions. If those indicators worsen while order volume grows, the integration is commercially unstable even if the connector still appears to be working.
If you need a partner for that layer rather than another plugin, our Integrations & APIs services page shows the scope involved in building reliable ERP-commerce flows.
Subiekt GT and nexo PRO integration with e-commerce works when the architecture matches the operating model and the failure paths are designed as carefully as the happy path. The wrong design often looks acceptable for the first few weeks, then breaks in a very specific way: duplicate or misclassified orders start generating the wrong document flow during peak sales, and support teams become the retry mechanism the software never had.
