我正在编写一个程序来使用 eConnect 修改 GP10 中的一些发票。一些发票需要重置分配,因为由于各种其他(对于这个问题并不重要)过程,总数没有正确加起来;这是通过这个程序完成的。此外,大多数发票将被移动到不同的批次(如果您不熟悉 GP,请考虑存储桶),也使用此程序。
这两项任务都是通过 eConnect 处理相同类型的文件来完成的。这是处理该文件的方法:
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);
}
我的问题围绕着这段代码:
transType.taSopHdrIvcInsert.UpdateExisting = 1; //updates the batch changes
transType.taSopHdrIvcInsert.CREATEDIST = 1; //re-creates the distributions
taSopHdrIvcInsert 是 eConnect 提供的对象,用于保留对发票的任何更改。据我所知,没有一个对象只能重新创建分布。每当我处理文档时,eConnect 都会在 Dynamics db 上调用一个类似命名的存储过程,以正确保存这些更改。UpdateExisting 和 CREATEDIST 是该 SP 的可选参数。
有时,我只需要更新批次(或发票的其他部分),或者只重新创建分配,但其他时候,我需要同时做这两个。重新创建分布不会导致任何不良变化,您总是希望每个发票的分布都是正确的。我没有测试一次只做一件事之间的任何时间节省。由于该对象在服务器端调用 SP,我看不出它在哪里需要显着不同的时间。
你们中是否有人认为有任何理由将其重新分解为 2-3 种不同的方法以保持每个所需的功能分开?