ÉTAPE 1 : DÉTERMINER SI LES RAPPORTS FINANCIERS UTILISENT DES TABLES AA :

Avant de fermer GL ou d’exécuter les étapes de cet article, exécutez vos rapports financiers normalement exécutés pour trouver l’équilibre avec le solde de la version d’essai GL. En fonction de ce que vous avez trouvé, suivez la méthode appropriée :

-MÉTHODE 1 -SI CORRECTE : si vos rapports financiers sont corrects et correspondent à GL, vous pouvez passer aux étapes 2 à 8 de cet article, qui doivent tout de même être terminées afin de ne pas obtenir d’erreurs AA pendant le processus de clôture de l’année GL.

Remarque : si vous utilisez un système de rapports qui lit uniquement directement à partir des tables GL (par exemple, le fournisseur hérité dans Management Reporter lors de la lecture à partir d’une société GL ou d’un autre outil de rapports)] pour vos rapports financiers, vous pouvez continuer à l’étape 2, car les données des AA n’affectent pas vos rapports financiers.


MÉTHODE2 -SI NON CORRECT : Toutefois, si vos rapports financiers ne sont pas corrects, c’est probablement en raison des tables AA utilisées et des données AA ne correspondent pas aux données GL. Pour vérifier les données des AA, vous devez tout d’abord exécuter les scripts SQL fournis dans KB 2910626 en plus des autres étapes de cet article.  

Remarque : DataS dans Management Reporter lit à partir de tables AA (et GL), ou le fournisseur hérité utilisé avec Management Reporter peut lire à partir d’une entreprise AA.

Étapes de la méthode 2 :

a.) Tout d’abord, exécutez tous les scripts en base de 2910626 pour vérifier les données AA avec des données GL.   

Les rapports financiers du Management Reporter ne correspondent pas aux rapports de solde d’essai de General Ledger dans Microsoft Dynamics GP
http://support.microsoft.com/help/2910626

b.) Une fois que vous avez terminé les étapes de la 2910626, revenir à cette ko et poursuivre les autres étapes répertoriées ci-dessous. (Notez que les étapes 2 et 4 sont également au 2910626 de la Base de données, mais nous vous recommandons de vérifier à nouveau cette information, car elles ne doivent renvoyer aucun résultat si vous avez déjà corrigé ces données.)

 

ÉTAPE 2 : VÉRIFIER LES DONNÉES AA POUR LES ANNÉES SUPERPOSÉES

Exécutez ces scripts pour vous assurer que les années ne se chevauchent pas dans la table Open AAG30000 avec la table historique AAG40000. Chaque année distincte ne doit exister que dans une table ou l’autre, mais pas les deux.

select distinct(YEAR1) from AAG30000

select distinct(YEAR1) from AAG40000

-Si les années se chevauchent dans les deux tables, il est recommandé d’ouvrir un incident de support pour obtenir de l’aide. Le cas du support peut être chargé car ce problème est généralement créé à cause de l’importation d’enregistrements. Notez que si la correction des données est nécessaire, il peut être nécessaire de faire référence à des conseils, ce qui vous serait facturé.
 

ÉTAPE 3 : VÉRIFIEZ QUE LES ANNÉES ENTRE LES TABLES OUVERTES/HISTORIQUES CORRESPONDENT ENTRE AA/GL :

Assurez-vous ensuite que les années des tables AA sont dans les mêmes années ouvertes ou fermées que vos tables GL. Les tables ouvertes AAG30000 et GL20000 doivent avoir les mêmes années. Les tables historiques AAG40000 et GL30000 doivent contenir les mêmes années fermées.

select distinct(YEAR1) from AAG30000

select distinct(OPENYEAR) from GL20000

select distinct(YEAR1)from AAG40000 order by YEAR1

select distinct(HSTYEAR) from GL30000 order by HSTYEAR

-Si vous trouvez des années dans la table ouverte AAG30000 AVANT l’année que vous fermez, vous devez également suivre LES ÉTAPES POUR DÉPLACER LES DONNÉES VERS L’HISTORIQUE ci-dessous afin de déplacer les données de l’année historique vers l’historique. La table AAG30000 ne doit avoir de données que pour les années qui sont actuellement ouvertes dans GL. Si vous tentez de fermer l’année dans GL, vous êtes invité à envoyer le message suivant :  

Utilisez les scripts ci-dessus pour déterminer si vous devez exécuter les ÉTAPES POUR DÉPLACER LES DONNÉES VERS L’HISTORIQUE afin d’éviter que le message ci-dessus ne se produise pendant le processus de clôture de l’année.


ÉTAPES DE DÉPLACEMENT DES DONNÉES VERS L’HISTORIQUE :
La première fois que vous fermez GL sur une version supérieure à GP 10.0 SP2 ou version supérieure (avec AA activé), vous êtes invité à déplacer les données AA vers l’historique avant que le système ne vous autorise à fermer l’année GL. Le système vérifie que les données AA se trouvent dans la série ouverte/historique correspondante de tables AA, car les données GL se trouve dans les tables ouvertes/historiques dans GL. Si ce n’est pas le cas, vous recevrez un message pour exécuter l’utilitaire Déplacer vers l’historique pour AA avant de poursuivre la fermeture de l’année GL.  (Vous ne devez exécuter cette routine qu’une fois après la mise à niveau d’une version deGP 10.0,et vous ne devriez plus avoir à la exécuter.  Il s’agissait d’un processus une seule fois. Cet utilitaire ne corrigera pas les années dupliquées entre les tables AA ou les données endommagées ultérieurement.)

Rappelez-vous que si vous n’avez pas fermé l’année GL (avec l’AA activée) après l’installation d’un Service Pack plus tard que SP2 pour la version 10.0, ou après la mise à niveau vers GP 2010, vous pouvez recevoir un message indiquant « Vous devez consolider les transactions et transférer lesdétailsvers l’utilitaire d’historique pour fermer l’année ». Le code a été ajouté au processus de clôture, qui compare les années des tables ouvertes AA aux années historiques de la configuration de la période fiscale de la société. Si des données AA sont disponibles dans la série de tables AAG3000X pour une année historique, vous recevez le message d’erreur. Pour consolider ces années, suivez ces étapes :

1.) Dans le menu Microsoft Dynamics GP, pointez sur Outils,pointez sur Utilitaires,pointez sur Financial,pointez sur Analytical Accounting,puis cliquez sur Déplacer les données vers Historique.

2.) Par défaut, la plus ancienne année est le système trouvé dans les tables AAG3000x ouvertes. Vous ne pourrez déplacer qu’un an à la fois.

3.) Sélectionnez l’option appropriée : Transférer les détails des transactions vers l’historique – Cette option déplace les enregistrements de détails AA des tables ouvertes vers les tables historiques et aucune entrée BBF ne

sera créée. Vous devez vous assurer qu’il n’y a aucune entrée BBF dans les tables AA, sinon vous ne pourrez pas sélectionner cette option. Cette option déplace simplement les enregistrements des tables AAG30000 vers les tables AAG40000.

Consolider les transactions et les détailsde transfert à l’histor y – Cette option déplace les enregistrements de détails AA des tables ouvertes vers les tables historiques et crée des éléments d’extraction BBF. Toutefois, pour que les entrées BBF soient créées, les options mentionnées ci-dessus doivent être sélectionnées précédemment. Cette option consolide les soldes de tous les codes de dimension des transactions au cours de l’année fermée (marqués comme devant être consolidés) et transfère les informations AA vers les tables historiques.

Notez que les soldes consolidés sont mis à l’année suivante. Les entrées BBF sont créées à partir des années fermées.

Rapport d’aperçu avant transfert à l’impression uniquement – Cela vous permet d’afficher les transactions qui seront déplacées sans déplacer réellement les données. Le rapport d’aperçu affiche les consolidations à faire.

Remarque : cette option ne modifie pas les données.

4.) Cliquez sur OK.

5.) Répétez ce processus pour chaque année « historique ». (Où l’année se trouve dans la table AAG30000 ouverte, mais est dans la table d’historique GL30000. L’enregistrement ouvert AA avec l’ancienne année doit être déplacé vers la table de l’historique AA pour correspondre à l’enregistrement correspondant dans la table historique GL.)

Remarque : si vous réexécutez les scripts de l’année distincte dans l’ÉTAPE 3 ci-dessus, vous devez obtenir les années distinctes pour la correspondance entre les tables AA et GL ouvertes, ainsi que les tables AA et GL historiques.

 

ÉTAPE 4 : VÉRIFIER LA SUPERPOSITION DES ID D’EN-TÊTE DANS LES TABLEAUX AA

Exécutez ce script sur la base de données de l’entreprise pour voir si les mêmes ID d’en-tête existent également entre les tables :

select * from AAG30000 where aaGLHdrId in (select aagLHDrId from AAG40000)

- Si vous trouvez des tableaux d’ID d’en-tête en double, il est recommandé d’ouvrir un incident de support pour obtenir de l’aide. Le cas du support peut être chargé. Notez que si la correction des données est nécessaire, il peut être nécessaire de faire référence à des conseils, ce qui vous serait facturé.

Cela se produirait si vous restriez une ancienne base de données Dynamics au-dessus de la base de données Dynamics actuelle et si les prochains nombres disponibles stockés dans la table AAG00102 de la base de données Dynamics sont rétablis. Gp continue à incrémenter à partir de ces valeurs, même si elles ont peut-être déjà été utilisées et entraînerait l’utilisation de la même valeur aaGLHdrID pour différentes valeurs YEAR1.
 

ÉTAPE 5 : METTRE À JOUR LES VALEURS AACOPYSTATUS

Vérifiez ensuite si une valeur d’aacopystatus incorrecte est incorrecte dans la table AAG40001. Exécutez ce script :

select count(*) from AAG40001 where aaCopyStatus<>8 

Si le script ci-dessus renvoie des résultats, vous pouvez mettre à jour aaCopyStatus sur « 8 » avant d’exécution de la fermeture de l’année GL : (La valeur de « 8 » est une valeur acceptée par le processus de clôture de fin d’année.)

update AAG40001 set aaCopyStatus=8

ÉTAPE 6 : EXAMINER LA CONFIGURATION DES DIMENSIONS À INCLURE À LA FIN DE L’ANNÉE

Utilisez les deux étapes ci-dessous pour activer l’option Entreprise afin d’inclure les dimensions AA dans la fermeture de l’exercice, puis pour marquer les dimensions individuelles que vous voulez inclure dans la fermeture de l’exercice. Cela entraîne des entrées dans la table AAG30003 avec les mêmes entrées aGLHdrID que les entrées BBF dans les tables AAG30000/AAG30001/AAG30002. Il s’agit d’un processus en deux étapes comme suit :

Si vous n’avez pas encore fermé General Ledger, suivez ces étapes pour vous assurer que la dimension est marquée correctement pour être incluse dans le processus de clôture :

1. Marquez l’option de configuration pour inclure La comptabilité analytique à la fin de l’exercice comme suit :

   1. Dans le menu Microsoft Dynamics GP,pointez sur Outils,pointez sur Configuration,sur Société,sur Comptabilitéanalytique, puis cliquez sur Options.

   2. Cochez la case Inclure dans la fin de l’année, puis cliquez sur OK.
      
      
      Remarque Cette option permet uniquement d’activer la fonctionnalité permettant de créer des entrées De l’équilibre vers l’avant aux dimensions. Les données Analytical Accounting seront toujours dirigées vers les tables des séries AAG40000 lorsque General Ledger sera fermé, que cette option soit marquée ou non.

2. Marquez individuellement les dimensions à inclure à la fin de l’exercice comme suit :

   1. Dans le menu Cartes, pointez sur Finances,pointez sur Comptabilité analytique,puis cliquez sur Dimension de transaction.

   2. Dans la liste Dimension Trx, cliquez sur la dimension que vous voulez inclure dans le processus de clôture de l’année.

   3. Dans la zone Clôture de l’année, cochez la case Consolider les soldes lors de la fermeture de l’année, puis cliquez sur Enregistrer.

   4. Répétez les étapes b et c pour chaque dimension que vous voulez inclure dans le processus de clôture de l’année.

Remarque : si vous utilisez la fonction MR et que les case à cocher ci-dessus ne sont pas marquées, les montants du solde de début risquent d’être manqués si les données de dimension AA BBF n’ont pas été créées à la fin de l’année et que vous créez des rapports sur des données AA. 



ÉTAPE 7 : VÉRIFIER LE COMPTE MAÎTRE AA

Il est toujours bon de vérifier que la table maître de compte AA (AAG00200) correspond à la table maître de compte GL (GL00100) avant de traiter la fin de l’année. Si des comptes sont manquants, les entrées BBF dans AA sont incorrectes. Exécutez les scripts ci-dessous sur la base de données de l’entreprise pour vérifier que les tableaux de base de comptes GL, GL Account Index Master et AA Account Master ont tous le même nombre d’enregistrements :

select count(*) from GL00100

select count(*) from GL00105

select count(*) from AAG00200

• Si la table maître compte AA possède MOINS d’enregistrements que la table GL00100, utilisez le script ci-dessous pour insérer les comptes GL manquants :

insert into aag00200 
ACTINDX, aaAcctClassID,aaChangeDate,aaChangeTime)
select ACTINDX, 0, convert(char(10),getdate(),111), convert(char(12),getdate(),114)
from GL00100 where ACTINDX not in (select ACTINDX from aag00200)

• Si la table maître de compte AA possède PLUS d’enregistrements que la table GL00100, utilisez le script ci-dessous pour supprimer les enregistrements supplémentaires :

Delete AAG00200 where ACTINDX not in (Select ACTINDX from GL00100)

• Si la table GL00105 ne correspond pas, voir

La 855963 pour savoir comment recréer la table d’index maître (GL00105). 





ÉTAPE 8 : VÉRIFIER L’INVERSION DES ENTRÉES GL/AA (GP2015/GP2016 UNIQUEMENT)

Des problèmes ont été signalés lors de l’inversion d’entrées gl en rapport avec la publication d’une année historique dans chaque version, comme indiqué ci-dessous.  Exécutez le script ci-dessous sur la base de données de l’entreprise.  Examinez les résultats comme indiqué pour chaque version.  Si une assistance est nécessaire, ouvrez un cas de support et référencez les problèmes de qualité. 

Exécutez ce script pour examiner toutes les entrées d’inversion publiées sur une année historique. 

--------------------------------

Select distinct(a.JRNENTRY) from GL20000 a rejoindre GL30000 b
on a.JRNENTRY = b.JRNENTRY
où a.SOURCDOC = 'GJ'
et a.TRXSORCE comme 'GLREV%'
et b.TRXSORCE comme 'GLTHS%'

----------------------------------

Examinez les résultats comme indiqué ci-dessous pour la version que vous utilisez :

Microsoft Dynamics GP 2016 (problème de qualité #91834)

 Comparez les enregistrements entre les tables GL et les tables AA pour chaque JE# renvoyée ci-dessus, car les résultats peuvent varier en fonction de l’utilisation des comptes P&L et de leur niveau de transaction ou de leur niveau publié.  Les mises à jour manuelles nécessaires peuvent être : 

• Mettez à jour la seQNUMBR dans la table GL20000 pour que l’entrée « GLREV » corresponde à SEQNUMBR dans la table AAG30001. (Si vous utilisez la référence MR, vous devez utiliser la référence SEQNUMBR de la table AA pour que MR le lisent.)

• Mettez à jour ACTINDX dans la table AAG30001 pour que l’entrée « GLREV » corresponde à ACTINDX dans la table GL20000. (L’index du compte des revenus conservés est incorrectement présenté dans le tableau AA sur l’entrée inversion.)

• Vérifier la somme des enregistrements d’AAG30002 est égale à la somme des enregistrements d’AAG30001 pour les enregistrements aaGLHdrID du JE.

Ouvrez un cas de support et référencez le problème de qualité #91834 si une assistance est nécessaire. 

MISE À JOUR : Ce problème a été résolu dans l’correctif rapide de janvier pour GP 2016 (16.00.0675) et GP 2018 (18.00.0438). 

Microsoft Dynamics GP 2015 (problème de qualité #88914)

Examinez les tables AA pour chaque je# renvoyée ci-dessus.  Les mises à jour manuelles nécessaires peuvent être :

• Vérifier la somme des enregistrements d’AAG30002 est égale à la somme des enregistrements d’AAG30001 pour les enregistrements aaGLHdrID du JE.

• Examinez les tables AAG30000 et AAG40000 pour chaque je# renvoyée.  Recherchez les enregistrements pour l’entrée « GLREV » dans les deux tables de la série AAG30000. Les enregistrements AA pour l’entrée « GLREV » ne doivent se trouve dans les tables AAG30000 que si l’entrée d’inversion est de la nouvelle année et ne doit pas être dans les tables de la série AAG400000.  Ces enregistrements dupliqués entraîneraient le surétat de rapports MR en cas de rapports sur AA.

Ouvrez un cas de support et référencez le problème de qualité #88914 si une assistance est nécessaire. 

MISE À JOUR : Ce problème a été résolu dans la version GP 2016 RTM.   

ÉTAPE 9 - AA BBF INCORRECT (****Problème connu pour GP 2016 uniquement***)

**REMARQUE IMPORTANTE POUR LES UTILISATEURS DE DYNAMICS GP 2016***

**Vous devez être sur le dictionnaire des gp 16.00.0675 ou supérieur (ou le dictionnaire AA 16.00.0645 ou une valeur supérieure) avant de fermer votre Dynamics GP 2016 afin de pouvoir avancer les soldes de début corrects**

Il existe un problème de qualité connu # 91502 lorsque vous fermez votre année GL avec AA.  Si vous avez des comptes GL avec un solde de 0 $ et si vous faites avancer les codes AA, les codes AA BBF ne sont pas corrects.  Ce problème ne se trouve pas dans GP 2015 ou GP 2013.  

Un correctif a été inclus pour ce problème dans la mise à jour des correctifs de décembre (KB 4056559) pour Microsoft Dynamics GP 2016.  Bien que la publication de décembre soit appelée mise à jour de fin de l’exercice2017des salaires canadien, elle doit être installée par tous les clients aux États-Unis qui ont besoin de ce correctif AA BBF inclus.  Il est vivement recommandé d’installer cette mise à jour du correctif de décembre avant de fermer votre gl si vous utilisez aA et avez des comptes GL avec un solde zéro, pour toutes les installations (États-Unis, Canada, etc.) qui utilisent AA. 

Notez que la version 16.00.0641 de Dynamics GP ne change pas entre la mise à jour du Year-End Update 2017 des États-Unis (version de novembre/KB 4046341) et la mise à jour du Year-End des salaires du Canada 2017 (mise à jour de décembre/4056559). Toutefois, le dictionnaire AA va mettre à jour de 16.00.0552 à 16.00.0645. (Consultez le groupe d’aide | À propos de Microsoft Dynamics GP | | À propos de la comptabilité analytique.) Vous aurez besoin du code AA dans la version de décembre pour résoudre ce problème AA/BBF. 

ÉTAPE 10 : EXÉCUTER LA FERMETURE DU TEST

Effectuer toujours une sauvegarde actuelle avant de commencer le processus de clôture de l’année GL. Nous vous recommandons de tester d’abord l’exécution de la fin de l’année d’une entreprise de test pour vous assurer que vous ne recevez pas d’erreurs. Le processus de clôture de fin d’année GL permet de créer les entrées de journal de rapport de rapport de l’équilibre (BBF) et de déplacer les enregistrements de l’année que vous fermez dans les tables General Ledger et Analytical Accounting. Les entrées BBF sont créées dans les tables GL et AA. Reportez-vous au processus décrit dans la 888003 de clôture de l’exercice pour General Ledger.

Pour plus d’informations, cliquez sur le numéro d’article suivant pour le consulter dans la Base de connaissances Microsoft :

888003 Year-End procédures de clôture de General Ledger dans Microsoft Dynamics GP

-----------------------------------------------------------------------------------------------
REMARQUE : La clôture de l’année avec AA SQL 2019 échoue
Si vous utilisez GP 18.2 avec SQL 2019 et AA chargés, la fermeture de la fin de l’année d’GL échouera, avec le message suivant : (Les versions SQL antérieures fonctionnent parfaitement.  Elle échoue uniquement le SQL 2019.  Ce problème a été résolu dans le correctif hot de février 2020. Pour plus d’informations, consultez le BLOG AA YE.)

« Erreur interne : la limite des services d’expressions a été atteinte. Recherchez les expressions potentiellement complexes dans votre requête et essayez de les simplifier. »  

------------------------------------------------------------------------------------------------

ÉTAPE 11 : VÉRIFIER SI L’AUTORISATION « COMPTES UNITAIRES » EST EFFACÉE (GP 2013/GP 2015 uniquement - #86400)

Si vous utilisez Microsoft Dynamics GP 2015 ou Microsoft Dynamics GP 2013 et que vous avez marqué la case à cocher sur les comptes unitaires comme « Effacer le solde pendant la fermeture de Year-End» , il est possible que les enregistrements du tableau AAG30002 soient toujours de valeurs incorrectes et doivent être 0,00 pour correspondre au tableau AAG30001.  (Ce problème a été résolu dans Microsoft Dynamics GP 2016.)

Pour vous assurer que les soldes de compte unitaire sont corrects dans les tables AA, exécutez le premier script ci-dessous sur la base de données de l’entreprise après l’exécuter pour vous assurer que la valeur BBF du compte unitaire est définie sur zéro si elle a été marquée comme effacée.  Utilisez le deuxième script pour mettre à jour les résultats.

select b.ACTINDX, c.aaGLHdrID, c.aaGLDistID, c.DEBITAMT, c.CRDTAMNT, c.ORDBTAMT, c.ORCRDAMT
from AAG30002 c inner join AAG30001 b
on b.aaGLHdrID = c.aaGLHdrID and
b.aaGLDistID = c.aaGLDistID
inner join GL00100 d on
b.ACTINDX = d.ACTINDX
where d.Clear_Balance = 1 and b.ACCTTYPE = 2 and b.SOURCDOC = 'BBF' 
and (c.DEBITAMT <> 0 or c.CRDTAMNT <> 0 or c.ORDBTAMT <> 0 or c.ORCRDAMT <> 0)

update c set c.DEBITAMT = 0, c.CRDTAMNT = 0, c.ORDBTAMT = 0, c.ORCRDAMT = 0 
from AAG30002 c inner join AAG30001 b
on b.aaGLHdrID = c.aaGLHdrID and
b.aaGLDistID = c.aaGLDistID
inner join GL00100 d on
b.ACTINDX = d.ACTINDX
where d.Clear_Balance = 1 and b.ACCTTYPE = 2 and b.SOURCDOC = 'BBF'
and (c.DEBITAMT <> 0 or c.CRDTAMNT <> 0 or c.ORDBTAMT <> 0 or c.ORCRDAMT <> 0)

ÉTAPE 12 : VÉRIFIER LES RAPPORTS DE LA FEUILLE DE SOLDE

Il est recommandé de comparer le rapport Du solde dans Management Reporter au rapport Solde d’essai de General Ledger de Microsoft Dynamics GP, pour vérifier que les soldes du compte transmis à la nouvelle année sont corrects. Si ces soldes ne correspondent pas, restituer votre sauvegarde et contacter le support de Microsoft Dynamics GP pour ouvrir un incident de support pour obtenir de l’aide supplémentaire.

INFORMATIONS INTERNES MICROSOFT

Date de la dernière mise à jour : 03/12/2021 - cw
Auteur : dspe contrôle; réécrit le 02/12/2012 par cwasgraphi, 19/09/2013 - Ajouté à l’étape 3 par kenhub/cwasgraph.
Writer : lmuelle
Réviseur technique :szree
Éditeur : v-andmck