La saisie de Données
Principe de numérotation des ecritures
Le « protocole » est un numéro d’enregistrement chronologique affecté aux écritures. Il démarre à « 1 » en début d’année civile, indépendamment des dates de début et de fin des exercices comptables.
Pour les achats et les ventes, le numéro de protocole doit être strictement chronologique. Un numéro de protocole affecté à une écriture comptabilisée à une date donnée ne peut en aucun cas être inférieur au numéro de protocole d’une écriture enregistrée à une date antérieure. Cette chronologie doit être contrôlée lors de la saisie.
Autrement dit, le défilement entre la date comptable et le numéro de référence (identifiant ) de l’écriture doit être homogène.
Exemple : Si l’écriture n°10 a une date comptable du 30/06, l’écriture n°11 ne peut pas avoir une date comptable du 29/06.
Donc, un champ existe depuis la version 4.0.0 dans la fonction P_1ENV / Distributeur, où l’on précise :
Chronologie par date : O ou N pour la nature associée à ce distributeur.
Les distributeurs de numéro de pièce dans ACE FINANCE sont très proches de la notion de « protocole ». Le numéro de protocole revenant à « 1 » en début d’année civile, le masque du distributeur doit indiquer l’année civile, ceci afin d’éviter des numéros en double à chaque nouvel exercice. Par ailleurs, pour différencier les distributeurs de protocole ci-dessus, il sera utile d’intégrer dans le masque un code origine représentant la catégorie de journaux.
Modification paramétrable des écritures intégrées
Contexte fonctionnel : seules 2 contraintes légales limitent la possibilité de modifier les éléments d’une écriture comptable en Italie ; ce sont :
1) l’édition de la déclaration de TVA (qui peut être mensuelle ou trimestrielle, suivant l’importance de la société)
2) l’édition des journaux avec « BOLLATO » (notion d’estampillage de documents officiels).
La déclaration de TVA fixe un certain nombre d’informations : le guide de TVA (taux, article fiscal), le montant de TVA et par conséquent l’assiette, ainsi que le tiers, mais pas le compte dit « de contrepartie » (charge ou produit).
Par exemple, on peut imaginer d’éclater sur plusieurs comptes un montant HT ou de regrouper les montants de plusieurs comptes sur un seul, mais avec le même guide de TVA.
Dans les faits, la pratique consiste davantage à modifier ou à supprimer des mouvements d’écriture, plutôt qu’à supprimer des écritures entières.
Le paramètre P_MECR a donc été créé depuis la version 4.1.0 ; il doit être positionné sur une fonction de saisie s’appuyant sur P_2SAI.exe ou P_SAI.exe.
Il permet de modifier dans une certaine mesure des écritures comptables intégrées, en fonction de 2 notions : lettrage ou couche concernée.
Le A1 : détermine si la modification d’une écriture comptable intégrée dont aucun mouvement n’est lettré est possible.
O pour pouvoir modifier
N pour l’interdire.
NB : si le mouvement d’une pièce est lettré, il conviendra de le « délettrer » avant de le modifier.
Le A2 : détermine si la modification d’une écriture dont un ou plusieurs mouvements sont lettrés est possible.
O permet d’annuler le lettrage des mouvements lettrés du « lot de lettrage » et de procéder aux modifications.
N interdit ce type de modification.
Le A3 : détermine si l’on autorise ou non la modification des écritures dont la TVA a déjà été déclarée.
O : on autorise cette modification ;
N : on interdit cette modification ;
Autrement dit, ce critère permet de « verrouiller » les écritures ayant déjà fait l’objet d’une déclaration de TVA.
N1 & N2 & N3 : ces 3 zones (facultatives) servent à préciser de façon limitative chacune des couches comptables concernées par ces modifications. Par défaut (si l’on ne renseigne rien), toutes les couches sont modifiables.
Exemple : si N1 = 1, seule la couche 1 est modifiable.
Limites de la fonctionnalité : elles sont liées au cœur du produit ; parmi tous les mouvements d’une écriture, le 1er mouvement (dit « mouvement 100 » dans ACE FINANCE) qui porte le TTC ne peut être supprimé. Si l’on veut le modifier, il conviendra d’annuler l’écriture et de recommencer.
D’autre part, la modification d’un mouvement de TVA (qui provient du mouvement HT) passe par une modification de ce mouvement HT.
De plus, la modification du compte sur un mouvement HT implique aujourd’hui de supprimer le mouvement entier.
Enfin, il est prévu, à l’avenir de pouvoir modifier le tiers sur le mouvement de TTC.
Gestion des arrondis et correction d’un mouvement de TVA
Gestion des arrondis
Certaines devises, dont notamment la lire italienne, n’ont pas de décimale ; la valeur intrinsèque de la monnaie étant déjà trop faible. Dans les calculs réalisés, (et notamment les calculs de TVA), les éventuelles décimales doivent donc être neutralisées. C’est le rôle du paramètre TVAARR (créé en version 4.1.1), qui selon son paramétrage, fixe les règles d’arrondi à appliquer.
Le A1 : uniquement dans le cas de l’Italie, c’est ici que l’on précise le code de la devise, qui va faire l’objet de l’arrondi (Ex : ITL)
Le N1 : pour l’Italie, il peut prendre 2 valeurs :
2 = l’arrondi pratiqué sur la TVA dépend du sens de la transaction : pour les factures, arrondi à l’unité supérieure ; pour les avoirs, arrondi à l’unité inférieure ;
3 = l’arrondi pratiqué sur la TVA est le même pour les factures et les avoirs : arrondi à l’unité supérieure.
Pour mémoire, ce paramètre détermine un mode de calcul d’arrondi d’un mouvement de TVA ;
toutefois, la fonction GDEM permet de définir un masque de saisie et de visualisation des montants dans une devise donnée ; par exemple : lire italienne (ITL), 10 (partie entière sur 10 numériques), 0 (pas de décimales)
Correction d’un mouvement de tva sur achat
En gestion commerciale, en comparant la saisie détaillée des postes d’une facture d’achat et le montant global de la facture, il peut apparaître un écart d’arrondi, notamment au niveau du montant du mouvement de TVA.
Il existe un paramètre baptisé CTRFAC , qui permet, si le A2 est égal à G , de compléter le mouvement de TVA de l’éventuel écart constaté entre la TVA calculée au niveau des lignes de factures et la TVA de référence saisie en en-tête de facture.
Ce complément s’inscrit bien sûr dans une fourchette définie dans le N1 ; par exemple :
pour une fourchette de 0.5 %, saisir 50 ;
pour une fourchette de 1 %, saisir 100 ;
Gestion des mouvements de pro-rata de tva
Dans le cas où une société peut déduire la TVA, mais uniquement sur une partie de son activité, il conviendra de gérer un pro-rata de déduction. Dans ACE FINANCE, ce dernier est indiqué dans le guide de TVA défini dans la fonction P_1ENV / Guide.
En Italie, dans ce cas de figure, il conviendra de réinjecter la part non déductible du mouvement de TVA sous forme d’un mouvement sur le même compte de HT que celui qui supporte l’assiette de TVA.
Pour ce faire, il faudra mentionner sur le guide de TVA concerné le code « 1 » dans le champ « type de gestion TVA ».
D’autre part, en gestion commerciale, il existe un paramètre baptisé TVADED (actif depuis la version 4.1.3, mais patché en version 4.1.1) ; ce paramètre permet un même comportement que celui décrit ci-dessus, pour autant que le N1 soit égal à « 0 », ou ne soit pas renseigné.
Si le N2 est égal à « 1 », cela permet d’obtenir le même comportement que précédemment, même quand le % de déductibilité de la TVA est nul ; on aura alors 2 mouvements sur le même compte HT considéré, l’un avec l’assiette HT et l’autre avec l’ « équivalent TVA » .
Voir les exemples dans la documentation du paramètre.
Utilisation des articles fiscaux
- Le guide comptable (modifiable lors de la saisie),
- Le taux d’IVA (modifiable lors de la saisie),
- Le montant d’IVA calculé et proposé automatiquement (modifiable lors de la saisie).
Le guide comptable de type 2 revêt en plus une importance particulière pour l’IVA. Il permet d’indiquer le « code article fiscal » (au sens article du code de fiscalité italien) justifiant l’exonération fiscale . En effet, en Italie, certaines opérations commerciales font l’objet d’une exonération de TVA, selon un article fiscal issu du code fiscal italien Ce code est utilisé pour les déclarations d’IVA mensuelles et annuelles..Il convient donc qu’il soit renseigné en amont, pour pouvoir récupérer cette information.
-
Dans ACE Finance
; le guide de TVA est saisi sur chaque mouvement HT ; cette information
sera alors positionnée dans un champ spécifique du guide de TVA (de type 2),
dénommé «
Article Fiscal
», que l’on peut renseigner par la fonction P_1ENV / Guide. (fonctionnalité créée en version 4.0.0 )
-
Dans ACE Commerce
; le guide de TVA est déduit du code TVA en utilisant les « aiguilleurs »
comptables Qui et Quoi (cf fonction GPIC ) ;
toutefois, il existe un paramètre, baptisé
CODFIS
, (développé dans une version antérieure à la 3.7.0 ) qui permet de
prendre en compte un code fiscal (champ « codfis » de la table EVP ) au niveau d’un poste d’événement, ce code fiscal
correspondant à un code guide de TVA du poste, lors de la génération
d'écritures nécessitant la justification de l'exonération de TVA par un article
fiscal.
Pour une facilité de saisie, on peut utiliser une zone paramétrée (codzn)de l’en-tête d’événement et proposer sur chaque poste d’événement le code fiscal saisi dans cette zone paramétrée.
Le N1 indiquera alors le numéro de la zone paramétrée utilisée pour cet usage.
Important : ce que l’on appelle code fiscal ci-dessus, c’est en fait le code du guide de TVA exonéré, dont le champ article fiscal est renseigné .
Calcul d’une TVA collectée sur article gratuit
En Italie, il est possible de vendre un ou plusieurs articles, à un prix nul, mais le Fisc va quand même collecter une TVA sur la valeur de ces articles ; le vendeur a dans ce cas 2 possibilités : soit il paye lui même la TVA ; soit il la fait supporter à son client ; donc, tout n’est pas gratuit pour le client !
Dans ACE COMMERCE, la combinaison de deux paramètres : CODFIS et IVAGRA (fonctionnalité développée en version 4.3.0 et patchée en version 4.1.0 et 4.1.1) permet de traiter ces deux cas de figures, à condition que l’on soit dans un mode « Intégré ».
Le paramétrage de cette fonctionnalité étant assez complexe, il conviendra de se référer à la documentation de ces paramètres.
Vérification des coordonnées bancaires ABI-CAB
En France, la référence d’un compte bancaire est structurée de façon particulière (n° de banque, n° d’agence, n° de compte et calcul d’une clé).
En Italie, seuls 2 éléments sont normalisés ; ce sont les codes banques (5 caractères) et les codes guichets (5 caractères) ; cette liste de codes existe dans la société d’installation italienne (et est donc disponible via des .STR), avec les codes à jour en avril 2000 ;
Toutefois, on peut récupérer une liste mise à jour sur le site WEB suivant : “http://www.eniac.it”.
D’autre part, le paramètre P_ADBQ avec A1 =O permet lorsque l’on a saisi le code banque et le code guichet de contrôler l’existence du couple saisi et de récupérer les libellés associés.
Il conviendra également de créer un type de domiciliation italien code « 05 » Italie avec longueur banque 4, longueur guichet 5 et longueur compte 12 (valeur maximale).
Intégration des écritures provisoires
Intégration en masse des ecritures provisoires
L’une des manières de répondre au caractère « transitoire » de certaines informations des mouvements comptables d’une écriture italienne est de saisir cette écriture sur une « couche » provisoire ; la possibilité d’utiliser une couche provisoire est définie au niveau du journal comptable ; pour mémoire, l’« aiguillage » de l’écriture sur une couche provisoire se définit dans un pop-up de P_SAI « Etat de la validation » , accessible dans le tableau de saisie des mouvements, où l’on trouve le champ Provisoire O /N .
Une écriture provisoire peut être annulée physiquement, modifiée ou intégrée sur la couche comptable.
Cette intégration peut s’effectuer pour un ensemble d’écritures(depuis la version 4.1.0) en temps différé (batch) par la fonction P_2PVA, option Ecriture Provisoire ; on accède à un écran, qui permet selon différents critères de sélection de paramétrer ce traitement.
Intégration par interface d’écritures sur une couche provisoire
L’intégrateur comptable d’ACE est un programme, qui permet de prendre des données comptables issues de divers logiciels externes et de les « traduire » pour les rendre acceptable par ACE ; autrement dit , il les met au format ACE ; c’est la fonction P_2ITF.
Pour des écritures comptables, cette intégration ne pouvait jusqu’à présent s’effectuer que sur la couche comptable d’un journal.
Aujourd’hui, depuis la version 4.1.0, on peut intégrer des écritures, directement avec le statut « provisoire ».
Pour cela, il conviendra de renseigner la zone I_ITFACT dans l'enregistrement SOC avec la valeur P . Toutes les écritures de l'interface seront passées sur la couche provisoire du journal. Si le journal n'a pas de couche provisoire, elles seront comptabilisée sur la couche définitive (comptable).
N° identifiant TVA : Contrôle d’unicité, de structure et critère de recherche d’un tiers.
Le numéro d’identification de TVA (Partita IVA) a une structure donnée en Italie ; il est en général unique pour un tiers donné et il sert souvent de critère de recherche d’un tiers donné.
Les contrôles de structure et éventuellement d’unicité sont gérés via le paramètre TVACOM, qui est une évolution depuis le version 4.3.0, du paramètre CTRTVA (créé en version 4.1.2). On se reportera à la documentation de ce paramètre, pour de plus amples informations.
Enfin, le champ TVAINTER qui contient ce numéro d’identification TVA a été ajouté de façon virtuelle dans l’écran de recherche de la saisie comptable ; par la fonction PECR, il peut être dé-virtualisé et rendu visible dans l’optique exprimée ci-dessus.
Gestion du moyen de paiement Ri.Ba. (Ricevuta Bancarie)
Les Ri BA constituent un mode de règlement qui s’apparente pour partie à une gestion de prélèvement client et pour une autre partie à une gestion d’effets.
Un tiers fournit à sa banque une liste de créance –clients, constituée en portefeuille.
Une fois ce portefeuille remis à la banque (ou au pool bancaire), celle-ci pourra procéder à l’encaissement de ces créances . Le RiBa pourra également être le cas échéant endossé ;
- Le nom ou la raison sociale du tiers débité ;
- La domiciliation complète du tiré
- Le numéro de la facture
- La date comptable de la facture
- La date d’échéance de la facture
- Le montant de la facture
On peut distinguer 2 étapes :
1) la constitution du portefeuille : celle-ci diffère suivant que l’on est en mode intégré ou en mode « autonome ».
· En mode intégré, pour autant que dans la fiche client la modalité « RB » ait été définie et que l’on aie positionné les paramètre de type EFFExx sur gbfav1 , en indiquant les modalités et les natures qui doivent générer des virements sur le portefeuille d’effets, le portefeuille se constituera au fur et à mesure de l’émission des factures.
· En mode autonome, il faudra passer par l’ensemble des étapes (facultatives ou obligatoires)de la constitution des relevés périodiques clients (fonction P_3RVE), après avoir créé le guide de relevé « RBC » (= Ricevute Bancarie Clienti) :
a) Préparation (Obligatoire)
Cette étape va sélectionner les factures pour lesquelles une demande de prélèvement sera transmise à la banque.
Seuls les clients dotés du guide de gestion des relevés « RB » seront sélectionnés (cf. fiche signalétique du client, et utiliser le popup <PF1>+C « Données comptables »).
De plus, seules les factures possédant le mode de règlement « RB » seront sélectionnées.
Fonction : P_3RVE / Préparer RVE / Préparer
Préciser le guide de relevé (« RBC » = Ricevuta Bancarie Clienti), et vérifier la date comptable jusqu'à laquelle seront sélectionnées les factures clients.
NB 1 : la date comptable est affichée automatiquement et dépend d’un calendrier renseigné lors de la création du type de relevé (fonction P_3ENV / Relevés). En Italie, il est prévu d’effectuer ce traitement 2 fois par mois : en milieu et en fin de mois.
NB 2 : ce traitement ne prévoit pas d’état à imprimer.
b) Liste préparatoire (Obligatoire)
Cette liste correspond à la sélection des factures effectuée lors de la phase précédente. L’édition (=lancer le traitement, pas obligatoirement imprimer l’état) de cette liste est obligatoire.
Fonction : P_3RVE / Liste préparatoire
Préciser le guide de relevé.
c) Liste des hors relevés (Facultative)
Il s’agit d’une liste des factures clients qui n’ont pas été sélectionnées lors de la phase de préparation et qui pourraient être, éventuellement ajoutées à la préparation.
Fonction : P_3RVE / Liste hors relevé
Préciser le guide de relevé.
d)Ajustements (Facultative)
Cette option permet, manière interactive, modifier la préparation : ajout ou suppression de factures (donc ajout ou suppression de demande de prélèvement).
Fonction : P_3RVE / Ajuster
Préciser le compte client.Utiliser le popup <PF1>+A : pour ajouter des factures.
Utiliser le popup <PF1>+M : pour enlever des factures.
e) Validation(Obligatoire)
Cette phase permet de valider la sélection de factures clients opérée jusqu’alors.
Fonction P_3RVE / Valider
Préciser le guide de relevé et valider. Noter le N° de lot fourni par le sustème.
f) Edition provisoire (Facultative)
Permet d’éditer un état destiné à la banque.
Fonction : P_3RVE / Relevés / Préparatoire
Préciser le guide de relevé et le numéro de lot.
g) Génération des écritures (Obligatoire)
Cette phase va générer les écritures comptables de type :
Crédit Client à Débit portefeuille d’effets.
Fonction : P_3RVE / Relevés / Ecritures
Préciser le type de relevé, le numéro de lot, la date comptable, la nature de pièce et le libellé des écritures.
NB : bien vérifier si toutes les écritures du lot ont été générées ! ! ! Consulter si nécessaire le compte-rendu du traitement (cf. fiche explicative de la fonction UEDI).
2) La remise des effets en banque : Cette étape ne fait pas partie de la chaîne des relevés clients. Elle est utilisée pour vider le portefeuille d’effets vers le compte banque (compte transitoire). Ce compte transitoire sera soldé et le compte de banque débité à réception de l’extrait de compte bancaire qui montrera les prélèvements effectués et les impayés.
- sélectionner tous les effets contrôler le montant total de la sélection
- compléter par la nature de pièce, la date comptable et le libellé de l’écriture.
Pour saisir les éventuels impayé, utiliser la fonction de saisie de règlements (P_2SAI) et utiliser la nature de pièce prévue à cette effet (IMP).
