大家好！我叫Tanya，是Lamoda Axapta开发团队的团队负责人。本文将讨论我们在Microsoft Dynamics 365 For Finance and Operations平台上的第一个项目的开发。

我将谈论我们使用的方法，所犯的错误，并分享我的知识和经验。那些开始在D365中开发项目或只是考虑一下的人可能会对本文感兴趣。

这是Mycrosoft Dynamics 365和Power Platform Meetup会议的报告的免费抄本。

项目目标和技术基础

我们的德国子公司购买商品并将其出售给俄罗斯法人。以前，我们使用Tsenit系统，该系统仅允许我们在财务数据级别保留记录，而不能应付货物和物流任务。为了解决这些问题，我们有其他工具。数据一次存储在几个数据库中。所有这些负面影响了整个系统的速度和可靠性。

我们希望会计系统能够帮助德国分支机构提交报告，缴纳税款并通过审核。过去的ERP很难解决这些问题，因此我们决定开发并启动自己的会计系统。我们的ERP应该在一个电路中将财务，会计和分支机构物流结合在一起。作为主要软件，我们选择了Microsoft Dynamics 365-以前的Dynamics AX，也称为Axapta。

在“技术，外包和心理”一文中描述了业务组件。在这里，我们将讨论技术实施。因此，我们需要自动化几个业务流程：

向供应商购买商品；
出售给俄罗斯法人；
D365与俄罗斯法人会计系统Ax2012之间的集成；
;
.

在该项目中，我们决定实施Microsoft Dynamics 365云解决方案，因为德国办事处没有IT基础架构来部署应用程序，也没有负责该应用程序的人员。对于小型远程分支机构而言，SaaS方案是最佳选择，因为它使您能够在与提供商签订合同后立即获得所有必要的软件和开发环境以开始实施。

我们的截止日期很紧：必须在3个月内完成整个开发。由于在旧系统中，商品会计是通过电子表格进行的，因此在整个会计年度中转移全部历史数据将是一项不可能的任务。但是在报告期初，仅转移余额就足够了。因此，有必要启动2019年1月1日或将其推迟一年。

我们的团队没有在D365上的开发经验。尽管有各种情况，我们仍计划尽快启动该项目。接下来，我将分别描述开发的所有阶段。我将详细介绍每次迭代：我们获得了什么经验以及我们犯了什么错误。

第一次迭代，对应用程序版本7.3的修改

为了快速开展业务，我们首先开发了一个简单的应用程序体系结构。它由开发环境-DevBox 1层环境组成。所有组件都安装在一台服务器/虚拟机上：应用程序对象服务器（AOS），数据库，Dynamics 365 Retail和Management Reporter。

对于测试，我们决定使用SAT环境-标准验收测试2层环境。

2层环境是一个多框环境，其组件安装在多个云服务中，通常包括多个应用程序对象服务器（AOS）。实际上，它尽可能接近生产环境，因此我们决定对其进行测试。

我们在现有的内部部署基础架构上部署了第一个开发环境，但是其容量不足以进一步进行项目开发。因此，当另外两名开发人员加入该项目时，我们在云中快速，优雅地为他们部署了DevBox。

我们的云环境通过生命周期服务门户进行管理。

完成环境工作后，团队开始发展。我们在Visual Studio上设置了开发环境，并将它们连接到Azure DevOps的版本控制，之前已经创建了一个分支来下载代码。接下来，我们开发了一种方法，用于开发变更并将其转移到SAT环境。

D365体系结构中没有层次；所有标准代码都已在模型中布置。通过LCS门户使用包含已编译模型的软件包将修改内容转移到SAT环境。

– , – , .

首先，我们实现了最简单，最常见的修改-在标准表中添加一个新字段，在创建记录时对其进行初始化，然后输出为标准格式。

即使在如此简单的项目中，也存在新的对象类型。我们进行了扩展，以向标准表添加新字段。为了使字段成为标准表单，我们制作了一种新型的对象-表单的扩展。为了初始化该字段，我们创建了一个扩展表方法的类。创建记录时，他允许初始化字段。

通过这种简单的修改，我们看到了D365的基本原理之一-不是更改，而是对标准对象的扩展。

下一个修改是创建新表格。现在，在创建表单时，有必要指定其模式。模式是一种完全定义表单设计结构的模式。在我们完全复制模板中规定的结构之前，我们的表格将不会被编译。无法更改完成表格的模板。因此，在开始开发之前，我们预先考虑了外观。

我们还保留了自行管理表单设计的功能。如果我们指示模式-自定义，那么我们将完全负责表单的设计：表单上有哪些对象以及具有什么嵌套。

第一次迭代后的结论

1.不要更改标准，而只能扩展它。

2.如果我们在其他模型中使用其对象，请参考该模型。这是D365模型与以前版本之间的差异之一：对象仅存在于一个模型中。

3.更改标准对象的属性存在限制。并非可以在标准对象的扩展名中更改标准字段的所有属性。例如，PurchTable表的扩展名是LineDisc字段。我们可以控制字段和标签的可见性，并且必须更改诸如必填和可编辑之类的属性。

4. D365中没有作业，所有工作都通过类完成。

5.我们对模型打得太细微了，结果证明我们的“一个修改=一个模型”的原理不起作用。

第二次迭代并过渡到一个模型

在第二次迭代的开始，我们有两个相互引用的模型。因此，我们无法再独立转移这些修改。因此，我们决定在一个新模型中工作，有必要将所有现有的修改都移植到该模型中。

D365中的模型是位于单独目录中的源文件的集合。编译时，它们收集在一个单独的库中，该库与其他库具有链接。

因此，在DevBox上合并成一个模型归结为将文件从一个目录传输到另一个目录并删除旧目录。

因此，我们建立了一个新模型，在每个DevBox上获取了最新版本，然后继续在开发环境中的一个模型框架内工作。

自然，我们已经转移了一些模型来在SAT环境中进行测试。因此，有必要将其删除，然后发布一个新的。

SAT环境的所有更新都是使用软件包完成的，包括删除模型。我们创建了一个包含需要删除的空模型的程序包，并向其中添加了带有这些模型名称的脚本。然后，我们收集了一个具有新模型的程序包，并将其滚动到SAT环境中。因此，SAT得到了一个新模型。

合并模型时，我们注意到每个开发人员都以自己的方式命名对象的扩展。我们根据模板PurchTable.LamodaModelFormExtension，PurchTableTypeLamodaModelClass_Extension约定了对象命名规则。

我们在团队中也同意，对于一个标准对象，我们仅创建一个扩展并对其进行更改。

我选择了我们在此阶段所做的一些有趣的修改。他们展示了D365中可能的开发方法。

任务1

在过帐销售订单的发票时，有必要用订单中的编号替换发票编号。为此，我们定义了一个具有扩展可能性的标准类，该类允许我们执行此修改。

我们扩展了标准的SalesInvoiceJourCreate类。他的getNumAndVoucher（）方法中有Next-这是我们的新超级，他谈到了调用标准方法代码。调用标准代码后，我们将发票号替换为所需的值。

这是我们的开发方法之一：使用扩展并在执行标准代码之前或之后（作为选择-之前和之后）添加我们自己的代码。

任务2

必须更改采购订单总计的显示：将总计与采购订单行中供应商的发票编号分组。在这种情况下，我们不会在不减半性能的情况下找到扩展的空间，因此我们制作了自己的结果版本而没有触及标准结果。

任务3
另一个有趣的修改：在采购订单表单的各行中，必须从具有过滤功能的项目列表中添加字段。在以前的版本中，修改完全没有意思，只需将表格作为数据源添加到表格中，然后将这两种方法重叠即可解决。

在7.3版中，我们无法将方法扩展到标准表单数据源。为了进行过滤而不为此创建新表单，我们将视图添加为表单的数据源。

将方法扩展到数据源的功能出现在D365版本8.1中。

第二次迭代后的结论

在此阶段，我们已经对启动项目进行了必要的基本修改。

我们介绍了命名扩展的规则。它们不仅有助于使名称一致和易于理解，而且进一步简化了更新，因为我们的名称与Service Pack中标准对象的名称不一致。
我很高兴在构建项目或模型时如何快速进行交叉引用-在此版本中，它的组织非常方便。
在不同类型的环境中更新模型的方式不同。我们以合并模型为例对此深信不疑。
在开始开发新的修改之前，您需要获取模型的最新版本，因为开发是在一个模型的框架内进行的。
事实证明，更新产品上的数据时，在Excel中加载和卸载数据的数据实体机制非常方便。我们的数据和分析部门现在正在使用它从基于云的D365中检索数据。

我们按时进行了主要开发。Go Live出现了，该模型已投入生产。我们面临着仅在模型中发布经过测试的修改的问题。我们还希望在修改测试期间促进调试过程，并加快测试环境的更新速度。

现在如何运作

在上一次迭代中，我们添加了两个环境：构建和测试。在配置并验证了所有环境之后，我们简化了测试，并学会了仅在模型中发布经过测试的修改。

为了进行测试，我们部署了一个1层环境，并将其连接到版本控制系统中的开发分支。现在，更新包括获取模型本身及其组件的最新版本。在这种环境下，我们像通常的DevBox一样首次亮相。

现在，要在新的构建环境上进行发布的构建软件包。从最早到最后，将经过测试的修改与变更集（将变更包上传到版本控制系统）转移到版本控制系统中的新分支。

然后，我们将程序包部署到进行用户测试的SAT环境中，然后我们将程序包安排在LCS门户上，以便在产品上发布。因此，我们使用构建环境来设置发布过程。

我们决定不修改项目，而是将要修改的变更集上载到版本控制中。

第一次云版本更新

我们使用的是云版本，因此需要定期进行更新。第一次更新是从7.3版到8.0版的过渡。花了大约两个星期。

当然，我们为自己创造了主要问题，但我们也赢得了：

我们没有立即就命名标准对象的规则达成一致。在第一次更新中，我们的对象名称与Service Pack中的对象名称一致。
在更新云环境时，我们必须从AOS机器注销，否则更新过程将无法由登录用户完成。
产品和SAT环境的更新包需要与模型包结合使用。

今天，更新我们所有的环境大约需要3-4天，并且无需开发人员参与即可进行。我们甚至可以在更新的同时发布一个版本，主要是构建，SAT和prod具有相同的版本。

更新过程包括在lcs门户上下载更新程序包。首先更新DevBox和测试，然后更新构建，最后更新SAT和prod。

整个第一个项目的结果

我们已经积累了构建D365应用程序体系结构的经验。
开发了一种新的代码审查方法。
我们制定了将数据库传输到DevBox的规则（在D365中，对DevBox进行初始测试非常重要，现在，我们甚至在DevBox上测试开发人员）。
在D365上编写了开发指南。
学会在云中发展。

所有这些经验帮助我们更加审慎地开发了该项目。现在我们知道了系统的功能，我们可以更正确地构建体系结构，或者设置任务。项目周围的构建过程使连接首次使用D365进行编写的开发人员非常容易。

在Microsoft Dynamics 365 For Finance and Operations平台上开发第一个项目