Correction rapide :ORA-20122 … Field [X] may not be modifiedsignifie que le champ est insertable mais pas modifiable via l'API. Vous ne voulez probablement même pas le modifier — il est juste présent dans le mapping. Ouvrez Method List → Method List Attribute, et décochez « On Modify » pour la colonne concernée et sa jumelle_DB(ex.CATALOG_TYPEetCATALOG_TYPE_DB). Relancez : l'update passe.
Vous lancez un job de migration pour mettre à jour un champ simple — par exemple le prix de vente dans SALES_PART. Et chaque ligne renvoie :
ORA-20122 : SalesPart.UPDATE : Field [CATALOG_TYPE] in Sales Part may not be modified.
Le plus absurde en apparence : vous ne cherchez pas à modifier CATALOG_TYPE. Vous voulez juste changer le prix. Alors pourquoi ce blocage ?
Le symptôme
L'erreur survient à l'exécution (MIGRATE_SOURCE_DATA) d'un job en mise à jour, sur toutes les lignes, avec le motif :
ORA-20122: SalesPart.UPDATE: Field [CATALOG_TYPE] in Sales Part may not be modified. The value of [CATALOG_TYPE] is 'NON'.
Le nom du champ varie selon la vue, mais c'est toujours un champ figé après l'insertion : type de catalogue, type d'objet, classification… des attributs structurants qu'IFS interdit de changer une fois l'enregistrement créé.
La cause
C'est un grand classique des colonnes client / _DB dans les jobs de migration.
Certains champs IFS sont insertables mais non modifiables (insert-only) : on les fixe à la création, l'API refuse ensuite tout update dessus. Or, par défaut, le job de migration envoie toutes les colonnes mappées lors d'un update — y compris celles dont la valeur n'a pas changé. IFS voit arriver CATALOG_TYPE dans un ordre de modification → rejet ORA-20122, même si la valeur est identique.
Confirmé par la communauté IFS : « le champ CATALOG_TYPE est insertable mais non modifiable — il faut s'assurer que la case On Modify n'est pas cochée pour CATALOG_TYPE et CATALOG_TYPE_DB. » Un consultant note que ce problème « hante les jobs de migration depuis toujours, d'APPS10 au Cloud ».
Comment corriger
Trois clics, dans le job de migration :
- Ouvrez l'onglet Method List, clic droit sur la méthode → Method List Attribute.
- Cherchez la colonne citée dans l'erreur et sa jumelle :
CATALOG_TYPEetCATALOG_TYPE_DB. - Décochez « On Modify » (mettez-le à False / No) pour les deux colonnes.
- Relancez le job : le champ verrouillé n'est plus envoyé à l'update, et votre vraie modification (le prix) passe.
(Solution validée par la communauté IFS — identique en APPS10 et IFS Cloud.)
La règle à retenir sur les colonnes client / _DB
Les colonnes jumelles (CATALOG_TYPE / CATALOG_TYPE_DB) doivent toujours avoir les mêmes réglages On New / On Modify. En décocher une et pas l'autre = comportement imprévisible. Les exceptions documentées sont rares (clé client/_DB en doublon → flag - sur la colonne client, voir notre article ORA-20112).
Comment l'éviter
- Avant un job de mise à jour, passez en revue la Method List Attribute : repérez les champs structurants (types, classifications) et décochez On Modify dessus d'emblée.
- Ne mappez dans la source que les colonnes que vous voulez réellement changer + les clés. Chaque colonne mappée en plus est un risque d'
ORA-20122. - Réflexe miroir : si un champ est refusé à l'insertion avec un message similaire (« may not be specified for new objects »,
ORA-20121), c'est le même mécanisme côté On New.
Erreurs de migration IFS liées
Le même type de blocage se joue sur d'autres codes — tous décortiqués dans notre guide pilier Migration de données IFS Cloud:
- ORA-20112 FND_RECORD_EXIST — le job tente d'INSÉRER une ligne qui existe déjà (problème de clé, flags P/K).
- ORA-20111 / FND_RECORD_NOT_EXIST — un prérequis contextuel manquant (charger les parents avant les enfants).
- ORA-20110 — une règle métier violée (donnée hors plage, paramétrage manquant).
- SE_UNAUTHORIZED — la projection du job non accordée à l'exécutant : un problème de permissions de migration .
Pour la gestion des imports/exports, voir aussi la page Import / Export Excel IFS page.
Mettre à jour ses données sans connaître les flags par cœur
ORA-20122 illustre la mécanique interne des jobs IFS : pour réussir un simple update de prix, il faut connaître les colonnes client/_DB, les flags On New / On Modify et les champs insert-only de chaque vue. ERP Control évite cette gymnastique : il fait de vrais updates ciblés (PATCH via l'API OData) qui n'envoient que les champs modifiés — les champs verrouillés ne sont jamais touchés, donc jamais rejetés. En no-code, sans Method List ni PL/SQL, et de façon cohérente sur vos environnements CFG · UAT · TRN · PROD.
Découvrez comment ERP Control simplifie les migrations IFS Cloud — voir le module migrationFait partie de notre guide pilier :
Migration de données IFS Cloud — le guide complet 2026 Migration de données IFS Cloud — le guide complet 2026Fait partie de notre guide pilier :
FAQ
Je ne modifie pas ce champ, pourquoi IFS me le reproche ?
Parce que le job envoie toutes les colonnes mappées lors de l'update, même inchangées. IFS voit le champ dans l'ordre de modification et le rejette. Décochez « On Modify » pour l'exclure de l'update.
Faut-il décocher On Modify sur la colonne client, la colonne _DB, ou les deux ?
Les deux. Les colonnes jumelles client/_DB doivent toujours porter les mêmes réglages On New / On Modify.
Et si je dois vraiment changer la valeur d'un champ « may not be modified » ?
Via l'API standard, c'est impossible : le champ est figé à l'insertion. Selon le cas, il faut supprimer/recréer l'enregistrement, ou passer par la procédure métier prévue par IFS (quand elle existe). Vérifiez d'abord si la valeur cible justifie vraiment l'opération.
Sources
Cas réel issu de la communauté IFS (solution validée sur le thread) :