Sync flows¶
Sync is driven by Action Scheduler jobs. Each entity type has two scheduler classes:
- An index scheduler that finds new/changed WooCommerce records and schedules sync jobs.
- A sync scheduler that performs the actual API call to Business Central.
Orders¶
flowchart TD
A[WooCommerce order created/updated] --> B[OrdersScheduler indexes order into bc_order_index]
B --> C{Already in index?}
C -- No --> D[Insert row with sync=false]
C -- Yes --> E[Update row]
D & E --> F[Action Scheduler: SyncOrdersScheduler]
F --> G{Customer synced?}
G -- No --> H[Sync customer first]
H --> I[SyncOrdersScheduler: POST/PATCH salesOrder]
G -- Yes --> I
I --> J[Store bc_guid + bc_etag]
J --> K[SyncOrdersScheduler: POST salesOrderLines]
K --> L[Mark lines_created=true, sync=true] Customers¶
Customers are synced as part of the order flow (if the customer is not yet in BC) or independently via CustomerScheduler / SyncCustomerScheduler. A BC customer number is derived from the WooCommerce customer's billing country prefix + customer ID and stored via the business-central/customer/set-number filter.
Products¶
Products are pulled from Business Central into WooCommerce via ProductsScheduler. BC items are matched to WC products by item number and stored in bc_product_store.
Refunds¶
Refunds follow the same pattern as orders:
RefundsSchedulerindexes WC refunds intobc_refund_index.SyncRefundsSchedulerpostssalesCreditMemoandsalesCreditMemoLinesto BC.
Patch webhook notifications¶
PatchWebhookNotificationScheduler periodically renews BC webhook subscriptions so that incoming BC notifications remain active.
Sync guards¶
- A WP option lock (
bc_order_sync_running,bc_refund_sync_running) prevents concurrent runs of the same sync job. - The
Claimabletrait marks index rows with a uniqueclaim_idbefore processing; claims are released after the batch completes (or on failure) to avoid double-processing. - Individual order lines already synced (
_bc_guidorder item meta) are skipped.