我们将继续谈论如何改善我们的客户和合作伙伴以及公司员工的生活。 这将与统一制度的实施有关。 我故意没有指出“什么”的协调，因为在未来，从理论上讲，“一切”的协调将变得很明显。
关于审批制度的思考
最初，在我们公司以及其他许多我必须工作的公司中，或者我是“客人”或者只是从我的朋友那里听到的消息，协议都是通过定期通信的方式进行谈判的（并且在撰写本文时）。邮件。 自然，这适合具有少量人员和承包商的公司。 由于每月（甚至一年）仅签署一项或两项协议，而仅由首席执行官来决定签署，因此无需特别提出和实施系统。 在支付账单时也观察到类似情况。 每个与交易对手进行交互并需要付款的员工都需要发票，并通过邮寄将其发送到会计部门并要求“付款”。 同时，未经雇员和/或公司管理层的直接主管事先批准付款，会计部门不会总是支付账单。 在某些情况下，批准链可以“缩短”，反之亦然“延长”。
到目前为止，员工人数不多，每个人都知道谁是谁，谁是领导者—没有特别的问题。 在手动模式下和某些条件下，将以通信方式协商付款申请并付款（或拒绝）。 但是我们的公司正在发展，从某一刻起我们就越过了那条看不见的界线，此后，有必要考虑这些流程的自动化以及引入新事物的必要性。
我们的愿望清单
我们有自己的最低系统要求：
- 用户友好的界面和面向Web的高度期望（无需安装客户端）
- 配置灵活性
- 尽管我们不是临床医生，但我们很偏执。 因此，我们希望保留可能在机密区域内显示机密信息的服务
最初，我们分析了市场上“电子文档管理系统”系列的产品。 我们研究了著名的系统：1C：文档管理，“业务”，“ THESIS”。 我们还研究了为其他公司订购的系统以及诸如Allware之类的新产品。
我不能说系统不好。 实际上，几乎所有系统都使我们能够满足主要的愿望清单，甚至更多。 但是，像往常一样，细节决定成败。
首先-界面。 我们不习惯使用“ 1C”风格的界面。 我们需要一个简单直观的界面，在该界面中，我们将执行最少的操作以获得最大的结果（谁不想这么做？）。
其次，价格（同时支付，然后支付整个产品的拥有成本）。 我们不需要开箱即用的系统中的所有内容。 但与此同时，您必须立即支付所有费用。 而且由于许多人现在都在切换到订阅系统，因此您必须不断支付费用，并且费用通常取决于许多条件（用户/连接数，在云中工作的能力，其他选项，模块等）。 并“跳出”系统，如果价格突然停止适合-这是有问题的。
第三，没有办法“管理”您的“愿望清单”。
实作
我将不会写很长的时间来说明我们最终如何以及为什么要“决定骑自行车”并编写我们自己的电子文档管理系统。 做出决定-您需要这样做。 我们已经经历了试图在没有要求的情况下实施产品的麻烦，因此首先开始了TK的编写过程及其协调。 幸运的是，在我们耳目一新之前，我们已经看到了实现的示例，因此整个过程非常轻松。
我们唯一需要砸破矛的事情是，在开发体系结构的过程中，我们不应屈服于满足“原样”要求的诱惑，这不利于灵活性和进一步的易用性。 诱惑很大，特别是对于主要客户，因为实施和实施的时间将减少2倍。 但是我们设法说服管理层和我们自己，“最好是输掉一天，然后在5分钟内飞起来”。 我认为我们做出了正确的选择。
最好先输掉一天，然后在5分钟内飞起来。
“标准”堆栈是.Net Core 2和EntityFramework，Angular 4，MS SQL，因为我们在工具和技术的应用方面拥有相当大的背景。 尽管出于明显的原因，DBMS对我们并不重要。 如有必要，请继续进行我们希望的操作。
结果是满足我们重要要求的产品：
- 一个工作流程-协议的不同参与方（与下一段相关）
- 在指定条件下跳过批准阶段的条件（可以使用给定的检查将应用程序中的任何字段添加到条件中，并根据条件的有效性确定是否需要进行下一个批准步骤或“跳过”）
- 我们的“专有”界面
方便实用的功能，例如：
- 为目录（用户和系统）设置默认值。 用户指南是允许用户自行设置项目的实体。 创建的项目将仅对他可用。 同时，系统管理员可以在目录中输入常规元素，该目录对系统的所有用户都可用
- 确定每个用户最常用的目录元素，并根据这些统计信息在界面中形成列表（排序）
- 可以从管理面板图（要填充的字段的结构和属性）和视图（每种形式的批准）的视图（表格中元素的排列）进行完全自定义
- 灵活的ACL
- 每个用户均可通过各种参数集对应用程序进行自定义搜索。 参数可以是应用程序模板的任何属性，并且可以选择过滤期间必须对此字段施加的条件。 在这种情况下，您可以创建尽可能多的过滤集。 方便在不同部分快速搜索
- 根据给定模板针对特定应用领域验证输入的值
当然，也有一些“好奇心”。 首先，我们正在谈论配置工作流程。 最初，我们认为我们需要能够配置业务流程的树形图。 从一个协调点（阶段）开始，可以根据用户的选择（协调）进行不同的分支。 逻辑灵活。 但是，当我们意识到这个机会并在生产环境中启动了该系统之后，在我们看来，实际上我们并不需要赋予用户选择权（思考的机会）。 对于他来说，一切都应该在“同意”，“拒绝”级别进行。 否则，我们将无法摆脱理解公司员工互动细微之处的原则。 为了满足此条件，工作流应该是
线性的 。
当然，也有一些“好奇心”。
结果，我们找到了一个折衷方案-解决方案体系结构和工作流的实现都像树一样，但是从配置的角度来看，使用固定在“协议”级别。 他们做对了。 从现在开始，当分析与启动新类型的批准相关的任务时，很明显，在某些阶段，对于特定类型的申请，我们需要为协调员提供选择各种行动的机会。
现在介绍一下我们的“诀窍”（至少我们相信它）。 为了实现线性并同时能够将一个工作流程用于一个批准计划（该计划，我指的是需要参与并且具有不同角色顺序的实体（合同，付款帐户等）），我们已经考虑并实施了一种条件机制跳过下一阶段的批准。 在创建条件时，我们可以使用对帐卡的任何实体并将其与“任何”进行比较。
例如，我们具有以下实体：发起人，金额，货币，交易对手。 我们需要的金额少于100,000卢布。 协调不是通过员工A来进行的；在外币支付中，协调必须与协调B有关，并且如果发起者是员工C，则必须对员工D进行额外的协调；此外，员工是指个人和特定群体。 为了实现这些点，我们“在线”添加所有匹配点。 即..：发起方-> A-> B-> D-> ...
接下来，形成用于“通过”到每个协调点的条件。 例如，在过渡发起者-> A上，在（发起者）A-> B-货币=“卢布”，（发起者A，B）-> D-发起者= C上配置了条件“金额<100,000”。
为什么在括号中标出过渡？ 因为条件可以在复杂的“幕后”条件下得到满足，所以如果我们形成过渡到协调点的条件，我们将自动生成一个“绕过”这一点的系统过渡（此处树状工作流体系结构对我们没有帮助， “拐杖”）。好吧，药膏有点苍蝇。 我们还没有实现可配置的警报管理机制。 尽管最初它是放置在项目的体系结构中的。 像往常一样，为了加快启动过程，我不得不“暂时进行硬编码”，此刻此硬编码仍然存在。 当时的想法是创建一种类似于jira的机制，该机制允许您创建自己的通知方案，您可以在其中设置触发器（事件）并将其与组或特定员工相关联，并能够将其“附加”到任何类型的应用程序。
为了加快启动过程，我不得不“临时硬编码”一点。
介面
我们系统的一些接口，因此可以大致了解所讨论的内容
仪表板
系统用户在打开系统时看到的第一件事（如果您不考虑身份验证过程）是仪表板。 它仅显示有效（不完整）批准。 此外，应用程序分为两个部分：
- 需要用户批准的应用程序（我是表演者）
- 用户发起的应用程序（我是作者）
创建一个新的应用程序
用于创建新应用程序的界面可以绝对具有任何表示形式（元素的数量和排列）。 这是一个简单的界面，演示了输入数字，从列表中选择，标记（复选框），日期，附件的功能。
您唯一需要注意的是“创建更多”选项。 激活它后，创建当前应用程序后，我们不在仪表板或新创建的应用程序的卡片中，而是会立即打开用于创建与刚刚创建的类型相同的新应用程序的表格。 它是根据我们的员工的要求实施的，这些员工必须“捆绑”创建相同类型的应用程序。
审批阶段
此界面与应用程序创建表单没有太大不同。 但是它具有许多基本功能特征：
- 将显示按钮，而不是创建按钮，而是单击按钮，然后单击这些按钮，将应用程序转移到业务流程的一种状态。 在退化的情况下，如上所述，它是“拒绝”和“同意”
- 附件，评论和新的日记帐实体（操作历史记录）放置在单独的选项卡中
- 默认情况下，除注释外，所有请求字段均不可编辑。 同时，我们制定了允许我们在协调的任何特定步骤提供仅调整给定字段集的功能的功能。
- 如果您是应用程序的发起者（可以随时转到批准卡），并且具有“创建重复项”选项，则单击该选项时，将打开应用程序创建表单，该表单的字段值（附件除外）与当前应用程序的字段值重复。
如果仔细观察，您会注意到“计数器”选择字段前面带有橙色加号的橙色元素。 这是管理个人目录的功能。 当您单击该项目时，将打开用于添加目录项目的表格。
由于在这种情况下是对方，因此我们中的directory元素包含两个详细信息-Name和TIN。 创建后，用户可以立即从下拉列表中选择此项。
搜寻
在搜索应用程序时，根据您需要选择的属性值在顶部显示一组属性。 每个用户都可以根据需要配置集，并可以在它们之间快速切换。
业务流程管理
作为管理业务流程的一部分，我们可以创建任意数量的航点并指示过渡。 结果，形成过渡图。 对于每个协调点，我们可以设置：
- 谁在给定点匹配
- 允许在路线中的给定点执行操作的权限
- 跳过这一点的条件（批准阶段）
选配
在“协调员”选项卡中，您可以添加组，添加的用户，他们可以在业务流程中的给定点执行批准流程。
动作权限
在权限方面，您可以多居住一点。 为了限制与更改应用程序中字段（实体）的值有关的协调器的动作，引入了一种许可机制。 目前，我们输入了4个权限：
如果前三个大致相同，则需要对更改可用字段的权限进行注释。 默认情况下，谈判者无法更改应用程序中的任何字段值。 仅查看模式可用。 如果需要允许在特定的批准点更改各个应用程序字段，则激活此选项，并且可以从应用程序字段列表中仅选择那些值可以更改为匹配字段的字段。
尽管有些牵强，但是例如，如果您有一个单独的职位“填写金额正确性的验证者”，那么这可能是必要的，然后给他机会仅更改应用程序中的金额，仅此而已。
跳过条件
跳过条件如上所述。 需要功能来为系统的所有用户形成一个单一的线性业务流程，并同时根据给定条件且无需用户干预，同时以不同方式沿路径进行应用程序移动。
在屏幕上，准备了一个设置，如果发起者在某些组中并且货币等于俄罗斯卢布，则将允许您跳过此路线点。
而不是结论
目前，我们公司仅发布了一种批准。 但是，由于具有嵌入系统的自定义灵活性，我们提供了一些工具，可让您配置任何应用程序卡，您可以在其中指定任意数量的字段，应用程序卡的任何表示形式以及在各种情况下进行协调的任何路线。
唯一需要做的就是与分析一起收集需求，然后通过管理界面将其传输到系统。 我们现在在做什么。
该产品是有生命的，我们会定期根据员工的要求进行更改，结果是其功能和可用性不断增强，并且已实现的功能可以满足业务所面临的任务，并且我们始终可以放心地说，在以下情况下，所要求的功能将得以实现如果可能的话。