财务孪生功能对财务共享原有功能的影响分析
目的
本文主要列举财务孪生开发的相关功能对财务共享现存功能的影响，以便于在后续财务共享功能开发过程中孪生相关联影响部分可查，不会导致两边相互影响，最终达到在开发这一部分功能时提高开发质量和开发效率。
说明
本文主要从功能、代码结构、数据库表的变化三个方面说明财务孪生对已存在的财务共享功能的影响点列示。本文只列举了财务孪生影响财务共享部分，不考虑财务孪生本身的功能，也不包括财务孪生各迭代过程中自身版本的相互影响。
功能影响
单据相关功能影响：
单据类型配置：
添加了是否开启孪生的开关，定义了一部分单据模板在新加单据时默认开启，其它单据可手动操作。开启孪生则在【单据提单、撤回，驳回、到达财务、完成】和历史数据初始化时 尝试写入财务孪生的中间表【ZFS_BOE_INVOICE_TWIN】。
单据提单、撤回，驳回、到达财务初审、完成
上面已提到在单据流转到这一部分节点时会尝试根据单据的头，发票明细行，补贴区写入财务信息中间表【ZFS_BOE_INVOICE_TWIN】； 根据分滩区写入【ZFS_BOE_INVOICE_TWIN_DETAIL】表。
我的单据
主要是移动端的页面修改。
财务孪生改前
 |
财务孪生改后
  |
待我审批
主要是移动端的页面修改，并在V10版本增加了智能分组的场景。
移动端展示影响：
移动端页面变化：
首页整体布局变更；我的发票待我审批 布局调整；首页、我的发票、待我审批统一了查询组件。
发票功能影响：
我的发票
通过各类入口（拍照、手工录入、电子票上传，微信卡包拉取）新增发票和订单接口同步时补充了标签相关的信息，同时在编辑也执行了同样的逻辑，具体增加的字段如下：
| 列名 | 类型 | 注释 |
| BUS_OCCURRENCE_ADDRESS | VARCHAR2(1024) | 费用发生地点-详细地址-高德返回 |
| LOCATION | VARCHAR2(64) | 费用发生地点-经纬度 |
| ARRIVE_CITY_ID | VARCHAR2(64) | 费用发生城市-城市表id |
| BUS_OCCURRENCE_DATE | VARCHAR2(64) | 费用发生日期 |
| TWIN_ADDRESS_ID | VARCHAR2(64) | 关联场所表id,（手选需要清空该字段） |
| TRANSACTION_CONTENT | VARCHAR2(512) | 交易内容 |
| TRANSACTION_TYPE_ID | VARCHAR2(64) | 交易分类(ID) |
| MATCH_FLAG | VARCHAR2(1) | 精准匹配标签:0:精确匹配,1兜底匹配 |
| START_OFF_CITY_ID | VARCHAR2(64) | 出发城市 |
| CARRIER_CODE | VARCHAR2(64) | 承运方编码 |
| INTE_COMPANY_CODE | VARCHAR2(64) | 常见互联网公司编码 |
| BUS_OCCURRENCE_CITY_ID | VARCHAR2(64) | 费用发生城市 |
| GOOD_SERVICE_CLASSIFY_CODE | VARCHAR2(64) | 商品服务分类 |
| DEPT_ID | VARCHAR2(64) | 部门id |
| SELLER_NUMBER | VARCHAR2(64) | 销方税号 |
| SELLER_NAME | VARCHAR2(200) | 销方名称 |
| BUYER_NUMBER | VARCHAR2(64) | 购方税号 |
以手工录入发票或者是修改发票时的场景为例，我们时序图列举了发票标签的交互图：
财务孪生字段的具体的业务处理逻辑
具体业务逻辑如下表
后端代码结构影响
后端代码主要在发票的保存和更新，其它都是孪生自身的功能。
单据扩展字段影响：
财务孪生在单据提交，业务或者财务修改，单据审批完成会在单据头表的extendMap 添加了下列字段，所以在单据配置过程中尽量不要使用下面的字段
| 字侧编码 | 名称 | 值说明 |
| T_twinAddressId | 场所地址 | |
| T_arriveCityId | 费用发生城市（到达城市） | |
| T_busOccurrenceAddress | 费用发生地址 | |
| T_location | 坐标 | |
| T_inteCompanyCode | 集团公司编码 | |
| T_inteCompanyName | 集团公司名称 | |
| T_goodServiceClassifyCode | 商品服务分类 | |
| T_transactionContent | 交易内容 | |
| T_sellerNumber | 销方编码 | |
| T_sellerName | 销方名称 | |
| T_buyerNumber | 购方编码 | |
| T_buyerName | 购方名称 | |
| T_deptId | 部门ID | |
| T_projectId | 项目ID | |
发票更新：
1、主要修改了下面了方法cn.ztessc.service.invoice.OpAllTicketService#update，在保存时会设置标签运维信息。
2、增加标签修改方法 cn.ztessc.service.invoice.OpInvoiceTicketService#updateTwinInfo ，此方法写在发票更新方法中，如果前端传twinUpdateFlag 为Y 时被执行，执行后原发票更新的后续逻辑将跳出。
发票保存：
发票的保存后台代码走的原逻辑，但在页面保存之前调用了cn.ztessc.controller.order.OpBillOrderVController#setTwinOpBillOrderDto 接口获取孪生信息赋值到页面，然后通过发票保存接口写入到发票的孪生字段中。
单据提交：
1、增加了等待异步调用 cn.ztessc.service.base.AbstractBoeFormCoreServiceImpl#twinLabelInfoSupplementProcess 方法，用于将单据信息写入到财务孪生的中间表。
单据增加了从BOE到BOE的有序MQ：
1、方法 cn.ztessc.service.base.AbstractBoeFormCoreServiceImpl#fmcAfterOperation MQ消费名 cn.ztessc.common.enums.DataPushEnum.DataPush2Twin#PUSH_BOEID_TO_TWIN
添加或者修改财务孪生标签字段（也就是孪生新加的相关字段）自测注意事项：
所有修改或者添加了孪生标签字段的需求，都需要跟进发票与订单表（OP_ALL_TICKET和op_bill_order）和孪生信息中间表（zfs_boe_invoice_twin）及孪生信息明细表（zfs_boe_invoice_twin_detail）四张表在提单，业务财务审批修改保存、单据审批完成使的数据变化，确认数据行数是否正常变化（是否有增减），字段值变化是否正常。
前端代码影响
数据库影响
参考下面文章
真诚点赞 诚不我欺~