Cegid-side prerequisites

Prepare Cegid Retail Y2 for The Wallet Crew with service access, chronos, loyalty campaigns, reference data, and request capacity.

A Cegid Retail Y2 integration depends on Cegid access, reference data, and capacity being ready before connector configuration starts. This page gives the Cegid administrator one preparation checklist.

Real-world examples

• A new store opens, its chrono is active but nearly exhausted, and enrolment fails at the till on the second day of trading.

• Two country rows share the ISO-2 code of one market, and every enrolment from that market fails until the duplicate is removed in Cegid.

• A service-account password expires under a routine security policy, and every store stops enrolling simultaneously.

A dedicated web-service user

The connector authenticates to Y2 as a named Cegid user. That account should be created for The Wallet Crew rather than reused from another integration, and granted only the web-service permissions and data access the intended wallet journeys require. Cegid Retail Y2 APIs lists the services involved, so permissions can be scoped precisely.

Two properties of the account matter more than they appear to. Its password must not expire, or the connector stops working without warning on a date nobody has recorded. Where the Cegid policy permits, the account should be exempted from expiry; otherwise the expiry date has to be tracked and the connector updated before it passes. And the stores the account is attached to determine which customers it can see, and which store a newly created customer is attributed to.

Chronos with headroom

Cegid uses counters, referred to as chronos, to allocate identifiers for new records. Every store whose customers the connector will create needs an active chrono, but activation alone is not sufficient. A chrono has a finite range, and a store that has consumed its range stops issuing identifiers.

An exhausted counter surfaces as a Cegid WP006 fault, reported as a failure to generate a customer code automatically. It is one of the most frequent errors in production, and it is not a Wallet Crew fault: the remedy is to extend the chrono range in Cegid. Checking the remaining range at setup, rather than after the first failure, avoids an outage at the till.

Loyalty programme membership

Where the wallet programme issues loyalty cards, every store that will create them must belong to the relevant Cegid loyalty campaign. A store that is absent from the campaign cannot have cards created against it, and the connector reports that no loyalty campaign could be found.

Clean reference data

The connector maps countries between Cegid's own identifiers and ISO codes. That mapping assumes the Cegid reference tables are unambiguous, and in practice they frequently are not. Duplicated country rows sharing one ISO-2 code, or nationality entries pointing at the wrong territory, are common and long-standing.

These defects surface as errors on enrolment, and they cannot be corrected from The Wallet Crew. The reference table has to be de-duplicated in Cegid. Reviewing the country and nationality tables before go-live is considerably cheaper than diagnosing the resulting errors afterwards.

Request capacity

Cegid applies a ceiling on the number of web-service requests an environment may make in a rolling window. That capacity is shared with every other application calling the same Cegid environment, not reserved for The Wallet Crew.

Before go-live, the Cegid administrator should confirm which plan the environment is on and how much of its capacity other integrations already consume. The remainder is what should be configured as the connector's limit, as described in Advanced configuration.

Checklist

Item	Owner	Verified by
Dedicated Y2 web-service user created, with the required permissions	Cegid administrator	Connection test in the admin console
Password expiry disabled, or expiry date recorded	Cegid administrator	Cegid user policy
Chrono active on every enrolling store, with range remaining	Cegid administrator	Cegid counter configuration
Every enrolling store present in the loyalty campaign	Brand, with Cegid	A test loyalty card creation
Country and nationality reference tables free of duplicates	Cegid administrator	A test enrolment per market
Request capacity confirmed and apportioned	Cegid administrator	Cegid plan documentation

FAQ

Can one web-service user serve every store?

It can, and most brands run exactly that way. A separate user per store is needed only where stores must be distinguished by the credentials used. Connections and stores explains what that changes and what it costs to maintain.

Does the connector work with Cegid Retail Y2 on-premise?

Yes, provided The Wallet Crew can reach the required Y2 web services over the network.

What happens if a chrono runs out after go-live?

Enrolment at that store fails until the range is extended in Cegid. Customers already enrolled are unaffected, and no data is lost; the store simply cannot create new records in the meantime.