Partager via

« Vous ne pouvez pas transférer les encumbrances pour XXXX lorsqu’il existe des montants d’encumbrance en attente pour un exercice précédent . » s’affiche dans Microsoft Dynamics GP (Blog)

Cet article fournit une solution à une erreur qui se produit dans Microsoft Dynamics GP.

S’applique à : Microsoft Dynamics GP
Numéro de l’article de la base de connaissances d’origine : 4567109

Problème

L’article de blog est disponible ici.

La fenêtre de transfert d’encumbrance de fin d’année est utilisée pour transférer les soldes d’encumbrance sur les bons de commande ouverts (POS) de l’année en cours à l’année suivante. Le processus de transfert liquide automatiquement les montants inutilisés de l’année en cours et met à jour les bons de commande ouverts avec les montants restants qui seront remis l’année prochaine.

La fenêtre de transfert d'encumbrance de fin d'année se trouve en accédant à Achats > Routines > Transfert d'encumbrance de fin d'année.
Lors de l’exécution de ce processus, vous pouvez recevoir l’erreur suivante :

Vous ne pouvez pas transférer les encumbrances pour XXXX lorsqu’il y a des montants d’encumbrance en attente pour un exercice précédent

La cause

Il existe de nombreuses raisons de rencontrer l’erreur.

  1. Parfois, les utilisateurs ont rétrodéfini une transaction qui s’est déroulée dans un délai d’un an qui a déjà été transférée. Dans ce cas, vous devez simplement revenir à cette année de la transaction et transférer ces anciennes valeurs de transaction. D’autres fois, ce n’est pas aussi simple.
  2. Il existe de nombreux tiers, intégrations et personnalisations qui s’intègrent au traitement des bons de commande, et parfois les données peuvent ne pas être dans un état attendu par Microsoft Dynamics GP, provoquant ainsi l’erreur.
  3. En outre, si vous avez rencontré des interruptions avec la publication, les données peuvent être endommagées, ce qui peut entraîner l’erreur. Dans ces cas, le problème peut être lié à la table ENC10111, car elle n’a peut-être pas tous les ins et sorties de la transaction. Il est également possible que les données de bon de commande en général sont endommagées à l’origine du transfert du bon de commande.

Résolution

Il existe quelques options pour essayer de résoudre cette erreur. Je vous recommande toujours de déplacer une copie de vos données LIVE dans une société TEST pour les tests. Ce blog suppose que l’utilisateur qui exécute ces étapes est familiarisé avec les données d’encumbrance et de bon de commande et la façon dont les tables doivent se présenter dans le back-end. Si vous n’êtes pas familier, vous devrez peut-être contacter votre partenaire ou créer un cas de support pour obtenir de l’aide. Dans un cas de support, nous pouvons aider avec un ou deux bons de commande problématiques et donner des conseils, mais si vous rencontrez des problèmes avec plus d’un couple de commandes, vous devrez peut-être créer des cas distincts pour chaque bon de commande, car chacun d’eux peut avoir une condition différente qui nécessite une analyse distincte des données.

OPTION 1 : Exécutez le transfert de fin d’année pour chaque année passée afin de vous assurer qu'il n'existe pas de bon de commande saisi ou engagé dans une année précédente qui doit être transféré.

Accédez aux routines d'achat> transfert d'encumbrance de fin d'année>.
Commencez par l’année en cours, puis continuez à reculer l’année par année pour déterminer s’il existe un bon de commande qui doit être transféré. S’il existe un bon de commande qui est « bloqué » et continue de rester sur le rapport même après le transfert, ce bon de commande doit être creusé en exécutant le script ALL PO et Receipt (lien listé plus loin dans ce blog) pour déterminer ce qui est incorrect avec le bon de commande. Beaucoup de fois, la ENC10111 n’est pas dans l’état approprié qui fait que le bon de commande ne passe pas à l’année suivante. Si c’est le cas, vous pouvez exécuter l’option 4 pour obtenir le transfert du bon de commande.

OPTION 2 : Supprimez les PO terminées et supprimez l’historique.

Utilisez cette option si vous disposez d’une condition de données spécifique dans laquelle un bon de commande sur le rapport de transfert ne déplace pas et que le bon de commande est dans un état fermé ou annulé. Il peut être que le bon de commande est endommagé et doit simplement être supprimé de la stratégie de groupe. Si vous êtes d’accord avec cette option, procédez comme suit.

  1. Accédez à Utilitaires > d'achat > Supprimer l’historique des achats, ce qui vous permettra de supprimer le bon de commande, le reçu, la distribution de compte et l’historique des journaux pour le bon de commande endommagé. Je sais qu’il peut sembler radicale, mais à ce stade, le bon de commande est endommagé et est fermé ou annulé, il n’y a rien qui peut être fait avec eux à l’avance, à l’exception de les fixer un par un. Par conséquent, la suppression peut être la meilleure option à essayer.

    • Remarque

      Si votre bon de commande n’est pas dans l’historique à supprimer, utilisez la routine Supprimer le bon de commande terminé pour déplacer le bon de commande vers le fichier d’historique. Accédez à routines > d'achat> Supprimer les bons de commande terminés.

    • Le rapport de suppression de bon de commande terminé s’affiche une fois le processus terminé. Si une commande d’achat n’est pas supprimée (par exemple, si elle est en cours d’utilisation ou a des données endommagées), un message s’affiche sur le rapport de suppression de bon de commande terminé indiquant que le bon de commande n’a pas été supprimé. Dans ce cas, vous devez passer en revue les résultats du script ALL PO et reçus pour déterminer ce qui est incorrect et le corriger ou le supprimer via le serveur principal. Si elle passe à l’historique, vous passez à l’étape suivante.
    • Vous pouvez maintenant utiliser la fenêtre Supprimer l’historique des achats pour supprimer l’historique des bons de commande.

  2. Ensuite, exécutez l’outil pour réparer les données ENC. (menu Microsoft Dynamics GP > Maintenance > Gestion des engagements > Maintenance de routine) Vous devez utiliser le Détail basé sur le bon de commande, puis Résumé basé sur le détail.

  3. Réessayez de transférer l’année, si vous obtenez toujours l’erreur, continuez avec les étapes de vérification des données qui sont OPTION 3.

OPTION 3 : Script de vérification des données

Nous avons un script ci-dessous que vous pouvez utiliser pour essayer d’identifier le ou les points de commande coupables à l’origine de l’erreur de transfert. De nombreux PO peuvent figurer dans la liste retournée, mais se concentrer sur le premier retourné qui est répertorié. Tous les POS répertoriés ne sont pas nécessairement mauvais. Il s’arrête juste après qu’il identifie le premier bon de commande endommagé et répertorie le reste après cela. Si nous corrigeons le premier bon de commande endommagé, l’espoir est le reste du bon de commande supprimé de la liste et le transfert passe sans problème. Si ce n’est pas le cas, vous devez répéter le processus jusqu’à ce que la liste soit effacée.

L’action de l’option 3 sera la suivante :

  1. Exécutez le script ci-dessous,
  2. Exécutez le script ALL PO et Receipt dans la première commande de la liste.
  3. Corrigez les données du premier bon de commande dans la liste,
  4. Réessayez le transfert.

Vous devez d’abord trouver une année qui n’a aucun POS affecté. Pour ce faire, vous devez identifier deux choses.

  • Déterminez si vous êtes une année fiscale ou civile. C’est important! Accédez à Administration >> Paramètres >> Entreprise >> Périodes Fiscales; notez les dates de début et de fin des années.
  • Quelle année obtenez-vous l’erreur lors de l’exécution du transfert de fin d’année ? Par exemple, si vous transférez 2017 à 2018, notez que.

Une fois que vous connaissez #1 et #2, vous pouvez maintenant exécuter le script ci-dessous pour trouver le ou les points de commande problématiques. Pour exécuter le script, vous devez l’exécuter pour une plage de dates qui correspond à vos années fiscales/civiles, plus 1 jour supplémentaire.

Utilisez le script ci-dessous. La clé entre les dates correctes.

Si vous êtes calendrier, vous serez 1/1/2017 au 1/1/2018. Supposons que vous êtes configuré pour un exercice fiscal à partir de mai1st, au lieu de cela, c’est mon exemple ci-dessous.

Si ma première période a commencé le 1er mai 2017 et que l’année s’est terminée le 30 avril 2018, mon script ressemblerait à ceci :

declare @FROM varchar(10) set @FROM ='05/01/2017'
declare @TO varchar(10) set @TO ='05/01/2018'
declare @FROMDATE DATETIME set @FROMDATE = CONVERT(DATETIME, @FROM, 101)
declare @TODATE DATETIME set @TODATE = CONVERT(DATETIME, @TO, 101)
select *
from ( select ENC10110.PONUMBER, ENC10110.POLNENUM,
ENC10110.ENCBSTAT, ENC10110.INVINDX,
ENC10110.REQDATE,
(SUM(ENC10111.ENCMBAMT) - ISNULL(
(
select SUM(LIQUDAMT)
from ENC10500
where (GLPOSTDT>=@FROMDATE and GLPOSTDT<@TODATE) AND
ENC10110.PONUMBER = ENC10500.PONUMBER AND
ENC10110.POLNENUM = ENC10500.POLNENUM),0)
) AS REMAMT
from ENC10111
inner join ENC10110
ON ENC10111.PONUMBER = ENC10110.PONUMBER AND
ENC10111.POLNENUM = ENC10110.POLNENUM
where (ENC10111.TRXDATE>=@FROMDATE and ENC10111.TRXDATE<@TODATE) AND
ENC10110.ENCBSTAT<>3
  GROUP by  ENC10110.PONUMBER, ENC10110.POLNENUM,
      ENC10110.ENCBSTAT, ENC10110.INVINDX,
      ENC10110.REQDATE
) AS ENC
where REMAMT<>0

La clé est de comprendre les dates que vous devez exécuter. Si vous n’utilisez pas les restrictions de date correctes, vous pouvez obtenir des résultats que vous pensez incorrects, mais en fait ils sont corrects et uniquement affichés en raison de la façon dont vous avez exécuté les restrictions de date. Je vous recommande toujours de commencer par l’année que vous essayez de transférer, puis de revenir l’année après l’année jusqu’à ce que vous ne receviez aucun résultat. Si vous utilisez le dernier exemple de configuration, vous commencerez par :

declare @FROM varchar(10) set @FROM ='05/01/2017'
declare @TO varchar(10) set @TO ='05/01/2018'

Ensuite, procédez comme suit :

declare @FROM varchar(10) set @FROM ='05/01/2016'
declare @TO varchar(10) set @TO ='05/01/2017'

Ensuite, procédez comme suit :

declare @FROM varchar(10) set @FROM ='05/01/2015'
declare @TO varchar(10) set @TO ='05/01/2016'

Et ainsi de suite, jusqu’à ce que les résultats soient nuls. Si je n’ai reçu aucun résultat pour 2015 à 2016, j’exécuterais le script précédent pour 2016 à 2017 et c’est là que je commencerais à résoudre les problèmes. L’objectif de l’exercice est de trouver où le problème a commencé. Là encore, en règle générale, vous obtenez les résultats des scripts ALL PO et Receipt pour le premier bon de commande dans la liste et passez en revue les données pour déterminer ce qui est incorrect. Une fois que vous avez déterminé le problème et résolu les données, vous devriez être en mesure de réexécuter la maintenance de routine d’encumbrance, puis de transférer l’année.

IL EST IMPÉRATIF QUE tous les utilisateurs d'Encumbrance se trouvent sur une version de GP égale ou supérieure à 11.00.1799.

Remarque

Le support peut vous aider à résoudre un ou deux problèmes et à examiner les données pour donner des conseils sur la façon de les résoudre, mais si vous avez de nombreuses POS, vous devrez travailler avec votre partenaire pour résoudre les données ou créer des cas distincts pour faciliter l’analyse des problèmes de données. Chaque bon de commande comporte de nombreuses tables pour analyser de sorte qu’une ou deux commandes d’achat dans un cas de support soit acceptable pour creuser, mais après cela, le cas est plus de conseil et a besoin de l’assistance de votre partenaire pour travailler.

Instructions pour collecter le script ALL PO et Receipts.

Script trouvé ici

Exécutez-le en texte à l’aide d’instructions ci-dessous.

L’objectif de cette instruction est d’examiner toutes les données relatives à un bon de commande spécifique. Il s’agit uniquement d’une instruction SELECT. Elle ne met pas à jour/supprime les données.

declare @PONUMBER char(20)
select @PONUMBER = 'POXXXX'
  1. Entrez votre numéro de bon de commande à la place de POXXXX dans le script.
  2. Appuyez sur (Ctrl + T) ou sélectionnez le bouton Résultats vers le texte dans la barre de menus avant d’exécuter pour envoyer les résultats au texte.
  3. Exécutez les résultats sur votre base de données d’entreprise.
  4. Cliquez avec le bouton droit sur les résultats, puis enregistrez sous .rpt.

OPTION 4 : Supprimez les données dans l'ENC10111 pour des commandes d’achat spécifiques (ou toutes les ENC10111) qui sont endommagées, exécutez un rapprochement sur l'engagement et réessayez le transfert.

  1. Exécutez l’outil pour réparer les données pour voir si l’outil corrige l’un des POS. Voyez ensuite si le transfert passe. (menu Microsoft Dynamics GP > Maintenance > Gestion des engagements > Maintenance de routine) Vous devez utiliser le détail en fonction du bon de commande, puis résumé en fonction du détail. Si ce n’est pas le cas, passez à l’étape 2.

  2. Supprimez la table ENC10111 en exécutant la commande IN TEST suivante. Je tiens à souligner que vous pourriez supprimer des données qui sont correctes dans cette étape, mais que vous avez toujours l’intégrité des tables de po si la recherche doit être effectuée pour une raison quelconque. La raison pour laquelle le transfert ne peut pas s'effectuer est qu’il existe une différence entre les tables ENC, et c’est le moyen le plus simple de l'écarter. GP remplacera cette table par des montants nets pour chaque bon de commande.

    -----------------
 DELETE ENC10111
-----------------

    Remarque

    Si vous n’avez qu’une seule commande qui ne transfère pas ou efface le rapport de transfert, vous pouvez spécifier le bon de commande spécifique à supprimer.

    DELETE ENC10111 WHERE PONUMBER = 'XXX'

  3. Une fois les données de la table supprimées, exécutez l’utilitaire pour remplir à nouveau la table ENC10111. (Menu > Microsoft Dynamics GP Maintenance > Encumbrance Management > Routine Maintenance). Vous allez utiliser le détail en fonction du bon de commande , puis résumé en fonction des détails et réessayer le transfert de fin d’année.

  4. Si vous rencontrez toujours des problèmes avec le transfert, utilisez le script de vérification des données à partir d’OPTION 3 et vérifiez si cette commande est répertoriée. Ensuite, passez aux étapes décrites dans cette option pour corriger les données.

L’objectif ultime est d’exécuter le script dans l’option 3, l’année par année et d’avoir aucune donnée retournée, ce qui signifie que le processus de transfert de fin d’année peut être traité sans erreur.

OPTION 5 : Désactiver et réactiver l’encumbrance

S’il existe une grande quantité de corruption trouvée, la meilleure option peut être d’envisager de désactiver l’encumbrance, de déplacer toutes les commandes d’achat fermées/annulées vers l’historique, puis de réactiver l’encumbrance.

Remarque

Pour déplacer des POs fermés/annulés vers l’historique, utilisez la routine Supprimer le bon de commande terminé pour déplacer le bon de commande vers le fichier d’historique. Accédez à Routines > d’Achat > Supprimer les Bons de Commande Terminés.

Vous ne perdez pas les données de traitement de bon de commande tant que vous êtes configuré pour conserver l’historique dans l’installation pop. Vous perdez seulement quelques-uns des anciens détails de l’encumbrance des années historiques pour Pos qui sont dans l’histoire. Vous serez toujours laissé avec les encumbrances en suspens actuelles pour les années actuelles pour lesquelles vous avez ouvert des commandes d’achat.