N° document
Important
Tout ou partie de la fonctionnalité décrite dans cet article est accessible dans le cadre d’une version préliminaire. Le contenu et la fonctionnalité peuvent faire l’objet de modifications. Pour plus d’informations sur les préversions, voir Disponibilité des mises à jour de service.
Qu’est-ce qu’un N° document ?
En raison de la flexibilité des journaux financiers, vous pouvez saisir une pièce justificative unique qui représente une transaction, mais qui a plusieurs clients, fournisseurs, immobilisations, projets ou comptes bancaires. Microsoft fait référence à cette fonctionnalité comme N° document. Les scénarios N° document n’incluent pas les transactions qui incluent uniquement les comptes généraux. Ces transactions sont comptabilisées dans le grand livre général, et non dans les livres auxiliaires tels que la comptabilité client, les immobilisations et la banque.
Il existe deux catégories d’exemples de N° document :
Le N° document contient plusieurs transactions qui ont été saisies comme une seule transaction. Voici quelques exemples possibles :
- Plusieurs paiements fournisseur sont saisis sur chaque ligne (aucun compte de contrepartie n’est utilisé) et la contrepartie du montant du paiement sur un compte bancaire est saisie sur une seule ligne. La récapitulation des paiements est effectuée pour mettre à jour le grand livre auxiliaire de la banque en tant que montant récapitulatif correspondant au relevé de compte bancaire. Cependant, chaque transaction fournisseur est toujours enregistrée en détail dans la comptabilité auxiliaire de la comptabilité fournisseur. Le même scénario se retrouve également côté paiement client.
- Plusieurs immobilisations sont acquises en un seul N° document. Cette approche est souvent utilisée quand les soldes d’ouverture sont saisis pour le module Immobilisations.
Le N° document contient une transaction qui affecte plusieurs types de comptes non généraux. Voici quelques exemples possibles :
- Virements
- Compensation des soldes fournisseur/client (même partie)
- Transfert de soldes du client A au client B
- Factures fournisseur comportant plusieurs lignes contenant des immobilisations ou des projets
Les exemples précédents pour chaque catégorie représentent des exigences opérationnelles valides. Parfois, les exigences commerciales ne peuvent être satisfaites d’aucune autre manière : l’organisation doit saisir les transactions sous la forme d’un N° document. Cependant, à d’autres moments, il existe d’autres moyens valables de répondre aux besoins de l’entreprise : les transactions peuvent être saisies différemment ou utiliser une autre fonctionnalité.
Problèmes liés à la fonctionnalité N° document
L’utilisation de la fonctionnalité N° document pour répondre aux besoins de l’entreprise peut entraîner des problèmes. Divers processus, annulations de transactions et demandes de renseignements/rapports nécessitent des détails sur les transactions. Ces détails ne peuvent pas être déterminés à partir du modèle de données actuel si plusieurs transactions sont saisies en résumé dans un seul N° document. De plus, les détails ne peuvent pas toujours être clairement déterminés si le type de transaction saisi est inconnu. Cette limitation est causée par la flexibilité des revues, surtout quand elles sont réintroduites par le journal des opérations diverses.
Certains scénarios peuvent toujours fonctionner correctement, selon la configuration de votre organisation. Voici les domaines dans lesquels vous pouvez rencontrer des problèmes :
Règlement – S’il existe plusieurs fournisseurs ou clients sur un justificatif, la comptabilité créée pendant le règlement peut être affectée de manière incorrecte aux dimensions financières. Pour plus d’informations sur les problèmes qui peuvent survenir pendant le règlement, voir N° document avec plusieurs enregistrements de clients ou de fournisseurs. Les performances de règlement sont fortement influencées par le nombre de lignes du journal des factures qui utilisent un justificatif unique. Le temps nécessaire à la validation du règlement et du paiement devrait augmenter de façon exponentielle si le nombre de lignes du journal des factures utilise un justificatif unique.
Calcul de la taxe – S’il existe plusieurs justificatifs ou clients sur un justificatif, le calcul de la taxe peut être incorrect.
Contrepassation de transaction – S’il existe plusieurs types de comptes de comptabilité auxiliaire sur un justificatif, quand une seule transaction de compte de comptabilité auxiliaire est contrepassée, une écriture comptable incorrecte peut être validée pour la contrepassation dans la comptabilité. Par exemple, si vous acquérez plusieurs actifs dans un seul compte de comptabilité auxiliaire, puis annulez l’acquisition de l’un des actifs, la comptabilité générale sera incorrecte pour l’annulation.
Rapports et demandes – Si vous incluez plus d’un type de compte auxiliaire (par exemple, Fournisseur et Client) sur un compte de comptabilité auxiliaire, les rapports/requêtes n’afficheront que la première valeur de compte trouvée.
Par exemple, vous validez la facture fournisseur multiligne suivante. Elle contient quatre projets qui représentent les "lignes" sur la facture. Cette approche est une exigence commerciale courante pour les organisations qui utilisent beaucoup les revues.
Trois des quatre projets sont affichés sur le même compte principal (601500). Si vous ouvrez l’explorateur de source comptable pour afficher les détails des transactions comptabilisées pour ce compte principal, vous remarquerez que l’ID de projet pour les trois lignes est 000057. Ce comportement est une limitation connue de compte de comptabilité auxiliaire. Les détails ne lieront pas correctement chaque ligne au projet approprié sur le journal. Au lieu de cela, la première valeur de compte trouvée sera toujours affichée sur les rapports et dans les demandes de renseignements.
Entrez une transaction en tant que N° document
Pour saisir des transactions sous forme de N° document, rendez-vous sur Comptabilité > Configuration de la comptabilité > Paramètres de comptabilité, puis, sur le comptabilité onglet, définissez le Autoriser plusieurs transactions sur un seul N° document sur Oui.
Vous pouvez saisir une transaction de N° document sur le Noms de journaux page en réglant la Nouveau N° document champ à l’une des valeurs suivantes :
- Un seul numéro de justificatif – Chaque ligne que vous ajoutez au journal sera incluse dans le même justificatif et les lignes contiendront plus d’un client, fournisseur, banque, immobilisation ou projet.
- En lien avec le solde – Saisissez un justificatif multiligne quand il n’y a pas de compte de contrepartie et que les lignes contiennent plus d’un client, fournisseur, banque, immobilisation ou projet.
- En lien avec le solde – Entrez un justificatif à une seule ligne quand le compte et le compte de contrepartie contiennent un type de compte auxiliaire, par exemple Fournisseur/Fournisseur, Client/Client, Fournisseur/Client ou Banque/Banque.
Mon scénario d’entreprise nécessite-t-il un N° document ?
Les scénarios commerciaux suivants ont été identifiés comme des scénarios pour lesquels les clients utilisent la fonctionnalité N° document. Certaines exigences métier peuvent être remplies uniquement à l’aide de la fonctionnalité N° document. Cependant, pour beaucoup d’autres, d’autres options sont disponibles.
| Scénario | Description | Un N° document est-il obligatoire ? | Alternative |
|---|---|---|---|
| Résumé sur le paiement fournisseur | Une organisation communique une liste de fournisseurs et des montants à sa banque. La banque utilise cette liste pour payer les fournisseurs au nom de l’organisation. Chaque paiement fournisseur doit être enregistré en détail dans les comptes fournisseurs, mais la somme des paiements est enregistrée sur le compte bancaire en un seul retrait. | Pas de | À partir de Microsoft Dynamics 365 Finance version 10.0.32, il existe une fonctionnalité nommée Possibilité de valider des paiements fournisseur et client détaillés, mais de synthétiser les montants dans des comptes bancaires. Pour plus d’informations, voir Valider des paiements fournisseur et client détaillés. |
| Résumé du paiement client | Les paiements des clients sont déposés sous forme de somme forfaitaire sur le compte bancaire. Chaque paiement client doit être enregistré en détail dans les comptes clients, mais la somme des paiements est enregistrée sur le compte bancaire en un seul dépôt. | Non | À partir de Dynamics 365 Finance version 10.0.32, il existe une fonctionnalité nommée Possibilité d’afficher les paiements détaillés des fournisseurs et des clients, mais de résumer les montants sur le compte bancaire. Pour plus d’informations, voir Valider des paiements fournisseur et client détaillés. |
| Facture client/fournisseur | Une facture est saisie pour un seul client ou fournisseur, mais des lignes supplémentaires représentent les lignes de la facture et ont plusieurs immobilisations ou projets. | Oui | |
| Journal des paiements client avec acompte contenant des taxes sur plusieurs « lignes » | Un client effectue un prépaiement pour une commande. Les lignes de la commande ont des taxes différentes. Le paiement client d’acompte doit contenir le client sur plusieurs lignes, afin que les taxes puissent être calculées pour chaque ligne. | Oui | |
| Remboursement client | Si la tâche périodique Remboursement est exécutée dans la Comptabilité client, elle crée une transaction pour déplacer le solde d’un client à un fournisseur. Le vendeur est la même partie que le client. | Oui | |
| Maintenance des immobilisations : rattraper l’amortissement, fractionner une immobilisation et calculer l’amortissement sur la cession | L’amortissement de rattrapage, le fractionnement d’un actif et le calcul de l’amortissement pour la cession d’actifs sont tous utilisés pour créer un seul bon. | Non | Avec la version 10.0.21 de Finance, les transactions d’immobilisations créées pour l’amortissement de rattrapage, le fractionnement d’un actif et le calcul de l’amortissement pour la cession d’un actif utilisent différents N° documents. |
| Lettres de change et billets à ordre | Les lettres de change et les billets à ordre déplacent le solde client ou fournisseur d’un compte général Comptabilité client ou Comptabilité fournisseur à un autre, selon l’état du paiement. Étant donné que le même client ou fournisseur est toujours utilisé dans le N° document, aucun problème de rapport n’existe. | Oui | |
| Compensation | Si un client et un fournisseur sont la même partie, les soldes du fournisseur et du client sont compensés les uns en fonction des autres. Cette approche réduit l’échange d’argent entre une organisation et la partie client/fournisseur. | Non | À partir de Microsoft Dynamics 365 Finance version 10.0.40, il existe la fonctionnalité Compensation client et fournisseur. La fonctionnalité de compensation crée automatiquement deux justificatifs comptables distinctes pour le fournisseur et le client. Pour plus d’informations, voir Soldes fournisseur et client nets. |
| Transférer les soldes | Une organisation peut être amenée à transférer un solde d’un fournisseur à un autre, en raison d’une erreur ou de la reprise du passif par un autre fournisseur. Les transferts de ce type s’appliquent également aux types de comptes tels que les Client ou Banque. | Oui/Non | Les transferts de solde d’un compte (fournisseur, client, banque, etc.) vers un autre peuvent être effectués via des justificatifs distincts, et la contrepartie peut être validée dans un compte général de compensation. Pour certaines organisations, cette approche nécessite trop de frais généraux. Par conséquent, ils choisissent d’utiliser un N° document à la place. |
| Règlement de plusieurs paiements non validés sur la même facture | Ce scénario est généralement utilisé dans les organisations où les clients peuvent utiliser plusieurs modes de paiement pour les achats. Dans ce scénario, l’organisation doit pouvoir enregistrer plusieurs paiements non validés et les régler pour la facture client. | Non | Une nouvelle fonctionnalité ajoutée à Finance permet de régler plusieurs paiements non validés pour une facture unique. |
| Fonctions spécifiques à un pays/une région | Le Document administratif unique (DAU) fonctionnalité pour la Pologne exige actuellement que les transactions soient regroupées, et le N° du document est utilisé à cette fin. Des fonctionnalités supplémentaires spécifiques au pays/région peuvent nécessiter la fonctionnalité N° document. | Oui | |
| Mécanisme pour regrouper les transactions d’un événement commercial | Une organisation a un événement commercial unique qui déclenche plusieurs transactions. Le service Comptabilité souhaite afficher ensemble les écritures comptables pour un audit simplifié. Un scénario similaire est celui où les transactions bancaires sont enregistrées dans Finance via un fichier reçu de la banque. Les organisations souhaitent souvent regrouper ces transactions à l’aide du numéro de relevé bancaire dans le fichier. | Non | Bien que le regroupement de transactions soit un scénario valable, le N° document ne doit jamais être utilisé à cette fin. Les N° documents représentent toujours des transactions individuelles, jamais un groupe de transactions. Les transactions peuvent être regroupées selon d’autres champs à la place, comme le numéro de lot du journal ou le numéro de document. |
| Saisie des soldes d’ouverture | Les organisations entrent souvent les soldes d’ouverture des comptes auxiliaires (fournisseurs, clients, immobilisations, etc.) en tant que transaction de N° document. | Non | Les soldes d’ouverture de chaque compte auxiliaire doivent être saisis sous forme de N° documents distincts. La contrepartie peut être imputée sur un compte général, qui est compensé par le solde d’ouverture du compte général. |
| Corriger l’écriture comptable d’un document validé | Une organisation peut avoir à corriger le compte général Comptabilité client ou Comptabilité fournisseur pour une facture validée. Parce que la facture est correcte, elle ne doit pas être annulée. | Oui/Non | Si une correction doit être effectuée dans le compte général Comptabilité client ou Comptabilité fournisseur, un ajustement peut être effectué directement dans le compte général. Cette approche nécessite que l’ajustement ait lieu pendant un « temps d’arrêt » afin que le compte général puisse temporairement autoriser la saisie manuelle. L’un des inconvénients de cette approche est que les rapports de rapprochement fournisseur/client à bancaire montreront une différence à l’entrée et à la sortie. Le montant net est 0 (zéro). |
| Validation récapitulative dans la comptabilité | Les organisations souhaitent souvent effectuer une validation récapitulative dans la comptabilité afin de réduire la quantité de données. Toutefois, ces organisations requièrent toujours que les détails de la transaction soient mis à jour. Quand la validation récapitulative est effectuée via un N° document, les détails de la transaction ne sont pas connus et ne peuvent pas être mis à jour. | Non | Comme les détails de la transaction sont perdus, les organisations ne doivent utiliser N° document pour effectuer une validation récapitulative si les détails sont obligatoires pour les rapports. |
| « Autorisation du système » | Les organisations utilisent souvent la fonctionnalité N° document simplement parce que le système les y autorise, sans comprendre les implications. | Non | Le simple fait que le système permette l’utilisation de la fonctionnalité n’est jamais une raison valable. La fonctionnalité doit être utilisée uniquement si elle est obligatoire pour répondre à une autre exigence métier. |
Avenir de la fonctionnalité N° document
En raison des problèmes qui peuvent survenir quand la fonctionnalité N° document est utilisée, les options suivantes sont explorées :
- De nouvelles fonctionnalités continueront d’être introduites s’il existe une meilleure façon d’accomplir un scénario d’entreprise. Par exemple, une fonctionnalité qui a été introduite dans Finance version 10.0.32 permet de saisir des paiements sous forme de N° documents distincts, mais le compte bancaire est toujours mis à jour en résumé. Au fur et à mesure que des fonctionnalités seront ajoutées, elles seront documentées pour chaque scénario métier dans la colonne "Autres" du tableau précédent.
- Certaines transactions peuvent continuer à être saisies via le journal dans un seul document, mais des données supplémentaires peuvent être suivies pour identifier correctement les détails de la transaction.
- Une combinaison de nouvelles fonctionnalités peut être utilisée, mais les transactions pour les scénarios commerciaux peuvent continuer à être saisies dans le journal à l’aide d’un seul document.
Au fur et à mesure que de nouvelles fonctionnalités sont introduites, votre organisation doit évaluer en permanence si l’option Autoriser plusieurs transactions dans un seul N° document sur le Paramètre comptable page peut être désactivée. Nous vous recommandons de ne pas utiliser N° document pour les intégrations, sauf si elle est requise pour l’un des écarts fonctionnels.
Au fur et à mesure que les écarts fonctionnels seront comblées, Microsoft communiquera les nouvelles fonctionnalités à utiliser à la place du justificatif unique. Pour certains scénarios métier, par exemple une facture fournisseur avec plusieurs lignes, le justificatif unique continuera d’être utilisé mais avec des améliorations. Ces améliorations seront communiquées au fur et à mesure qu’elles seront disponibles.