Comment tirer parti de l’audit d’Acumatica en code

Résumé des fonctionnalités d’audit

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

Supposons que vous souhaitiez suivre chaque fois qu’une valeur de ligne de crédit est modifiée pour un client et lorsque la ligne d’adresse 2 est modifiée, ainsi que toute modification apportée à un attribut client de INDUSTRY.

Sélectionnez l’écran Maintenance clients sur l’écran Audit et notez que plusieurs tables et champs peuvent déjà être sélectionnés pour vous.  Supposons que cela puisse déjà être mis en place et que notre solution ne doive se concentrer que sur le ou les domaines qui nous intéressent.  Nous devrons inclure Customer, BACCOUNT et CSANSWERS pour les attributs.  Lorsque vous avez terminé de sélectionner les tables et les champs appropriés, assurez-vous de cocher la case Active pour commencer l’audit.

Maintenant, nous pouvons tester un changement.  Ouvrez ABC Holdings ou tout client et modifiez la limite de crédit.  J’utilise la base de données sales demo, donc je vais changer la ligne de crédit à $123,456.78.  Je vais changer la ligne d’adresse 2 à la suite 122, et je vais ajouter un attribut de BANKING.

Si vous ouvrez ensuite l’écran Historique de l’audit D’Acumatica, vous pouvez voir vos modifications.

Ce qui se passe dans les coulisses

Tout d’abord, regardons la table AuditHistory dans SQL.

Notez que non seulement le client ABCHOLDING a eu des changements, mais 2 autres clients ont également eu des changements.  Mais nous n’y avons pas touché.  Voyez si vous pouvez deviner pourquoi alors que nous continuons.  Je vais expliquer plus dans la section suivante.

Ce que nous voyons en examinant la table AuditHistory sont deux enregistrements pour notre client, un pour la table Customer et un pour la table BAccount de base.

• Le BatchID nous donnera un regroupement du moment où une modification a été apportée. Dans mon exemple, j’ai changé trois choses différentes sur l’écran du client, de sorte qu’elles ont toutes été soigneusement regroupées
• ChangeID sera un ID unique de chaque modification
• Pour l’opération , vous verrez un U pour mis à jour et I pour inséré
• TableName nous indique évidemment quelle table a été modifiée
• CombinedKey fournira des informations sur la fiche maîtresse qui a été modifiée
• Le champ ModifiedFields de l’enregistrement client nous indique quel champ a été modifié

Il va sans dire que nous ne voulons jamais lire SQL directement dans le monde Acumatica, alors jetons un coup d’œil à ce que nous obtenons lors de la lecture des enregistrements AuditHistory de la couche d’accès aux données.

J’ai créé un bouton sur l’écran Maintenance client pour un débogage rapide pour 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 peux voir que nous obtenons le même nombre d’enregistrements que nous avons vu dans SQL.  Décomposons ce que nous voyons.

Sous la Clé combinée pour cet enregistrement, nous avons le BACCOUNT. Valeur ACCTCD nous pointant vers le client qui a été changé.

Sur le champ ModifiedFields, nous avons une paire clé/valeur séparée par un « \0 ».   Nous pouvons analyser ces données dans un dictionnaire nous donnant quel champ a été modifié et à quelle valeur il a été modifié.  Remarquez que nous n’avons pas vu cela en faisant simplement une requête SQL de la table.  Dans votre code, attendez-vous à ce que cela puisse contenir plus d’une paire de valeurs, comme vous le verrez plus tard.

Pour les modifications 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 à l’écran l’a fait, alors gardez cela à l’esprit que si vous souhaitez uniquement suivre des champs très spécifiques, vous devrez filtrer ce dont vous n’avez pas besoin.

La valeur CombinedKey d’une modification d’adresse contiendra une valeur de chaîne représentant l’int AddressID , que vous pouvez prouver en effectuant une requête rapide.  La leçon ici est que combinedkey ne contiendra pas toujours la valeur ACCTCD , il peut porter l’ID d’enregistrement, vous devrez donc le convertir d’une chaîne en une valeur int dans certains cas.

Des choses encore plus intéressantes apparaissent pour les audits d’attributs.

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 quelle clé d’attribut a été modifiée, qui dans ce cas était « INDUSTRY ».  Puisque le TableName est CSANSWERS, il pourrait contenir n’importe quel attribut qui avait changé.

Les champs ModifiedFields pour les attributs auront toujours « Valeur » analysé par la nouvelle valeur qui est BNK pour les opérations bancaires.

Cette requête affiche la correspondance pour quel client a été changé.

Autres idées

Dans notre première section, j’ai souligné que plus d’un client a été déclenché comme changé lorsque je n’ai apporté qu’une modification à ABCHOLDING.  Cela est dû à la nature des comptes enfants pour les clients.  ABCVENTURES et ABCSTUIDOS sont des comptes enfants pour ABCHOLDING et sous la logique métier et la configuration d’Acumatica, ils sont obligés de partager les informations de limite de crédit, donc changer l’un a déclenché le même changement pour les deux autres.  Il est important de s’attendre à ce que de telles bizarreries se produisent, vous devrez donc faire beaucoup de programmation et de tests défensifs pour répondre à vos objectifs de solution.

J’espère que ce BLOG vous est utile pour fournir des informations de base dont vous pourriez avoir besoin lors de la conception d’une solution programmatique qui vous oblige à extraire les informations d’audit D’Acumatica.

Bon codage!