> 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/connections-and-stores.md).
# Connections and stores
Configure multiple Cegid Retail Y2 connections, route each store to the correct credentials, and maintain multi-store integrations.
The connector can use one Cegid connection or separate connections for individual stores. This page explains when multiple connections are needed, how the connector selects one, and what requires ongoing maintenance.
### When more than one connection is needed
A single connection is sufficient whenever one set of Cegid credentials can see and act on every customer the wallet programme touches. That covers the large majority of implementations, including most multi-market ones, because markets are usually separated by store rather than by credentials.
Several connections become necessary in two situations. The first is genuinely separate Cegid databases: a brand operating distinct Cegid environments for different regions or fascias. The second, and more common in practice, is a single database in which each store has its own web-service user, so that records created by that store carry the store's own identifier prefix and consume that store's counter.
{% hint style="info" %}
Per-store credentials give precise attribution in Cegid, at the cost of a configuration entry per store that has to be created at each opening and maintained through every password change. Brands running estates of this kind should read [Operations runbooks](/connectors/pos/cegid/events-and-operations/operations-runbooks.md) alongside this page.
{% endhint %}
### Add and remove connections
Connections are managed from the connection toolbar at the top of the Cegid configuration page. The picker lists every connection with its database identifier, marking the default. Alongside it are actions to add a connection, delete the selected one, and set it as the default.
A new connection is created pre-filled with the service URL and credentials of the default connection, so that in the common case — a new store in an existing database — only the name and the store's own user name and password need changing.
### How a connection is chosen
When a request concerns a particular store, the connector selects a connection in a fixed order:
1. The connection explicitly bound to that store, if one is configured.
2. A connection whose **name is exactly the store identifier**.
3. The default connection.
```mermaid
flowchart TD
A["Request concerns store 0431"] --> B{"Is a connection explicitly bound to store 0431?"}
B -- Yes --> C["Use the bound connection"]
B -- No --> D{"Is there a connection named exactly 0431?"}
D -- Yes --> E["Use that connection"]
D -- No --> F["Fall back to the default connection"]
F --> G["No error is raised to the operator.
The customer is created with the default
connection's store prefix."]
```
The second rule is the one most estates rely on, and it is the reason connection naming is not cosmetic: naming each connection after its store identifier is what makes store-specific credentials take effect without any further configuration.
{% hint style="warning" %}
Exactly one connection should be marked as the default. Where more than one carries the flag, which one is treated as the default is not defined, and stores that fall through to it may authenticate inconsistently.
{% endhint %}
{% hint style="danger" %}
A store that matches neither of the first two rules falls through to the default connection without an error being raised to the operator. The enrolment succeeds, against the wrong store's credentials, and the resulting customer carries the wrong identifier prefix. When customers appear in Cegid attributed to an unexpected store, an unmatched connection name is the first thing to check.
{% endhint %}
### Binding a store to a named connection
Where a connection cannot be named after the store — because one connection serves several stores, for example — the store can be bound to a named connection explicitly. That binding is set on the store record in the tenant configuration and has no equivalent on the connector page, so it is one of the few settings that requires the configuration workspace described in [Advanced configuration](/connectors/pos/cegid/setup-and-configuration/advanced-configuration.md).
### Store of attachment and store of creation
Cegid distinguishes the store a customer is attached to from the store where the record was created. The connector writes the store of attachment, and reads it back in preference to the store of creation, falling back to creation only where attachment is empty.
The store of creation is set by Cegid itself from the credentials used, which is the mechanism behind identifier prefixes. It cannot be chosen through the web service the connector writes with, so a record created with one store's credentials carries that store's prefix permanently.
{% hint style="warning" %}
Store attribution recorded on a pass reflects the store of attachment at the moment the pass was created, and is not revised afterwards. Where a store closes or a customer transfers, historical passes continue to report the original store.
{% endhint %}
### Patterns to avoid
Three habits recur in long-lived multi-connection configurations, and each causes a characteristic problem.
**Commenting connections in and out** as a way of disabling stores leaves configuration in which live and retired entries are interleaved, and makes a typo in a live entry easy to overlook. Deleting the connection is preferable.
**Retired stores left configured** continue to be tested on every configuration check, producing persistent errors that train operators to ignore the test result.
**Receipt settings applied to some connections only** produce receipts that differ by store without any obvious cause.
### FAQ
Why did a customer get an identifier with the wrong store prefix?
The record was created using credentials belonging to a different store. Either the store has no connection of its own and the request fell through to the default, or the connection name does not exactly match the store identifier.
Can an identifier prefix be corrected after the fact?
Not by The Wallet Crew, because the identifier is assigned by Cegid. Where Cegid re-issues identifiers, the passes can be updated to point at the new ones, given the mapping between old and new.
Is there a limit on the number of connections?
No fixed limit. Estates with several dozen connections run in production. Beyond a handful, the maintenance burden rather than the platform becomes the constraint.
---
# 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/connections-and-stores.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.