Les exécutions d’amortissement expliquées en détail

Si vous devez exécuter l’amortissement par code d’entreprise, le code t AFAB (Nom du programme RAPOST2000) peut être exécuté. Le programme RAPOST2010 permet la sélection de plusieurs codes d’entreprise. Les variables de sélection de rapport peuvent être conservées dans la table TVARV pour ces deux programmes et peuvent être planifiées à l’aide du gestionnaire de planificateur.

Exécution d’imputation planifiée

L’Exécution d’imputation planifiée est l’exécution périodique standard pour afficher l’amortissement planifié. Cela doit être utilisé lorsque le dernier cycle d’amortissement a réussi et qu’il est temps d’effectuer le cycle d’amortissement dans le cadre du nouveau processus de clôture de période. Le système vérifie que la période de publication est celle qui suit la dernière période de publication réussie ; ces informations sont ensuite enregistrées dans le tableau T093D, dans les champs AFBLPE (période) et AFBLCJ (année). De plus, l’état d’une exécution d’amortissement est également mis à jour dans le tableau TABA. Les noms de champs dans TABA sont « Indicateur de publication de document – XBUKZ et Période au cours de laquelle la dernière dépréciation a été enregistrée – AFBLPE. Veuillez noter que l’entrée TABA est créée en premier pendant le processus de publication. La table T093D est mise à jour comme l’une des dernières étapes. Cependant, veuillez noter que la table T093D ne serait pas mise à jour pour les tests. De plus, le tableau ANLP stocke les valeurs d’amortissement de chaque cycle d’amortissement. Le champ NAFAZ a de la valeur à afficher à partir de cette course d’amortissement.

Redémarrage

L’exécution de redémarrage ne serait utilisée que si l’exécution de comptabilisation de l’amortissement s’est terminée pendant le traitement en raison d’une panne ou d’une erreur du système. Si l’exécution de publication s’est terminée pour des raisons techniques et que des modifications ont déjà été apportées à la base de données, le rapport d’exécution d’amortissement doit être démarré en mode redémarrage.

Par exemple, lorsqu’un actif a un WBS fermé ou un centre de coûts invalide, le système effectue une comptabilisation dans le sous-grand livre des immobilisations (en mettant à jour les tables ANLC / ANLP), mais la tâche n’a pas été postée à G / L. En d’autres termes, le programme a échoué les écritures à G / L, d’où une incohérence créée à ce moment entre FI-AA et FI-GL, au moins jusqu’à ce que le redémarrage de l’amortissement soit à nouveau exécuté. Si le WBS ou le Centre de coûts est corrigé dans le maître de l’actif, le redémarrage réinitialisera les tables et exécutera l’exécution de publication prévue, à partir du point où elle a été interrompue. Cela effacera toute base de données d’éventuelles incohérences. L’utilisation du mode de redémarrage garantit que toutes les activités du système qui ont été interrompues par la fin sont répétées. L’entrée TABA de la table doit exister à ce stade, mais le redémarrage ne crée pas de nouvelle entrée TABA. Si le champ TABA-XBUKZ a une valeur de « 1 », cela signifie que le mode de redémarrage est requis. Après avoir résolu une ou plusieurs erreurs, le champ sera remplacé par « X », ce qui signifie qu’il a été posté avec succès. Si TABA-XBUKZ a une valeur de « N », il n’est pas encore affiché.

Remarque : Cela affecte uniquement les actifs qui n’ont pas été exécutés avec succès lors de l’exécution précédente.

Repeat

L’exécution répétée est utilisée pour répéter l’exécution de publication au cours de la dernière période publiée. La répétition serait utilisée si des modifications ont été apportées après l’affichage de l’amortissement de la période.

Par exemple, disons les termes d’amortissement (par ex. une durée de vie utile de l’actif) sont modifiées dans les données de base de l’actif ou les nouvelles transactions enregistrées (par exemple, les transferts d’actifs). Par conséquent, il est nécessaire de se déprécier au cours de la période en cours pour les modifications apportées. Le système recalcule l’amortissement pour la période, soustrait l’amortissement déjà affiché, puis ne poste que la différence. Cela peut être limité à des actifs spécifiques qui peuvent être répertoriés sous paramètres pour le test ou pour tous les actifs dans le code de la société. De plus, l’opération de publication répétée peut être utilisée si des actifs supplémentaires ont été réglés après la fin de l’opération de publication prévue. Un exemple serait l’allocation a été exécutée, ce qui a entraîné la création d’actifs supplémentaires. Une exécution répétée pourrait alors être traitée uniquement pour ces numéros d’actifs spécifiques ou pour un seul actif.

Remarque : Lors d’une exécution de publication répétée, le système ne publie que les différences résultant de la première exécution de publication et de l’exécution de publication répétée, c’est-à-dire qu’il n’y a pas de double publication ou d’écrasement de publication existante.

Exécution de publication non planifiée

L’exécution de publication non planifiée permet de publier en dehors du cycle de traitement normal (par exemple mensuel). Cette option n’est pas la même que l’amortissement imprévu. Plusieurs périodes peuvent être postées en une seule exécution avec cette option. En réglant cet indicateur, le système ne vérifie pas la connexion à la période précédente et permet de sauter des périodes. Cela peut être une option utile à des fins de test pour l’estimation ou la validation d’un calcul d’amortissement, mais cette option n’est généralement pas recommandée.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.