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.

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 alongside this page.

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.

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.

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.

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.

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.

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.

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.

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.