AcumatiCares
La plupart d'entre nous l'ont fait à un moment ou à un autre. Le client a besoin d'un nouveau champ à l'écran, les consultants fournissent les informations et vous créez un UDF sur une table Acumatica standard. Le travail est fait. Mais, pour une raison ou une autre, le champ n'est pas utilisé ou a peut-être été créé par erreur. À moins que vous n'interveniez avec un script SQL pour supprimer la colonne, ce champ UDF inutilisé existera probablement toujours dans SOOrder ou SOLine . Je trouve cela très frustrant et c'est une autre très bonne raison de toujours avoir une instance de test d'Acumatica ! Mais c'est le sujet d'un autre article. Dans cet article, j'aimerais discuter des avantages de créer des champs personnalisés différemment en créant des tables d'extension DAC au lieu de créer des champs UDF individuels dans une table Acumatica standard.
Une table d'extension DAC est une table SQL séparée qu'Acumatica associe automatiquement à une table standard (ex : SOOrder) soit via une jointure gauche, soit via une jointure interne, en fonction de la configuration. La table d'extension DAC possède les mêmes champs clés que la table standard, en plus du nombre de champs UDF que vous souhaitez créer. Acumatica crée automatiquement une entrée dans votre DAC Extension Table, soit chaque fois que vous en avez besoin, soit pour chaque enregistrement dans la table Acumatica jointe, en fonction de la configuration. A mon avis, c'est une bien meilleure façon d'ajouter des informations qui sont directement liées aux tables standard d'Acumatica. Quelques points importants à noter lors de la création de votre propre table d'extension DAC :
- La table SQL doit avoir les mêmes colonnes de clés principales que les tables standard (il n'est toutefois pas nécessaire de les définir dans le CED).
- La table SQL doit contenir les champs CompanyID et DeletedDatabaseRecord.
- Vous devez avoir l'attribut PXTable attaché à votre table DAC Extension. Le paramètre isOptional détermine si Acumatica mappe votre table avec une jointure interne ou externe gauche.
- Il n'est pas nécessaire d'utiliser le préfixe "Usr" requis lors de la création d'un UDF standard, mais plutôt un préfixe indiquant son auteur.
- Vous pouvez utiliser les types de colonnes d'audit standard pour ajouter des métadonnées à votre table(tstamp, CreatedByID, etc.). Toutefois, si la table standard contient ces champs d'audit, veillez à éviter les collisions de noms.
Voici un exemple de code :
GIST : https://gist.github.com/patrick711/8cde1aaf8da0069d75a59626edd6fdb9
Bonne chance et bon codage !
