对于高层管理人员来说，该计划看起来有点不同，并且立即从在 Aeroclub 个人账户中购买门票开始。
——从公司的中央办公室到项目或从项目
相关部门——协调和转移部，负责监控旅行政策的遵守情况。如果购买不符合政策规则，则会启动更改商务旅行的流程。例如，如果在此期间有更便宜的票，他们可能会提出更改日期。
更改商务旅行
不仅在协调部门注意到住宿或航班 台湾邮箱 条件过于豪华时才需要进行变更，而且在出现与工作问题相关的其他原因时也可能需要进行变更：需要晚点走或早点走、在航线中增加其他物体、员工生病、家庭情况、不可抗力等。
为此，我们设想了两种情景：
- 更改 B24 侧的旅行日期；
- 航空俱乐部方面的日期变更。
第一个流程是手动启动的：通过单击元素上的按钮，员工将进入一个表单，其中有一组特定的字段可供编辑。更改日期后，相应的BP就会启动。根据情况，可能会有或不会同意、拒绝等。作为业务流程的结果，新数据被发送到航空俱乐部，并且在 1C:ZUP 中已经发送了更改订单的任务。
在第二种情况下，用户在 Aeroclub 中独立更改某些内容，然后专门创建的代理获取这些 布韦岛商业指南 数据，并且该过程几乎总是无需批准。
您可以根据需要进行多次更改，但必须达到一定的状态。
商务旅行流程和整合的特点
在业务流程开发过程中，我们遇到了许多困难和限制。
- 审批有几个阶段，与位于层级结构不同级别的审批者的角色相关。例如，不仅必须获得直属上司的批准，还必须获得以下人员的批准：
- 员工所在项目的策展人；
- 项目经理（如果员工不是来自中央办公室，则与策展人交换位置）；
- 行政主管（如果出国出差）；
- 职能主管（例如，来自运输机械化部门的员工在项目之间调动）
- 首席执行官或其助理（在某些情况下）。
审批程序和路线以组织结构为依据。有必要遍历整个链条，找到其中所有的经理，具体取决于被派出差人员的职位和工作地点。但其特殊之处在于，该组织架构有1000多个部门，仅行政管理人员就有5000多人。
一方面，由于不需要将所有 提供商可以根据所选的资费限制 员工从 1C：ZUP 拖到 B24，因此任务变得更容易。另一方面，司机或焊工并不在 CRM 中工作，但他们必须在项目之间调动，因此需要安排商务旅行。为此，业务流程需要一名负责人的参与，该负责人可以代表被派出差人员安排行程。
路线的逻辑是一个单独的主题，但其中的主要内容是查找协调器的方法。如果经理不在，系统会找副经理，如果两人都不在，会找上级经理，如果经理休假，审批会交给副经理，如果出差，审批会转到移动应用程序。为了确定经理是否在员工队伍中以及是否在工作场所，不仅要使用 1C:ZUP 的卸载，还要使用 Bitrix24 中的缺勤时间表。
并非所有副经理、助理经理都有批准权。为了防止在没有协调经理的情况下将申请上报给首席执行官，有必要改变标准的授权功能，因为那里的设置不是很灵活。我们开发的审批机制基于预先设定的用户角色，可以：代表经理行事、代表自己行事或委托。这缩短了审批链，因为即使没有经理并且他的助理没有权限批准，该文件也会被委托给有权限批准的人。完成所有批准后，该流程将把已批准人员名单转移到 1C:ZUP。
- 一个项目可以覆盖多个城市：总部可以设在莫斯科，承包商可以设在乌斯季卢加。因为航空俱乐部对购买机票和预订酒店的城市名单进行了限制，所以离不开其经理的参与。从莫斯科到圣彼得堡可以自己买票，但到乌斯季卢加只能在旅行社工作人员的帮助下购买。在自动化的过程中，出现了人工处理，这里的解决方案只能在航空俱乐部方面。
- 在B24中，城市和项目之间存在联系。如果用户选择了一个项目，那么该城市就会自动输入到表单中，以启动“商务旅行”业务流程。事实证明，这并不总是必要的。例如，该集团旗下一家公司的总部设在莫斯科，但有一些员工在圣彼得堡工作。如果是从总部出差，出发城市就确定为莫斯科，圣彼得堡的人无法正常飞出。为了解决这个问题，我们增加了手动选择出发城市的功能，这需要编辑表格并改进审批流程。
- Velesstroy 会计解决了 Bitrix24 中的部分任务，但商务旅行是在 1C:ZUP 端处理的。应客户的要求，我们开发了一种机制，在 B24 中生成任务文本（标题、人员、日期、路线、优先级等）并将其传输到 ZUP。该解决方案有一个缺点：会计部门必须手动将数据从任务转移到1C。
因此，创建并将其传输对象（包含商务旅行数据的 JSON）从 B24 到 1C 以生成“商务旅行”文档和在此基础上的商务旅行订单的任务已移至待办事项。毕竟，不可能简单地创建并将 JSON 传输到 1C（以便它立即起作用）；1C 需要进行修改。有必要组织该对象的存储、其处理（1C 中收集任务文本的逻辑）、向任务表单添加按钮、实现创建文档和存储与任务的连接机制。