> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/connectors/pos/cegid/setup-and-configuration/cegid-side-prerequisites.md).
# 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](/connectors/pos/cegid/developer-reference/cegid-retail-y2-apis.md) 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.
{% hint style="warning" %}
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.
{% endhint %}
### 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](/connectors/pos/cegid/setup-and-configuration/advanced-configuration.md).
### 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](/connectors/pos/cegid/setup-and-configuration/connections-and-stores.md) 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.thewalletcrew.io/connectors/pos/cegid/setup-and-configuration/cegid-side-prerequisites.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.