Comment tirer parti de l'audit dans le code d'Acumatica ?

Résumé des fonctionnalités d'audit

Commençons par un rappel de ce qu'est l'audit dans Acumatica et comment le mettre en place. L'ERP d'Acumatica permet à un utilisateur de suivre les modifications apportées à presque tous les champs d'Acumatica.

Supposons que vous souhaitiez suivre la modification de la valeur d'une ligne de crédit pour un client, la modification de la ligne d'adresse 2 et toute modification de l'attribut INDUSTRY d'un client.

Sélectionnez l'écran de gestion des clients dans l'écran d'audit et remarquez que plusieurs tables et champs sont déjà sélectionnés. Supposons que tout cela soit déjà configuré et que notre solution ne se concentre que sur le ou les champs qui nous intéressent. Nous devrons inclure Customer, BACCOUNT et CSANSWERS pour les attributs. Une fois que vous avez sélectionné les tables et les champs appropriés, veillez à cocher la case Actif pour lancer l'audit.

Nous pouvons maintenant tester une modification. Ouvrez ABC Holdings ou n'importe quel client et modifiez la limite de crédit. J'utilise la base de données Sales Demo, je vais donc modifier la ligne de crédit à 123 456,78 $. Je vais changer la ligne d'adresse 2 en Suite 122, et je vais ajouter un attribut BANKING.

Si vous ouvrez ensuite l'écran Historique des audits Acumatica, vous pouvez voir vos modifications.

Ce qui se passe en coulisses

Tout d'abord, examinons la table AuditHistory en SQL.

Remarquez que non seulement le client ABCHOLDING a subi des modifications, mais aussi deux autres clients. Mais nous ne les avons pas touchés. Essayez de deviner pourquoi en continuant. J'en dirai plus dans la section suivante.

La table AuditHistory contient deux enregistrements pour notre client, l'un pour la table Customer et l'autre pour la table de base BAccount.

• Le BatchID nous permet de savoir à quel moment une modification a été effectuée. Dans mon exemple, j'ai modifié trois éléments différents sur l'écran du client, et ils ont donc été regroupés de manière ordonnée.
• ChangeID sera l'identifiant unique de chaque changement
• Pour Opération, vous verrez un U pour mise à jour et un I pour insertion.
• TableName nous indique évidemment quelle table a été modifiée
• CombinedKey fournira des informations sur la fiche qui a été modifiée.
• Le champ ModifiedFields de l'enregistrement du client nous indique quel champ a été modifié.

Il va sans dire que nous ne voulons jamais lire le langage SQL directement dans le monde Acumatica, alors regardons ce que nous obtenons lorsque nous lisons les enregistrements AuditHistory à partir de la couche d'accès aux données.

J'ai créé un bouton sur l'écran de gestion des clients pour un débogage rapide afin de vous montrer tous les extras que vous obtenez.

GIST : https://gist.github.com/JACOBNOTES/f7e1c49abe27b476fe6701d11c5127ae

Lorsque je débogue cette ligne de code et que j'examine la collection HistoryRecords, je constate que nous obtenons le même nombre d'enregistrements que dans SQL. Décortiquons ce que nous voyons.

Sous la clé combinée de cet enregistrement, nous avons la valeur BACCOUNT.ACCTCD qui nous renvoie au client qui a été modifié.

Dans le champ ModifiedFields, nous avons une paire clé/valeur séparée par un "\0". Nous pouvons analyser ces données dans un dictionnaire qui nous indique quel champ a été modifié et à quelle valeur il a été modifié. Remarquez que nous n'avons pas vu cela en effectuant simplement une requête SQL sur la table. Dans votre code, attendez-vous à ce qu'il y ait plus d'une paire de valeurs, comme vous le verrez plus tard.

Pour les changements d'adresse, nous avons maintenant un exemple de plus d'une paire clé-valeur sur le champ ModifiedFields. Nous n'avons pas directement modifié le RevisionID, mais la logique métier de l'écran l'a fait. Gardez cela à l'esprit si vous souhaitez uniquement suivre des champs très spécifiques, vous devrez filtrer ce dont vous n'avez pas besoin.

La valeur CombinedKey pour un changement d'adresse contiendra une chaîne de caractères représentant l'identifiant d'adresse (AddressID int), ce que vous pouvez vérifier en effectuant une requête rapide. La leçon à retenir est que la CombinedKey ne contiendra pas toujours la valeur ACCTCD, elle peut contenir l'ID de l'enregistrement, vous devrez donc la convertir d'une chaîne de caractères à une valeur int dans certains cas.

Les audits d'attributs présentent des aspects encore plus intéressants.

Ici, notre paire clé-valeur dans le champ CombinedKey représente un GUID NoteID pointant vers le BACCOUNT par NoteID où le changement s'est produit.

La valeur NoteID est séparée par le "\0" indiquant la clé d' attribut modifiée, qui dans ce cas était "INDUSTRY". Le nom de la table étant CSANSWERS, il peut contenir n'importe quel attribut modifié.

Les champs ModifiedFields pour les attributs auront toujours "Value" analysé par la nouvelle valeur qui est BNK pour Banking.

Cette requête montre la correspondance avec le client qui a été modifié.

Autres points de vue

Dans notre première section, j'ai souligné que plusieurs clients étaient considérés comme modifiés alors que je n'avais apporté qu'une modification à ABCHOLDING. Cela est dû à la nature des comptes enfants des clients. ABCVENTURES et ABCSTUIDOS sont des comptes enfants pour ABCHOLDING et selon la logique d'affaires et la configuration d'Acumatica, ils sont forcés de partager l'information sur la limite de crédit, donc changer l'un d'eux a déclenché le même changement pour les deux autres. Il est important de s'attendre à ce que des bizarreries comme celle-ci se produisent, vous devrez donc faire beaucoup de programmation défensive et de tests pour répondre aux objectifs de votre solution.

J'espère que ce BLOG vous sera utile en vous fournissant quelques informations de base dont vous pourriez avoir besoin lors de la conception d'une solution programmatique qui vous oblige à extraire des informations d'audit d'Acumatica.

Bon codage !