11. Gestion des Paiements des Salaires et Avances et Claims
par ORIAC

• Définition:

Il s'agit des opérations permettant de procéder à la mise à jour automatique des comptes de trésorerie de la comptabilité ainsi que, le cas échéant, au paiement du Personnel par l'intermédiaire des supports magnétiques habituels.

Nous allons distinguer trois procédures différentes: les paiements des salaires, les paiements des avances et claims et l'enregistrement des paiements des avances et claims déjà payés par une autre méthode. Pour les deux premières procédures, les paiements seront générés par l'intermédiaire des supports magnétiques habituels en utilisant le standard bancaire suisse DTA et la trésorerie de la comptabilité sera mise à jour automatiquement. Pour la troisième procédure, aucun paiement ne sera bien entendu généré mais la trésorerie de la comptabilité sera mise à jour automatiquement.

Chacune des procédures se déroule en plusieurs phases qui correspondent à des transactions. Les phases doivent s'enchaîner dans un ordre déterminé qu'il est obligatoire de respecter. Des mnémoniques spéciaux pour le CERN ont été définis de manière à avoir des écrans préremplis à disposition. Etant donné que certaines transactions ne produisent pas de listing, il conviendra de surveiller attentivement qu'aucun message anormal (comme par exemple: "erreur dans l'exécution de...") n'apparaisse à l'écran durant le déroulement du traitement.

11.1. Gestion des paiements des salaires:

Mnémoniques CERN disponibles

1. TECTSAL

2. T1VASAL

3. TLSPSAL

4. TGEFSAL

5. T1VAPER

6. TRMBSAL

7. NTDTASAL

8. NEDTAPER

9. NTVMADTA

1. Transaction TECTSAL

La transaction TECTSAL procède au transfert des écritures de paie en comptabilité et assure la validation de ces écritures par rapport aux adresses de paiement et aux domiciliations bancaires. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TECTSAL est relançable.

Uniquement en cas d'anomalie, un listing est édité à l'issue du traitement. Dans ce cas, ce listing indique les rejets à traiter. (Actuellement, seuls les rejets comportant un numero d'écriture commençant par 5 concernent l'application Salaires.)

A titre d'information, le journal contenant les écritures à transférer en comptabilité, se nomme PAYE.

2. Transaction T1VASAL

La transaction T1VASAL procède à la validation comptable (première partie) des écritures de paie. Aucune zone n'est à remplir dans l'écran de soumission. La transaction T1VASAL est relançable. Un listing d'une page est édité à l'issue du traitement indiquant le nombre d'écritures validées. Il n'y a pas de vérification à effectuer.

3. Transaction TLSPSAL

C'est la constitution de la liste des pièces[1] correspondant aux salaires à payer. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TLSPSAL est relançable.

Un listing d'une page est édité à l'issue du traitement où il faut impérativement vérifier la correspondance entre:

- le total général à payer édité et le montant net édité à la fin du bordereau de paiement GIP des salaires CERN.

- le nombre d'éléments de liste créés édité et le nombre d'écritures édité à la fin du bordereau de paiement GIP des salaires CERN.

Si le nombre d'éléments de liste créés édité est zéro, il est probable que le transfert des données entre le système de paie et Oriac ne se soit pas correctement effectué. Dans ce cas, et après confirmation du transfert de données, il convient de recommencer à la transaction TECTSAL (point 1).

Si le total général à payer édité est non-nul et différent du montant net à payer édité à la fin du bordereau de paiement GIP des salaires CERN, il est probable que certains rejets apparus au cours des points précédents n'ont pas été correctement traités.

A titre d'information, seules les pièces de type FS (Facture Salaire) et comportant le mode règlement DTA sont sélectionnées par ce traitement. La liste de pièces créée se nomme DTASAL.

4. Transaction TGEFSAL

La transaction TGEFSAL procède à la création des pièces de règlement groupées dans une nouvelle liste de pièces, à leur lettrage avec les pièces à régler (factures salaires), à la création des écritures de trésorerie sur le journal de banque correspondant. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TGEFSAL n'est pas relançable. Aucun listing n'est édité à l'issue du traitement.

A titre d'information, les pièces de règlement créées sont de type PS (Paiement Salaires et Claims). La création des écritures de trésorerie se fait sur le journal de banque PERSBS. La liste de pièces créée se nomme SDTA.

5. Transaction T1VAPER

La transaction T1VAPER procède à la validation comptable (première partie) des écritures de trésorerie créées par la transaction précédente. Aucune zone n'est à remplir dans l'écran de soumission. La transaction T1VAPER est relançable.

Un listing d'une page est édité à l'issue du traitement où, en principe, le nombre d'écritures validées édité et le nombre d'écritures édité à la fin du bordereau de paiement GIP des salaires CERN doivent correspondre, à moins que le traitement de validation générale lancé systématiquement à l'heure du midi ainsi que le soir n'ait déjà validé les écritures en question.

6. Transaction TRMBSAL

La transaction TRMBSAL permet de constituer une remise en banque pour une liste de pièces de règlement. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TRMBSAL n'est pas relançable. Aucun listing n'est édité à l'issue du traitement.

7. Transaction NTDTASAL

La transaction NTDTASAL permet de générer un fichier DTA-Salaires.

Attention, une seule zone très importante est à remplir dans l'écran de soumission, sans possibilité de relance (sauf en cas d'anomalie): il s'agit de la zone "Date de traitement souhaitee" qui doit absolument être remplie à la date de valeur à laquelle les salaires doivent être crédités (= jour de paie). Attention, il est impératif que cette date ne coïncide pas avec la date de traitement souhaitée d'un autre fichier DTA (salaires ou avances et claims).

Un listing est édité à l'issue du traitement où figure le numero d'ordre DTA attribué, lequel doit être retenu impérativement car il est ensuite utilisé dans les transactions NEDTAPER (point 8) et NTVMADTA (point 9). Ce numero d'ordre a la forme aaaammnnnn (ex : 1994070001).

Si ce listing présente une ou plusieurs anomalies indiquées par un message d'erreur (comme par exemple: La domiciliation ne correspond pas à un DTA), le batch est alors rejeté en totalité et, il convient, avant de relancer la transaction NTDTASAL, de vérifier et corriger (au moyen de la transaction GTIDC), pour chaque anomalie, les informations de la domiciliation bancaire notamment l'exactitude du numero de compte en banque et la présence de la valeur D dans le genre.

La zone à remplir est la suivante:

• Date de traitement souhaitée

Saisir la date sous la forme jj-mm-aaaa.

8. Transaction NEDTAPER :

La transaction NEDTAPER permet l'édition du bordereau d'accompagnement DTA. Deux zones sont à remplir dans l'écran de soumission: il s'agit du numero d'ordre DTA attribué par la transaction NTDTASAL (point 7) (format: aaaammnnnn), et de la date d'exécution désirée correspondant à la date de traitement souhaitée, saisie dans l'écran de soumission de la transaction NTDTASAL (point 7). La transaction NEDTAPER est relançable.

Un bordereau d'une page est édité à l'issue du traitement où il faut impérativement vérifier la correspondance entre le montant total à payer édité (tout en contrôlant que la devise associée est bien CHF) et le montant net édité à la fin du bordereau de paiement GIP des salaires CERN. Ce bordereau est à envoyer à la banque muni des signatures autorisées.

Les zones à remplir sont les suivantes :

• Numéro d'ordre

Saisir le numero d'ordre DTA attribué par la transaction NTDTASAL

(point 7) (format: aaaammnnnn).

• Date d'exécution désirée

Par défaut la date du jour, peut-être modifiée. Elle doit correspondre à la date de traitement souhaitée, saisie dans l'écran de soumission de la transaction NTDTASAL (point 7).

9. Transaction NTVMADTA

La transaction NTVMADTA permet de générer un fichier magnétique DTA à partir du fichier produit par la transaction NTDTASAL. Une seule zone est à remplir dans l'écran de soumission: il s'agit du numero d'ordre DTA attribué par la transaction NTDTASAL (format: aaaammnnnn).

La zone à remplir est la suivante:

• Numéro d'ordre

Saisir le numéro d'ordre DTA attribué par la transaction précédente (format: aaaammnnnn).

Le deuxième écran de soumission , où figurent l'imprimante et le format etc., apparaît. Pour générer la bande magnétique il est impératif de contrôler que la zone Imprimante est remplie avec TAPE et que la zone Format est remplie avec MAGNETIQUE. Si ce n'est pas le cas, il faudra saisir ces valeurs.

Ensuite, il faut prendre contact avec AS-MI afin que la bande magnétique soit générée et remise à FI-F-CP. Cette bande magnétique doit ensuite être envoyée au centre de calcul des banques en utilisant la même procédure que pour les paiements aux fournisseurs.

11.2. Gestion des paiements des avances et claims

Mnémoniques CERN disponibles

1. TECTCLM

2. T1VACLM

3. TPITCLM

4. TLSPDCLM

5. TGEFDCLM

6. T1VAPER

7. TRMBDCLM

8. NTDTACLM

9. NEDTAPER

10. NTVMADTA

1. Transaction TECTCLM

La transaction TECTCLM procède au transfert des écritures d'avances et claims en comptabilité et assure la validation de ces écritures par rapport aux adresses de paiement et aux domiciliations bancaires. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TECTCLM est relançable.

Uniquement en cas d'anomalie, un listing est édité à l'issue du traitement. Dans ce cas, ce listing indique les rejets à traiter. (Actuellement, seuls les rejets comportant un numero d'écriture commençant par 4 concernent l'application Avances et Claims, parmi lesquels seuls ceux se rapportant à la Gestion des Paiements des Avances et Claims 10.2 doivent être immédiatement traités.)

A titre d'information, le journal contenant les écritures à transférer en comptabilité, se nomme PAYCL.

2. Transaction T1VACLM

La transaction T1VACLM procède à la validation comptable (première partie) des écritures d'avances et claims. Aucune zone n'est à remplir dans l'écran de soumission. La transaction T1VACLM est relançable. Un listing d'une page est édité à l'issue du traitement indiquant le nombre d'écritures validées. Il n'y a pas de vérification à effectuer.

3. Transaction TPITCLM

La transaction TPITCLM permet d'effectuer automatiquement le rapprochement entre les pièces de claims et les pièces d'avancescorrespondantes afin que les avances soient bien déduites des claims au moment du paiement. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TPITCLM est relançable.

Uniquement en cas d'anomalie, un listing est édité à l'issue du traitement. Dans ce cas, ce listing indique les rejets à traiter. La transaction TPITCLM n'édite que les rejets concernant l'application Avances et Claims, parmi lesquels seuls ceux se rapportant à la Gestion des Paiements des Avances et Claims 10.2 doivent être immédiatement traités.

Il est à remarquer que la transaction GPIE permet d'effectuer manuellement le même rapprochement. Le lecteur est invité à se référer au chapitre 3 du manuel d'utilisation Oriac (Gestion des pièces et de leurs associations).

Dans le cas de rapprochements manuels, pour chaque avance figurant sur le bordereau A.V.C.L. CERN, il faut d'abord interroger la pièce correspondant au claim, puis utiliser le rapprochement assisté (GPIE blocs 3 et 4) pour effectuer manuellement le rapprochement par rapport à la pièce d'avance correspondante, et ce, pour le montant de cette avance.

Par ailleurs, la transaction GPIE permet également, de modifier le libellé qui figurera sur l'avis de crédit du bénéficiaire, édité par la banque. Il suffit de modifier le contenu de la zone "Informations" située au bas de l'écran GPIE. Il est possible de faire défiler cette zone afin d'accéder aux 4 segments de 35 caractères correspondant aux 4 lignes qui figureront sur l'avis de crédit. (Cette modification peut être faite juste avant la transaction NTDTACLM (point 8)).

4. Transaction TLSPDCLM

C'est la constitution de la liste des pièces¹ correspondant aux claims à payer. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TLSPDCLM est relançable.

Un listing d'une page est édité à l'issue du traitement où il faut impérativement vérifier la correspondance entre:

- le total général à payer édité et le montant net à payer édité à la fin du bordereau A.V.C.L. CERN.

- le nombre d'éléments de liste créés édité et le nombre d'écritures édité à la fin du bordereau A.V.C.L. CERN.

Si le nombre d'éléments de liste créés édité est zéro, il est probable que le transfert des données entre le système d'avances et claims et Oriac ne se soit pas correctement effectué. Dans ce cas, et après confirmation du transfert de données, il convient de recommencer à la transaction TECTCLM (point 1).

Si le total général à payer édité est non-nul et différent du montant net à payer édité à la fin du bordereau A.V.C.L. CERN, il est probable que certains rejets apparus au cours des points précédents n'ont pas été correctement traités.

A titre d'information, seules les pièces de type FL (Facture Claim) et comportant le mode règlement DTA sont sélectionnées par ce traitement. La liste de pièces créée se nomme DTACLM.

5. Transaction TGEFDCLM

La transaction TGEFDCLM procède à la création des pièces de règlement groupées dans une nouvelle liste de pièces, à leur lettrage avec les pièces à régler (factures claims), à la création des écritures de trésorerie sur le journal de banque correspondant. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TGEFDCLM n'est pas relançable. Aucun listing n'est édité à l'issue du traitement.

A titre d'information, les pièces de règlement créées sont de type PS (Paiement Salaires et Claims). La création des écritures de trésorerie se fait sur le journal de banque PERSBS. La liste de pièces créée se nomme LDTA.

6. Transaction T1VAPER

La transaction T1VAPER procède à la validation comptable (première partie) des écritures de trésorerie créées par la transaction précédente. Aucune zone n'est à remplir dans l'écran de soumission. La transaction T1VAPER est relançable.

Un listing d'une page est édité à l'issue du traitement où, en principe, le nombre d'écritures validées édité et le nombre d'écritures édité à la fin du borderau A.V.C.L. CERN doivent correspondre, à moins que le traitement de validation générale lancé systématiquement à l'heure du midi ainsi que le soir n'ait déjà validé les écritures en question.

7. Transaction TRMBDCLM

La transaction TRMBDCLM permet de constituer une remise en banque pour une liste de pièces de règlement. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TRMBDCLM n'est pas relançable.

Aucun listing n'est édité à l'issue du traitement.

8. Transaction NTDTACLM

La transaction NTDTACLM permet de générer un fichier DTA normal c'est à dire avec édition de la part de la banque d'un avis de crédit pour chaque bénéficiaire.

Attention, une seule zone très importante est à remplir dans l'écran de soumission, sans possibilité de relance (sauf en cas d'anomalie): il s'agit de la zone "Date de traitement souhaitée" qui doit absolument être remplie à la date de valeur à laquelle les claims doivent être crédités. Attention, il est impératif que cette date ne coïncide pas avec la date de traitement souhaitée d'un autre fichier DTA (salaires ou avances et claims).

Un listing est édité à l'issue du traitement où figure le numero d'ordre DTA attribué, lequel doit être retenu impérativement car il est ensuite utilisé dans les transactions NEDTAPER (point 9) et NTVMADTA (point 10). Ce numero d'ordre a la forme aaaammnnnn (ex : 1992070001).

Si ce listing présente une ou plusieurs anomalies indiquées par un message d'erreur (comme par exemple: La domiciliation ne correspond pas à un DTA), le batch est alors rejeté en totalité et, il convient, avant de relancer la transaction NTDTACLM, de vérifier et corriger (au moyen de la transaction GTIDC), pour chaque anomalie, les informations de la domiciliation bancaire notamment l'exactitude du numero de compte en banque et la présence de la valeur D dans le genre.

La zone à remplir est la suivante:

• Date de traitement souhaitée

Saisir la date sous la forme jj-mm-aaaa.

9. Transaction NEDTAPER

La transaction NEDTAPER permet l'édition du bordereau d'accompagnement DTA. Deux zones sont à remplir dans l'écran de soumission: il s'agit du numero d'ordre DTA attribué par la transaction NTDTACLM (point 8) (format: aaaammnnnn), et de la date d'exécution désirée correspondant à la date de traitement souhaitée, saisie dans l'écran de soumission de la transaction NTDTACLM (point 8). La transaction NEDTAPER est relançable.

Un bordereau d'une page est édité à l'issue du traitement où il faut impérativement vérifier la correspondance entre le montant total à payer édité (tout en contrôlant que la devise associée est bien CHF) et le montant net édité à la fin du borderau A.V.C.L. CERN. Ce bordereau est à envoyer à la banque muni des signatures autorisées.

10. Transaction NTVMADTA :

La transaction NTVMADTA permet de générer un fichier magnétique DTA à partir du fichier produit par la transaction NTDTACLM. Une seule zone est à remplir dans l'écran de soumission: il s'agit du numero d'ordre DTA attribué par la transaction NTDTACLM (format: aaaammnnnn).

Le deuxième écran de soumission , où figurent l'imprimante et le format etc., apparaît. Pour générer la bande magnétique il est impératif de contrôler que la zone Imprimante est remplie avec TAPE est que la zone Format est remplie avec MAGNETIQUE. Si ce n'est pas le cas il faudra saisir ces valeurs.

Ensuite, il faut prendre contact avec AS-SU afin que la bande magnétique soit générée et remise à FI-F-CP. Cette bande magnétique doit ensuite être envoyée au centre de calcul des banques en utilisant la même procédure que pour les paiements aux fournisseurs.

11.3. Gestion de l'enregistrement des Paiements des Avances et Claims

Mnémoniques CERN disponibles

1. TECTCLM

2. T1VACLM

3. TPITCLM

4. TLSPMCLM

5. TGEFMCLM

1. Transaction TECTCLM

La transaction TECTCLM procède au transfert des écritures d'avances et claims en comptabilité et assure la validation de ces écritures par rapport aux adresses de paiement et aux domiciliations bancaires. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TECTCLM est relançable.

Uniquement en cas d'anomalie, un listing est édité à l'issue du traitement. Dans ce cas, ce listing indique les rejets à traiter. (Actuellement, seuls les rejets comportant un numero d'écriture commençant par 4 concernent l'application Avances et Claims.)

A titre d'information, le journal contenant les écritures à transférer en comptabilité, se nomme PAYCL.

2. Transaction T1VACLM

La transaction T1VACLM procède à la validation comptable (première partie) des écritures d'avances et claims. Aucune zone n'est à remplir dans l'écran de soumission. La transaction T1VACLM est relançable. Un listing d'une page est édité à l'issue du traitement indiquant le nombre d'écritures validées. Il n'y a pas de vérification à effectuer.

3. Transaction TPITCLM

La transaction TPITCLM permet d'effectuer automatiquement le rapprochement entre les pièces de claims et les pièces d'avances correspondantes afin que les avances soient bien déduites des claims pour l'enregistrement du paiement. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TPITCLM est relançable.

Uniquement en cas d'anomalie, un listing est édité à l'issue du traitement. Dans ce cas, ce listing indique les rejets à traiter. La transaction TPITCLM n'édite que les rejets concernant l'application Avances et Claims.

Il est à remarquer que la transaction GPIE permet d'effectuer manuellement le même rapprochement. Le lecteur est invité à se référer au chapître 3 du manuel d'utilisation Oriac (Gestion des pièces et de leurs associations).

Dans le cas de rapprochements manuels, pour chaque avance figurant sur le bordereau A.V.C.L. CERN, il faut d'abord interroger la pièce correspondant au claim, puis utiliser le rapprochement assisté (GPIE blocs 3 et 4) pour effectuer manuellement le rapprochement par rapport à la pièce d'avance correspondante, et ce, pour le montant de cette avance.

4. Transaction TLSPMCLM

C'est la constitution de la liste des pièces[2] correspondant aux claims à enregistrer. Aucune zone n'est à remplir dans l'écran de soumission, sauf s'il on désire travailler au niveau du batch AVCL. Dans ce cas, il convient de préciser une fourchette de bordereaux et/ou de banques. La transaction TLSPMCLM est relançable.

Un listing d'une page est édité à l'issue du traitement où il faut impérativement vérifier la correspondance entre:

- le total général à enregistrer édité et le montant net à payer édité à la fin du bordereau A.V.C.L. CERN.

- le nombre d'éléments de liste créés édité et le nombre d'écritures édité à la fin du bordereau A.V.C.L. CERN.

Si le nombre d'éléments de liste créés édité est zéro, il est probable que le transfert des données entre le système d'avances et claims et Oriac ne se soit pas correctement effectué. Dans ce cas, et après confirmation du transfert de données, il convient de recommencer à la transaction TECTCLM (point 1).

Si le total général à enregistrer édité est non-nul et différent du montant net à payer édité à la fin du bordereau A.V.C.L. CERN, il est probable que certains rejets apparus au cours des points précédents n'ont pas été correctement traités.

A titre d'information, seules les pièces de type FL (Facture Claim) et comportant le mode règlement MANUEL sont sélectionnées par ce traitement. La liste de pièces créée se nomme MANUCLM.

Les zones à remplir éventuellement sont les suivantes :

• Bordx

Saisir la fourchette de numeros de bordereaux (format: aammxy où x est le numero de semaine et y le numero de passage).

• Banques

Saisir la fourchette de banques (PER, SSP, SDP, SDD, SDE, CAI, SCC ou CCP).

5. Transaction TGEFMCLM

La transaction TGEFMCLMprocède à la création des pièces de règlement et à leur lettrage avec les pièces à régler (factures claims), ainsi qu'à la création des écritures de trésorerie sur les journaux de banque correspondants. Aucune zone n'est à remplir dans l'écran de soumission. La transaction TGEFMCLM n'est pas relançable. Aucun listing n'est édité à l'issue du traitement.

A titre d'information, les pièces de règlement créées sont de type PS (Paiement Salaires et Claims). La création des écritures de trésorerie se fait sur les journaux de banque PERSBS, SSPSBS, SDPSBS, SDDSBS, SDESBS, CAISSE, SCCSBS et CCPCHF.

La validation comptable (première partie) des écritures de trésorerie créées sera effectuée par le traitement de validation générale lancé systématiquement à l'heure du midi ainsi que le soir.