Utilisez cette fonction pour définir les caractéristiques de la transaction de règlement et les modes de règlement utilisés par la société :

  • caractéristiques générales : sens (recette ou dépense), mode de règlement (virement, chèque, etc.),
  • écrans de saisie : champs affichés, champs obligatoires,
  • étapes de comptabilisation et modalités de regroupement : remise en banque, mise en portefeuille, éclatement de fichiers bancaires, etc.

Prérequis

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre

Gestion de l'écran


En-tête

Onglet Général

Onglet Saisie

Zones supplémentaires

Il est possible d'ajouter des données en saisie (jusqu'à 30 champs). Ces champs doivent être définis dans l'écran PAY2, et sont optionnellement repris dans les écrans de transaction en fonction des réponses de présence données dans ce tableau.
Ces champs sont, par exemple, liés au code activité KSW - Suisse.

Motif économique

Le code motif économique est utilisé par la Banque de France dans le cadre de l’établissement de la Balance des paiements.
Il est nécessaire pour toute opération entrant dans le cadre suivant :

  • transactions en euro vers une banque de l'Union européenne, y compris la France, pour les comptes de non-résidents et à partir de 50 000 euros,
  • transactions en euro vers une banque située à l'extérieur de l'Union européenne et à partir de 12 500 euros,
  • transactions en devise autre que l'euro vers une banque de l'Union européenne, y compris la France et à partir de 12 500 euros.

SEEINFO La qualité de résident/non-résident est définie au niveau Tiers.
Les seuils déclaratifs sont déterminés par les valeurs paramètres AMTVIR1, AMTVIR2 et AMTVIR3 dans le chapitre Tiers / Valeurs par défaut.

La saisie de ce code et son caractère obligatoire sont déterminés au niveau du paramétrage de la transaction de saisie de règlements.
Si la société à partir de laquelle on constitue le règlement a le statut de déclarant direct général à la balance des paiements, le code 060 ‘Déclarant direct général’ est proposé (paramétrage fiche Société).
Dans le cas contraire, la valeur proposée sera celle définie au niveau du tiers (paramétrage fiche Tiers).
SEEINFO Ce code est modifiable.
Cette valeur est reprise dans les fichiers bancaires (AFB160, AFB320, SEPA Credit Transfer).

Fonctionnement du code motif économique

Si la société est déclarante directe, le code Motif économique '060' doit être renseigné dans la section Compta de la fiche Société.
Ce code est automatiquement appliqué à tout règlement à destination de tiers non résidents généré à partir de cette société.
SEEINFO Ce champ n'est pas alimenté s'il s'agit d'opérations avec des résidents.

Si la société n'est pas déclarante directe, le code motif économique doit être renseigné pour chaque tiers non résident.
En fonction des seuils déclaratifs, il est pris en compte :

SEEINFO Si aucune valeur n'a été renseignée dans la ficheTiers, un code peut être sélectionné directement ensaisie de règlement.
SEEWARNING La saisie est rendue obligatoire si le paramétrage de la transaction desaisie de règlement l'impose.

Onglet Étapes

La section Etapes permet de définir les étapes de comptabilisation propres à la transaction de règlement. L'ordre des étapes est immuable. Si, pour une transaction de règlement, toutes les étapes de comptabilisation sont sélectionnées, chaque traitement doit être complété avant de pouvoir passer à l'étape suivante.

Éclatement de fichiers bancaires

Vous pouvez créer une transaction de règlement dédiée à l’éclatement de fichier bancaire en utilisant les champs de la section Eclatement fichier bancaire. Vous pouvez ensuite utiliser cette transaction pour créer des bordereaux de remise et générer des fichiers bancaires dans les fonctions Saisie bordereau de remise (GESFRM) et Remises magnétiques (FICMAG). Lors de la génération de fichiers bancaires, un ou plusieurs fichiers sont créés selon les données de règlement et les critères d’éclatement renseignés.

L’éclatement de fichier dépend du format du fichier bancaire et doit être évalué. Par exemple, pour effectuer un éclatement par devise, vous devez utiliser un format spécifique prenant en charge le multi-devise (généralement par le biais de plusieurs fichiers séparés par devise).

Cette option n’est pas disponible en création de fichiers EDI.

Comptabilisation intermédiaire

Dernière étape de comptabilisation possible des règlements avant la comptabilisation en banque, une écriture peut être passée sur un compte intermédiaire de remise à l'encaissement ou à l'escompte par exemple.

Cette étape n'est accessible que pour les règlements placés sur un bordereau de remise.

Vous pouvez associer à l'étape de comptabilisation intermédiaire un groupe de pièces automatiques (cf. Groupe de pièces automatiques) : selon qu'il s'agisse de le première étape de comptabilisation ou de la seconde, le groupe de pièce proposé en standard peut être respectivement STEP1 ou STEP N.

Vous pouvez indiquer le journal de comptabilisation de la comptabilisation intermédiaire. Vous pouvez générer des schémas comptables différents suivant que le règlement soit remis à l'encaissement ou à l'escompte. Le journal sélectionné, selon le paramétrage, peut être déterminant pour la recherche du compte intermédiaire. Le type de journal sélectionné est lié à la définition de la Banque.

Un traitement propre vous permet d'effectuer la comptabilisation intermédiaire en masse des règlements sur bordereau.
SEEREFERTTO Se reporter à la documentation sur la Comptabilisation intermédiaire pour plus d'informations.

Comptabilisation en banque

Cette avant-dernière étape est obligatoire pour toutes les transactions de règlements. Elle permet la comptabilisation en banque du règlement.

Vous pouvez associer à l'étape de comptabilisation en banque un groupe de pièce automatique (cf. documentation Groupe de pièces automatiques). Selon qu'il s'agisse de le première étape de comptabilisation ou de la seconde/troisième, le groupe de pièce proposé en standard peut être respectivement  STEP1 ou STEPN.

Les champs Regroupement si encaissement et Regroupement si escompte sont accessibles lorsque la transaction comporte une étape de saisie de bordereau ou de saisie d'avis de domiciliation.
Le code de regroupement vous permet de définir si une écriture est générée selon le type de remise :

  • par règlement (1 règlement, 1 pièce comptable),
  • par bordereau (1 bordereau de remise, 1 pièce comptable),
  • par date d'échéance (1 pièce comptable par date d'échéance).

Le regroupement par échéance ou bordereau n'est possible que si l’option Bordereau de remise est activée.
Si le code édition rattaché au code traitement est "CHE" ou "CHR" (table diverse N° 304), le champ Regroupement si escompte est inaccessible.

Vous devez indiquer ensuite le journal utilisé pour la comptabilisation en banque. Le journal sélectionné, selon le paramétrage, peut être déterminant pour la recherche du compte bancaire. Le type de journal sélectionné est lié à la définition de la Banque.
Un traitement propre vous permet d'effectuer la comptabilisation en banque des règlements (voir Comptabilisation en banque). Vous pouvez également remettre un règlement en banque depuis la saisie de remise ou saisie de domiciliations (suivant les étapes paramétrées), ce qui permet aussi de valider cette étape pour un règlement/bordereau/avis unique

Autorisation requise

Vous pouvez exiger que les règlements de type dépense ou indéterminés soient soumis à une approbation. Pour cela, sélectionnez la case à cocher Autorisation et assurez-vous que les cases Bordereaux de remise et Fichier banque sont aussi sélectionnées. Les utilisateurs désignés comme approbateurs ont le paramètre PAYAPP - Autorisation de paiement (chapitre TDS, groupe AUZ) sur Oui.

Dévalorisation des effets

Cette dernière étape permet de gérer la comptabilisation des effets, notamment pour les législations espagnole ou portugaise. Indépendamment des législations, cette dernière étape permet de générer une étape de comptabilisation supplémentaire depuis la fonction Dévalorisation des effets.

Le groupe de pièce doit être défini.

Vous devez indiquer le journal utilisé pour la comptabilisation intermédiaire. Vous pouvez générer des schémas comptables différents suivant que le règlement soit remis à l'encaissement ou à l'escompte. Le journal sélectionné, selon le paramétrage, peut être déterminant pour la recherche du (des) compte(s). Le type de journal sélectionné est lié à la définition de la Banque.

Onglet Trésorerie

Longueur fixe de champ

Le fichier d'export des échéances est en longueur fixe (cf. documentation Export échéancier tréso Sage).
De ce fait, le contenu d'une zone peut être tronqué si, du fait du paramétrage, elle vient à contenir trop de caractères par rapport à sa longueur maximale dans le progiciel de trésorerie.

S'agissant de l'interface avec Sage Concept Trésorerie :

  • pour le code Nature (CPTA) = 16 caractères maximum
  • pour le code Annexe (CDC) = 16 caractères maximum
  • pour le Commentaire (DESCR) = 32 caractères maximum
  • pour le code Référence (CODRIF) = 8 caractères maximum
  • pour le Numéro de chèque (NASS) = 8 caractères maximum

 SEEWARNING Le paramétrage de certaines zones doit aussi tenir compte descontraintessuivantes :

  • les zones Nature (CPTA) et Annexe (CDC)
    Au niveau du progiciel de trésorerie, ces zones pointent sur une table de valeur ; il est donc préférable de les alimenter de la même façon pour l'export des échéances.
  • la zone Numéro de chèque (NASS)
    Celle-ci n'a pas vocation à récupérer un numéro de chèque, inexistant à ce stade du cycle de vie des échéances, mais plutôt à récupérer des informations complémentaires (si CODRIF et DESCR sont insuffisants par exemple)
Valeurs par défaut et valeurs saisies

Dans le cas où le paramétrage n'est pas renseigné pour tout ou partie des champs du fichier de trésorerie, les valeurs par défaut suivantes sont appliquées, quelle que soit la transaction et la banque :

  • pour la Date d'opération (DOPE) =
    • si le fait générateur = remise en banque
      • DOPE = date comptable
    • si le fait générateur < remise en banque
      • DOPE = date échéance si date échéance > date comptable
      • DOPE = date comptable si date échéance < date comptable
  • le champ Numéro de chèque (NASS) =
    • si le paramétrage de la transaction de règlement prévoit le champ 'Numéro de chèque' (CHQNUM de PAYMENTH), son contenu est automatiquement repris.
    • pour le neutraliser, il suffit de paramétrer un autre contenu (y compris "" pour que la zone soit transmise vide)

Dans le cas où ces valeurs par défaut ne conviennent pas, le paramétrage de certaines zones doit tenir compte des contraintes suivantes :

  • les zones Nature (CPTA) et Annexe (CDC)
    Au niveau du progiciel de trésorerie, ce champ pointe sur une table de valeurs ; il est donc préférable de l'alimenter de la même façon pour l'export des règlements.
  • le champ Date d'opération (DOPE)
    Ce champ est au format de date JJMMAAAA.
  • le champ Numéro de chèque (NASS)
    Celle-ci a ici vocation à récupérer un numéro de chèque, mais elle peut parfaitement être 'détournée' sur certaines transactions, pour récupérer des informations complémentaires (si CODRIF et DESCR sont insuffisants par exemple)

Longueur fixe de champ

  • pour le code Transfert (TRANS) = 128 caractères maximum
  • pour le code Libellé (DESCR) = 128 caractères maximum

 SEEINFO Ces zones ne pointent pas sur des tables de valeur, côté Sage 1000 Trésorerie.

Valeurs par défaut et valeurs saisies

Dans le cas où le paramétrage n'est pas renseigné pour tout ou partie des champs du fichier de trésorerie, les valeurs par défaut suivantes sont appliquées, quelle que soit la transaction et la banque :

  • pour la Date d'opération (DOPE) =
    • si le fait générateur = remise en banque
      • DOPE = date comptable
    • si le fait générateur < remise en banque
      • DOPE = date échéance si date échéance > date comptable
      • DOPE = date comptable si date échéance < date comptable
  • pour la Référence (REF) =
    • si le paramétrage de la transaction de règlement prévoit le champ 'Numéro de chèque' (CHQNUM de PAYMENTH), son contenu est automatiquement repris.
    • pour le neutraliser, il suffit de paramétrer un autre contenu (y compris "" pour que la zone soit transmise vide)

Dans le cas où ces valeurs par défaut ne conviennent pas, le paramétrage de certaines zones doit tenir compte des contraintes suivantes :

  • le champ Transfert (TRANS)
    Elle permet de savoir s'il s'agit d'un virement international ou non et le contenu attendu de ce champ est de type Oui ou Non. Les valeurs envoyées sont libres pour peu qu'il n'y en ait que 2 distinctes (Sage 1000 Trésorerie utilise alors une table de transcodage)
  • le champ code Budgétaire (BUDG)
    Au niveau du progiciel de trésorerie, ce champ pointe sur une table de valeurs ; il est donc préférable de l'alimenter de la même façon pour l'export des règlements.
  • le champ Date d'opération (DOPE)
    Ce champ est au format de date JJMMAAAA.
  • le champ Référence (REF)
    Celle-ci a ici vocation à récupérer un numéro de chèque, mais elle peut parfaitement être 'détournée' sur certaines transactions, pour récupérer des informations complémentaires (si CODRIF et DESCR sont insuffisants par exemple)
  • le champ Type de LCR (LCR)
    Les valeurs attendues sont Encaissement/Escompte/Aucune, ou toutes autres valeurs dès lors qu'il n'y en a que 3. Le transcodage est alors fait au niveau de Sage 1000 Trésorerie.

S’agissant de l'interface avec Sage FRP Treasury

  • pour le code Libellé (DESCR) = 32 caractères maximum,
  • pour le code Référence (REFXRT) = 16 caractères maximum.

 SEEINFO Ces zones ne pointent pas sur des tables de valeur, côté Sage FRP Treasury.

Valeurs par défaut et valeurs saisies

Dans le cas où le paramétrage n'est pas renseigné pour tout ou partie des champs du fichier de trésorerie, les valeurs par défaut suivantes sont appliquées, quelle que soit la transaction et la banque :

  •  pour la Date d'opération (DOPE) =
    • si le fait générateur = remise en banque
      •  DOPE = date comptable
    • si le fait générateur < remise en banque 
      • DOPE = date échéance si date échéance > date comptable 
      • DOPE = date comptable si date échéance < date comptable

Actions spécifiques

Messages d'erreur

Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :

Transaction de type SEPA : incohérence entre le sens du règlement et les modes de règlement rattachés ($1$)

Ce message s'affiche lorsque le contrôle de cohérence entre le sens de la transaction de saisie et le mode de règlement sélectionné échoue.
 

Tables mises en œuvre

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre