Accueil Blog (en) Changements dans Acumatica Multicurrency pour les développeurs

Changements dans Acumatica Multicurrency pour les développeurs

Nous passons en revue les récents changements apportés par Acumatica à la multidevises qui affectent les personnalisations des développeurs apportées à Acumatica Cloud ERP. Il est important pour les développeurs et les consultants de 3ème partie d’examiner ces changements.
Sergueï Nikomarov | Le 23 mars 2022

Changements dans Acumatica Multicurrency pour les développeurs

Introduction

Les équipes de développeurs de logique métier d’Acumatica retravaillent la mise en œuvre multidevises depuis un certain temps maintenant pour la rendre plus facile à comprendre et à personnaliser. Avec ce travail, il y a des changements importants dans la fonctionnalité de notre implémentation multidevises qui affectent les développeurs que nous pensons qu’il est important de partager avec vous.

Nouvelle extension de graphique

We have a new generic graph extension: MultiCurrencyGraph<TGraph, TPrimary> that stores the common multicurrency logic. From this graph extension developers should derive their specific currency graph extension to support multicurrency in their graph. The details of this process are described in this article from Acumatica help portal:

API de plate-forme: Implémentation de la prise en charge multidevises sur un formulaire personnalisé

Cependant, le passage à la nouvelle logique peut nécessiter quelques modifications de la part des développeurs partenaires. Les modifications vous affecteront s’il y a des champs DAC dans vos DAC personnalisés ou extensions DAC qui stockent de l’argent dans une devise. Dans ce cas, vous devez revoir votre code et l’ajuster à ces modifications. De plus, cela peut être particulièrement important pour les développeurs de personnalisation qui intègrent leur code aux modules Acumatica.

Aperçu des changements

Pour montrer pourquoi il est important, je dois d’abord faire un aperçu des changements dans la multidevise.

Il existe désormais deux ensembles d’attributs de devise pour les champs DAC. Les anciens attributs se trouvent dans l’espace de noms PX.Objects.CM et le nouvel ensemble se trouve dans le PX. Espace de noms Objects.CM.Extensions . La plupart des attributs de devise de ces deux ensembles ont les mêmes noms.

Par exemple, il y a les deux PX. Objects.CM.PXDBBaseCuryAttribute et PX. Objects.CM.Extensions.PXDBBaseCuryAttribute.

Cela facilite le passage à la nouvelle implémentation multidevises car vous n’avez pas besoin d’apprendre de nouveaux noms d’attributs ou de vous souvenir de deux ensembles d’attributs. Mais en même temps, il est plus facile de manquer l’attribut de devise incorrect de l’espace de noms incorrect lors de l’examen d’un code DAC. Alors, s’il vous plaît soyez prudent.

Lorsque vous déclarez ou examinez un champ DAC dans une extension DAC/DAC qui stockera certaines informations dépendantes de la devise (par exemple, le montant de l’argent dans une devise), vous devrez déclarer sur la propriété de champ DAC un attribut de devise approprié à partir de l’un de ces deux ensembles.

Il est très important de NE PAS mélanger les anciens attributs hérités et les nouvelles extensions de graphique de devises , car cela entraînera des problèmes au sein du système.

Tout d’abord, vous devez savoir quels graphiques utilisent le DAC contenant le champ DAC mentionné ci-dessus.

Les anciens attributs de devise dans l’espace de noms PX.Objects.CM contiennent l’implémentation de support multidevises à l’intérieur d’eux.

Avec les nouveaux attributs de devise, le PX. L’espace de noms Objects.CM.Extensions s’appuie sur les extensions de graphique multidevises qui contiennent désormais la prise en charge de l’implémentation multidevises.

Nouveaux attributs de devise

Nous avons de nouveaux attributs de devise qui sont conçus pour fonctionner avec les extensions de graphique de devise. Par conséquent, les règles suivantes s’appliquent :

  1. Si tous les graphiques utilisant votre DAC n’ont pas d’extensions de graphique de devise correspondantes et que vous n’allez pas introduire une nouvelle extension de graphique de devise, vous devez utiliser les anciens attributs de devise.
  2. Si tous les graphiques utilisant votre DAC ont des extensions de graphique de devise correspondantes, vous devez utiliser les nouveaux attributs de devise.
  3. Si seuls certains des graphiques à l’aide de votre DAC ont des extensions de graphique de devise correspondantes, vous devez déclarer les événements de graphiques attachés au cache pour ces graphiques pour vos champs DAC. Dans la déclaration d’événement jointe au cache, vous devez déclarer un attribut de devise adapté au graphique. Utilisez les règles 1 et 2 pour ce faire.

Cela couvre les bases de la façon de choisir un attribut de devise. Vous pouvez trouver plus de détails dans ces deux articles à partir de notre portail d’aide:

API de plate-forme: Implémentation de la prise en charge multidevises sur un formulaire personnalisé

API de plate-forme : Insertion d’un document multidevises

L’importance d’intégrer les changements dans les attributs de devise

Revenons maintenant à la raison pour laquelle il est important d’intégrer ces changements.

Tout d’abord, les anciens attributs de la monnaie sont maintenant hérités et ne recevront donc pas beaucoup de soutien et d’améliorations à l’avenir. Il est possible qu’ils soient rejetés à un moment donné dans le futur lorsque tous les modules Acumatica et les grandes personnalisations seront migrés vers la nouvelle implémentation multidevises.

Deuxièmement, certaines personnalisations doivent intégrer les changements dans la multidevises pour fonctionner correctement sur les versions plus récentes et futures d’Acumatica.

Comme je l’ai mentionné précédemment, les anciens attributs ne doivent pas être mélangés avec les nouvelles extensions de graphique de devise.

Imaginez une situation où il y a une personnalisation qui étend le PX. Objects.APTran DAC avec un champ DAC personnalisé SomeBusinessSpecificAmt qui utilise un ancien attribut de devise. Le DAC APTran est utilisé sur l’écran « Factures et ajustements ». Dans ce cas, la logique métier de l’écran est stockée dans le PX. Graphe Objects.AP.APInvoiceEntry .

Maintenant, si les développeurs Acumatica ajoutent une extension de graphique de devise à ce graphique et que vous publiez cette personnalisation, l’ancienne et la nouvelle logique multidevises deviendront mixtes. Cela entraînera des erreurs dans le système.

Résumé

Les développeurs d’Acumatica ont retravaillé la prise en charge multidevises dans les modules Acumatica au cours des dernières années. Ils intègrent progressivement ces changements dans divers modules Acumatica.

L’historique des changements que nous avons apportés au fil du temps ressemble à ceci:

  • Acumatica 2018R2 : le support a été ajouté au graphique d’opportunité dans GRC
  • Acumatica 2019 : le module des services sur le terrain mis en œuvre avec la nouvelle fonctionnalité multidevises
  • Après les services sur le terrain, le soutien a été ajouté aux devis et aux proformas dans les projets
  • Dans Acumatica 2021R2: AP, AR et d’autres modules financiers ont été retravaillés
  • Actuellement, les développeurs retravaillent les modules de distribution

Les personnalisations qui étendent ces modules devraient intégrer les changements que nous avons apportés à la multidevises que nous avons décrits ici aujourd’hui.

Veuillez revoir votre personnalisation dans les cas suivants :

  • Personnalisations qui contiennent des DAC personnalisés avec des champs DAC stockant des données liées à la devise et des extensions de graphiques aux graphiques Acumatica existants qui utilisent ces DAC personnalisés dans leur logique
  • Les personnalisations qui contiennent des extensions de DAC personnalisées vers les DAC Acumatica et ces extensions DAC déclarent les champs DAC avec des données liées à la devise

Si vous avez des questions, veuillez les publier dans notre Forum public des développeurs communautaires - Sujets divers pour les développeurs.

Bon codage!

Auteur du blog

Sergey a rejoint Acumatica en 2017 et a commencé en tant que développeur d’applications dans l’équipe OEM, où il a fait beaucoup de développement Acumatica Framework - en plus de faire plusieurs personnalisations. Un exemple est une grande personnalisation pour le contrôle budgétaire automatisé pour Censof, un partenaire OEM. En 2019, il a rejoint l’équipe de développement de la plate-forme en tant que développeur de systèmes. Et plus récemment, Sergey est responsable de l’acuminator et de notre développement et maintenance RVT. Participant à un certain nombre de hackathons internes d’Acumatica, Sergey faisait partie de l’équipe gagnante - avec Vladimir Panchenko - qui a créé Acuminator. Lors d’un hackathon ultérieur, son équipe l’a étendu davantage en développant la carte de code avec d’autres améliorations à Acuminator.

Recevez des mises à jour de blog dans votre boîte de réception.