Refactorisation d'une méthode eConnect utilisant une seule procédure stockée

Question

J'écris un programme pour modifier certaines factures dans GP10 en utilisant eConnect. Certaines factures exigent que les distributions soient réinitialisées parce que les totaux ne s'additionnent pas correctement en raison de divers autres processus (non importants pour cette question); Ceci est accompli grâce à ce programme. De plus, la plupart des factures seront déplacées vers un autre lot (pensez à des compartiments si vous n'êtes pas familier avec GP), en utilisant également ce programme.

Ces deux tâches sont accomplies en traitant le même type de fichier via eConnect. Ceci est la méthode qui traite ce fichier:

public bool PersistAllChangesInDynamics() 
    { 
     //instantiate the proper eConnect object for updating the invoice. 
     eConnectType eConnect = new eConnectType(); 
     SOPTransactionType transType = new SOPTransactionType(); 
     transType.taSopHdrIvcInsert = this.ConvertToSopHdrIvcInsertXml(); 
     //Adjust fields to reset distributions. 
     transType.taSopHdrIvcInsert.UpdateExisting = 1; 
     transType.taSopHdrIvcInsert.CREATEDIST = 1; 

     SOPTransactionType[] updateInvTypeArray = { transType }; 
     eConnect.SOPTransactionType = updateInvTypeArray; 

     //serialize and process the document. 
     XmlDocument eConnectDoc = eConnectHelper.SerializeEConnectDoc(eConnect); 
     return eConnectHelper.ProcessEConnectDoc(eConnectDoc); 
    } 

Ma question tourne autour de ce morceau de code:

transType.taSopHdrIvcInsert.UpdateExisting = 1; //updates the batch changes 
    transType.taSopHdrIvcInsert.CREATEDIST = 1; //re-creates the distributions 

Le taSopHdrIvcInsert est l'objet fourni par eConnect persister toute modification des factures. Autant que je sache, il n'y a pas un objet qui recrée SEULEMENT des distributions. Chaque fois que je traite le document, eConnect appelle une procédure stockée nommée de la même manière sur la base de données Dynamics pour enregistrer ces modifications correctement. UpdateExisting et CREATEDIST sont paramètres optionnels pour ce SP.

Parfois, je n'aurai besoin de mettre à jour le lot (ou d'autres parties de la facture), ou seulement recréer des distributions, mais d'autres fois, je devrai faire les deux. Recréer les distributions ne provoque pas de changements indésirables, vous voulez toujours que les distributions soient correctes pour chaque facture. Je n'ai pas testé les économies de temps entre faire une seule chose à la fois; Puisque l'objet appelle un SP du côté serveur, je ne vois pas où cela prendrait beaucoup de temps. Est-ce que l'un d'entre vous voit une raison de le factoriser en deux ou trois méthodes différentes pour séparer chaque fonction souhaitée?

Answer 1

Si tout ce que vous faites est la mise à jour d'un champ ou deux et que vous savez qu'il ne gênera aucun GP, ​​mettez à jour le (s) champ (s) via SQL. J'ai beaucoup de méthodes qui appellent eConnect et ensuite directement mettre à jour l'objet après eConnect est fait avec lui parce qu'il n'y a pas de paramètres eConnect pour les champs que je dois changer.