> ## Documentation Index
> Fetch the complete documentation index at: https://docs.solya.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Spécifications d'ingestion — détection

> Chaque type de règle de détection, comment les modes de correspondance les combinent, et comment une spécification est sélectionnée pour un fichier entrant.

La **détection** décide quelle spécification s'applique à un fichier entrant. C'est un `match_mode` plus une liste de `rules`.

```json theme={null}
"detection": {
  "match_mode": "composite",
  "rules": [
    { "type": "data_source", "codes": ["pos_polaris"] },
    { "type": "filename_matches", "pattern": "(?i)\\.sav$" }
  ]
}
```

## Modes de correspondance

| Mode        | Logique                                                                                          |
| ----------- | ------------------------------------------------------------------------------------------------ |
| `any`       | Au moins une règle correspond (OR).                                                              |
| `all`       | Chaque règle correspond (AND).                                                                   |
| `composite` | Combinaison personnalisée (typiquement une porte data-source ET un test nom de fichier/en-tête). |

## Types de règles

| Type               | Champ                 | Signification                                                                                                   |
| ------------------ | --------------------- | --------------------------------------------------------------------------------------------------------------- |
| `data_source`      | `codes` (string\[])   | Restreindre la spécification aux fichiers provenant de systèmes sources spécifiques.                            |
| `filename`         | `pattern` (string)    | Correspondance exacte du nom de fichier.                                                                        |
| `filename_matches` | `pattern` (regex)     | Le nom de fichier correspond à une expression régulière (ex. `"(?i)tickets"` — `(?i)` = insensible à la casse). |
| `columns`          | `columns` (string\[]) | Les colonnes du fichier doivent correspondre exactement à cette liste.                                          |
| `header_contains`  | `columns` (string\[]) | La ligne d'en-tête doit contenir **toutes** ces colonnes (sous-ensemble, ordre indépendant).                    |
| `sheet_name`       | `pattern` (string)    | Un nom de feuille Excel correspond exactement.                                                                  |

### Codes `data_source`

Le tableau `codes` utilise les identifiants de source de données canoniques, incluant :

```
pos_polaris, pos_ginkoia, pos_fastmag, pos_kezia, pos_lcv, pos_cegid,
pos_openbravo, pos_oracle, pos_sage, ecommerce_api, erp_sap, user_uploads
```

Ces codes sont validés lors du seeding des spécifications — un code inconnu échoue rapidement.

## Un exemple composite

```json theme={null}
"detection": {
  "match_mode": "composite",
  "rules": [
    { "type": "data_source", "codes": ["pos_ginkoia", "user_uploads"] },
    { "type": "filename_matches", "pattern": "(?i)tickets" },
    { "type": "header_contains", "columns": ["Numéro", "Séquence", "Montant", "Mode paiement"] }
  ]
}
```

Se lit comme : *le fichier provient de Ginkoia (ou d'un upload manuel) **et** son nom contient « tickets » **et** son en-tête a les quatre colonnes.*

<Note>
  Quand plusieurs spécifications pourraient correspondre, le gagnant est choisi par `priority` puis `spec_version`
  — voir [Anatomie → priorité](/fr/developers/ingestion-specs/overview#priorité-et-résolution-de-conflits).
</Note>