Le domaine de la gestion commerciale
Au travers de divers Bulletins Officiels des Impôts (3 C.A, N° 136 du 7 août 2003, 13 L-1-06, N° 12 du 24 janvier 2006), la DGI a référencé un certain nombre de mentions devant figurer sur les factures.
Elle prévoit aussi que l’impression de la facture ne doit s’effectuer qu’à partir d’une pièce justificative validée (la validation définitive de la pièce garantissant donc son caractère intangible).
De même, le règlement de la facture ne doit intervenir que sur la base d’une pièce justificative validée.
Dans ce cadre-là, le paramètre INTCPYINV - Factures inter-sociétés (chapitre TRS, groupe INV) a nécessairement la valeur Non pour les sociétés de législation française1.
Les mentions obligatoires / factures de vente
Pour assurer la présence des informations obligatoires, notamment sur les factures, certaines zones doivent obligatoirement être renseignées sur les fiches de base.
Ces informations concernent des données relatives aux tiers, aux adresses et aux sociétés/sites. Le caractère obligatoire de ces informations est paramétré par pays, via une coche permettant de préciser si l’information est obligatoire en plus d’être présente.
Ainsi, pour le pays France FR2, le code postal devient une information obligatoire dans le fichier des adresses, ainsi que le SIREN et le SIRET.
Le caractère obligatoire de certaines de ces informations (le SIREN et le N° de TVA intra communautaire) sur les factures implique aussi que leur mise à jour soit suivie de manière particulière.
Quatre règles de workflow3 dédiées sont donc livrées à cette fin :
BPRMAINFLD |
Pour les tiers au sens large excepté les clients |
Champs CRN et EECNUM |
BPCMAINFLD |
Pour les clients |
Champs CRN et EECNUM |
CPYMAINFLD |
Pour les sociétés |
Champs CRN et EECNUM |
FCYMAINFLD |
Pour les sites |
Champ CRN |
Il faut donc prévoir d’adapter le/les destinataire(s) défini(s) dans les règles livrées.
Le cycle d’impression des factures clients
L’impression des factures et avoirs définitifs ne peut se faire que lorsque le document est comptabilisé et donc non modifiable.
Le paramètre SIVCFM - Impression obligatoire facture (chapitre TC, groupe INV) permet d’obtenir un cycle d’impression des factures ventes et des factures tiers clients répondant à cette exigence.
Il est livré avec la valeur de conformité Oui après validation comptable, pour la législation française et n'est pas modifiable. Il en est de même pour les sociétés de législation française.
Lorsque le paramètre a pour valeur Oui après validation comptable, toute impression de facture effectuée avant la validation comptable portera en diagonale la mention ‘PROVISOIRE’.
L'indicateur Impression n’a donc pour valeur Imprimé que lorsque l’impression est effectuée sur une pièce validée.
L’émission d’un bon d’acompte
Depuis la saisie de règlements, l'édition d'un bon d'acompte reçu (état INVACC) est possible.
L'édition INVACC est en effet proposée depuis la saisie de règlements4 sous réserve que le règlement respecte les conditions suivantes :
- Le règlement est porté par une transaction ou un règlement de type Recette5.
-
Le règlement ne contient que des lignes de règlements de type Acompte de même code taxe et de même devise.
L'édition du bon d'acompte s'appuie sur la pièce comptable de règlement qui ne doit contenir que des acomptes homogènes d’un point de vue taxe et devise.
Afin de disposer de règlement respectant ces conditions de regroupement d'échéance, un nouveau paramètre a été créé : PPYCONSCTL - Contrôle acompte (chapitre TRS, groupe PAY).
Il est livré avec pour valeur Oui pour la législation française FRA. Il en est de même pour toute société de législation FRA qui est créée.
En saisie directe de règlement, lorsque le règlement est de type Recette et que le paramètre PPYCONSCTL - Contrôle acompte a pour valeur Oui, le système contrôle alors que le règlement saisi respecte ces règles d’homogénéité et bloque sa création dans le cas contraire.
Lorsque la proposition automatique de règlements6 est lancée sur une transaction de recette donnée, le regroupement est ou non appliqué selon que le paramétrage de la transaction le permette ou non (cf. règle 3 ci-après).
La fonction de proposition de règlements pourra être lancée dans un 1er temps en tenant compte des échéances d'acomptes (et seules celles-ci seront prises en compte et regroupées par code taxe et devise), puis dans un 2ème temps en ne tenant pas compte des échéances d'acomptes (et seules celles-ci ne seront pas prises en compte).
Lorsque la proposition automatique de règlements est lancée toutes transactions de recette confondues, cette règle d'éclatement/regroupement est par contre systématiquement appliquée, que le paramétrage des transactions permettent ou non ensuite d'éditer INVACC (cf. règle 3 ci-après). - Le paramétrage de la transaction de règlements ne doit pas prévoir comme seule et unique étape de regroupement/comptabilisation le schéma suivant : [bordereau de remise OU domiciliation + comptabilisation en banque avec un regroupement Date échéance ou un regroupement Bordereau/Domiciliation].
La transaction de règlement doit être rattachée à un code édition rattaché lui-même à un code traitement prévoyant le lien vers l'état INVACC (via la gestion des codes impressions7).
Ces 3 critères permettent donc de disposer de règlements dont le contenu peut être édité sous forme de bon d'acompte.