> 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/events-and-operations/operations-runbooks.md).

# Operations runbooks

Operate a Cegid Retail Y2 integration through store openings, credential rotation, store closure, decommissioning, and configuration reviews.

Use these operational procedures throughout a live Cegid Retail Y2 integration. They cover store openings, credentials, closures, decommissioning, and regular configuration reviews.

### Open a new store

The procedure differs depending on whether the brand runs a single connection or one per store. With a single connection, a new store usually needs no connector change at all, only the Cegid-side prerequisites. With per-store credentials, the steps below apply.

{% stepper %}
{% step %}

#### Prepare the store in Cegid

Create the store, activate its counter with sufficient range, add it to the loyalty campaign where loyalty cards are issued, and create its web-service user.
{% endstep %}

{% step %}

#### Create the store record

In the administration console, create the store record.
{% endstep %}

{% step %}

#### Add the connection

On the Cegid configuration page, add a connection **named exactly as the store identifier**, and enter the store's own user name and password. Copy the receipt settings from an existing store so behaviour is consistent.
{% endstep %}

{% step %}

#### Verify the connection

Run the configuration test and confirm the new connection reports success.
{% endstep %}

{% step %}

#### Validate with a test customer

Enrol a test customer at the store and confirm in Cegid that the record carries the expected store and identifier prefix.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
The last step is the one most often skipped, and it is what catches a connection whose name does not match the store identifier. Without it the enrolment still succeeds, against the default connection, and the misconfiguration is discovered weeks later in reporting.
{% endhint %}

### Rotate credentials

Where a Cegid password changes, the connector stops working for the affected stores immediately and silently. The failure appears as rejected authentication at the point of enrolment, not as a configuration warning.

1. Update the password on each affected connection.
2. Run the configuration test and confirm every connection reports success.
3. Where the account is subject to expiry, record the next expiry date somewhere it will be seen.

### Close a store

1. Remove the store's connection from the configuration. Leaving it produces persistent test failures that mask real ones.
2. Where the store had its own Cegid user, disable it in Cegid.
3. Note that passes created while the store was trading continue to report it, since store attribution is recorded at creation and not revised.

### Decommission a tenant

Removing a Wallet Crew tenant does not stop Cegid sending business notifications to it. The subscription lives in Cegid and has to be removed there, or it will continue delivering to an endpoint that no longer serves a purpose.

1. Remove or repoint the business notification subscription in Cegid.
2. Disable the Cegid web-service users created for the integration.

### Copy a configuration between tenants

Creating a new tenant from an existing one carries the whole Cegid configuration across, including credentials, connection names, mapping scripts, and identifiers that belonged to the original brand. Each has to be reviewed deliberately rather than assumed to be inert.

1. Replace every connection's credentials and database identifier.
2. Confirm connection names match the new brand's store identifiers.
3. Review the mapping script. Free-field slots and language codes are specific to a Cegid database and will not transfer.
4. Run the configuration test before enabling any enrolment flow.

### Review an existing configuration

A periodic review catches the drift that accumulates in long-lived configurations. The checks worth making:

* Exactly one connection is marked as the default.
* No connection points at a Cegid test environment.
* Every connection's store identifier corresponds to a trading store.
* Receipt settings are consistent across connections.
* No retired connections remain, commented out or otherwise.
* Rate limit and cache settings still reflect the brand's share of Cegid capacity.
* The mapping script contains no dead code or commented-out duplicates.

### FAQ

<details>

<summary><strong>How long does opening a store take?</strong></summary>

The Wallet Crew side is a few minutes once the Cegid side is ready. The Cegid preparation — counter, loyalty campaign, web-service user — is the part worth scheduling in advance of the opening date.

</details>

<details>

<summary><strong>Can a store be added without its own credentials?</strong></summary>

Yes, where a single connection serves the estate. The store still needs its Cegid-side prerequisites, but no connector change is required.

</details>


---

# 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/events-and-operations/operations-runbooks.md?ask=<question>&goal=<user_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.