Configuration

Erpy splits its settings in two. Anything that belongs to one ERP lives on its connection. What is left is on the plugin's settings screen, because it should be true of every ERP you talk to.

The connection

Erpy → Connections → your connection.

Name and handle	The handle is what console commands take: php craft erpy/sync/run acme
Connector	Which ERP. Changing it on a live connection is not a thing you want to do
Enabled	A disabled connection never syncs, scheduled or otherwise
Store	Which Commerce store this connection feeds, on a multi-store site
Credentials	Whatever this connector declares — a URL, a key, a tenant, an OAuth flow

What it syncs

Each entity — products, prices, inventory, customers, orders, order status, shipments, invoices, payments, credit — gets its own row: direction, interval, and any filters the connector offers.

Only what your ERP actually supports is offered. You can narrow a direction; you cannot widen one. If a connector declares that it can pull products but not push them, there is no setting that will make it try — and the conformance suite that ships with Erpy is what keeps that promise honest.

Intervals are per entity on purpose. Inventory usually wants fifteen minutes and the product catalogue usually wants overnight. One interval for the whole connection means either hammering the ERP for a catalogue that changes twice a week, or letting stock go stale.

Test connection

Press it after every credential change. It calls the connector's health check, which is a real request to the ERP, and reports what came back — with secrets redacted.

Plugin settings

Erpy → Settings.

Logging

Setting	Default
logRequests	on	Record requests in the connection log at all
logBodies	on	Bodies are the useful part, and also the large part
logErrorsOnly	off	A busy catalogue sync is tens of thousands of successful requests nobody will read
logRetentionDays	14
runRetentionDays	30
recordSkippedItems	off	On a 40,000-SKU delta sync, "unchanged" is 39,900 of the rows
staleRunMinutes	60	A run still marked running after this long had its worker killed

A log write must never be the reason a sync fails. If the log table is unavailable, the sync carries on.

Orders

Setting	Default
pushOrdersOnComplete	on	Queue a push when an order completes. The only automatic write Erpy makes
pushOrderDelaySeconds	0	Wait before pushing — useful when payment capture is asynchronous and the ERP should not see an order the gateway has not settled
pushMaxAttempts	5	Retries before the document dead-letters for good

Order push is always queued, never inline. An ERP having a slow afternoon must not delay a customer's confirmation, and an ERP being down must not fail a sale.

Storefront

Setting	Default
applyContractPricing	on	Apply ERP contract pricing to cart line items
enforceCreditLimit	off	Refuse to complete an on-account order that would exceed the customer's credit limit
creditMaxAgeMinutes	60	Credit figures older than this are re-fetched before they are trusted to block a sale

enforceCreditLimit is off by default because it can stop a sale, and that has to be a decision rather than a surprise.

Scheduling

scheduleEnabled lets scheduled syncs run from Craft's queue. For a large catalogue, run erpy/sync/due from cron instead — cron has no request timeout. See Syncing.

Permissions

Erpy registers its own permissions, so a warehouse manager can watch activity without being able to edit credentials:

• View ERP connections → add/edit/delete connections, run a sync by hand, edit field mappings
• View sync activity and problems → replay and dismiss failed documents
• View log