财务审计功能简介
接口定义
暂无前端页面
接口定义相当于也是一种配置，配置CRM相关接口，比如合同接口信息，收款接口信息等
定时任务根据配置的请求接口信息定时请求CRM接口拉取数据
后端相关表 fin_interface_define_head 接口定义行表
| id | interface_name | interface_desc | request_url | mapping_field | start_time | end_time | is_freeze | data_type | target_table_name | analyze_path |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CRM_收款 | CRM_收款描述 | http://middleware-mps.elane.com:8090/api/v1/crm/receipt | {"endTime": "approveTimeMax", "startTime": "approveTimeMin"} | 2024-10-17 | 2099-12-31 | 0 | 1 | fin_crm_collection | |
| 2 | CRM_合同头 | CRM_合同头描述 | http://middleware-mps.elane.com:8090/api/v1/crm/salesOrder | {"endTime": "updatedTimeMax", "startTime": "updatedTimeMin"} | 2024-10-22 | 2099-12-31 | 0 | 1 | fin_crm_contract_head | |
| 3 | CRM_流水 | CRM_流水描述 | http://middleware-mps.elane.com:8090/api/v1/crm/cashDeposit | {"endTime": "transferDateMax", "startTime": "transferDateMin"} | 2024-10-22 | 2099-12-31 | 0 | 1 | fin_crm_bankflow | |
| 4 | CRM_合同行 | CRM_合同行描述 | http://middleware-mps.elane.com:8090/api/v1/crm/salesOrder | {"endTime": "updatedTimeMax", "startTime": "updatedTimeMin"} | 2024-10-23 | 2099-12-31 | 0 | 1 | fin_crm_contract_line | detail_Products |
| 5 | CRM_发票 | CRM_发票描述 | http://middleware-mps.elane.com:8090/api/v1/crm/salesInvoice | {"endTime": "invoicedTimeMax", "startTime": "invoicedTimeMin"} | 2024-12-09 | 2099-12-31 | 0 | 1 | fin_crm_invoicing | detail_Products |
接口定义的作用是 通过定义 请求URL，请求参数，然后为 CRMGetDataExecuteJob 类 创建定时任务 比如 infra_job 表
该表表示创建或更新的定时任务
http://audit-test.elane.com/financial/doc.html#/all/管理后台 - 定时任务/createJob
| id | name | status | handler_name | handler_param | cron_expression |
|---|---|---|---|---|---|
| 1037 | 流水 | 1 | CRMGetDataExecuteJob | { 'interfaceId': 3 } | 0 30 0 1 * ? |
| 1038 | 合同头 | 1 | CRMGetDataExecuteJob | { 'interfaceId': 2,'requestBody':{ 'startTime':'1999-01-01T00:00:00', 'endTime':'2025-03-31T00:00:00' } } | 0 20 0 1 * ? |
定时任务执行时，会将requestBody中的字段名根据 接口定义表中定义的字段替换该名称，比如 1038定义的定时任务，最终接口执行时
| request_url | http://middleware-mps.elane.com:8090/api/v1/crm/salesOrder |
|---|---|
| request_body | { 'updatedTimeMin':'1999-01-01T00:00:00', 'updatedTimeMax':'2025-03-31T00:00:00' } |
TIP
定时请求CRM接口返回的数据会先以 text 字段类型的格式存储在 fin_public_interface_head 和 fin_public_interface_line 表中
fin_public_interface_head 可以理解为 每一次的请求记录
fin_public_interface_line 则是记录着每次请求返回的数据，比如以分页方式请求， 每页10条， 则每一个head下对应着10条line记录，最后一页例外
业务表
暂无前端页面
业务表存储的是解析过后的每一个字段的值，即解析过text的具体的字段信息，具体的解析路径为 fin_interface_define_head 表的 analyze_path 字段定义的解析路径，为空则表示解析整个json
| 业务表名称 | 描述 |
|---|---|
| fin_crm_collection | 收款单信息业务表 |
| fin_crm_bankflow | 现金流水单信息业务表 |
| fin_crm_contract_head | 合同头信息业务表 |
| fin_crm_contract_line | 合同行信息业务表，即合同下具体购买的每个产品数据的信息 |
| fin_crm_invoicing | 开票信息业务表 |
分录数据源
分录数据源主要包括五类数据 对应着五类事件集，分录数据源与凭证共用， 每类事件集下对应着一类或多类事件
WARNING
事件集原先定义在 fin_account_sum_type 表中，后迁移到代码的枚举中，AccountSumTypeEnum，确定无逻辑再依赖 fin_account_sum_type 表时，可将其删除
事件原先定义在 fin_account_type 表中，后迁移到代码的枚举中，AccountTypeEnum，确定无逻辑再依赖 fin_account_type 表时，可将其删除此事件非会计事件，此事件仅用于分录数据源
业务表与分录数据源表字段对应关系原先记录在 fin_account_type 和 fin_account_type_mapping 表中
后已将对应关系直接写在代码中，确保两表再无引用后，可删除
收款数据
收款数据对应的分录数据源表是 fin_journal_collection
根据业务表（fin_crm_collection）数据 生成对应的分录数据源数据
对应的Service是JournalCollectionCreateServiceImpl
无具体逻辑，只是将一定区间范围内的业务表字段直接赋值给对应的分录数据源表字段
开票数据
开票数据对应的分录数据源表是 fin_journal_invoicing
根据业务表（fin_crm_invoicing）数据 生成对应的分录数据源数据
对应的Service是JournalInvoicingCreateServiceImpl
无具体逻辑，只是将一定区间范围内的业务表字段直接赋值给对应的分录数据源表字段
收入确认数据
收入确认对应的分录数据源表是 fin_journal_apportion
根据业务表（fin_crm_contract_line）数据 生成对应的分录数据源数据
对应的Service是JournalIncomeConfirmCreateServiceImpl
收入确认生成规则
将合同下的每个产品数据根据每月的实际服务天数将产品价格分摊到每个月，最后一个月的分摊价格用产品总价格减去之前所有分摊月价格的总和，均保留两位数
比如 某个合同总价为 1000元， 合同的服务期限为 2025-01-01 至 2025-12-31
购买了 船舶挂靠记录 和 CargoGo 空运 两个产品，分别 对应价格为 600元 和 400元
| 产品ID | 产品名称 | 服务月 | 分摊数额（元） |
|---|---|---|---|
| 1 | 船舶挂靠记录 | 2025-01 | 50.00 |
| 1 | 船舶挂靠记录 | 2025-02 | 49.45 |
| 1 | 船舶挂靠记录 | 2025-03 | 50.82 |
| 1 | 船舶挂靠记录 | 2025-04 | 50.00 |
| 1 | 船舶挂靠记录 | 2025-05 | 50.82 |
| 1 | 船舶挂靠记录 | 2025-06 | 50.00 |
| 1 | 船舶挂靠记录 | 2025-07 | 50.82 |
| 1 | 船舶挂靠记录 | 2025-08 | 50.82 |
| 1 | 船舶挂靠记录 | 2025-09 | 50.00 |
| 1 | 船舶挂靠记录 | 2025-10 | 50.82 |
| 1 | 船舶挂靠记录 | 2025-11 | 50.00 |
| 1 | 船舶挂靠记录 | 2025-12 | 50.82 |
| 2 | CargoGo 空运 | 2025-01 | 33.33 |
| 2 | CargoGo 空运 | 2025-02 | 32.97 |
| 2 | CargoGo 空运 | 2025-03 | 33.88 |
| 2 | CargoGo 空运 | 2025-04 | 33.33 |
| 2 | CargoGo 空运 | 2025-05 | 33.88 |
| 2 | CargoGo 空运 | 2025-06 | 33.33 |
| 2 | CargoGo 空运 | 2025-07 | 33.88 |
| 2 | CargoGo 空运 | 2025-08 | 33.88 |
| 2 | CargoGo 空运 | 2025-09 | 33.33 |
| 2 | CargoGo 空运 | 2025-10 | 33.88 |
| 2 | CargoGo 空运 | 2025-11 | 33.33 |
| 2 | CargoGo 空运 | 2025-12 | 33.88 |
WARNING
但后来因为加入了产品分摊确认功能，导致产品实际分摊可以在服务月之外，所以为 fin_crm_contract_line添加了
actual_apportion_start_month 实际分摊账期起始月
actual_serve_begin_date 实际服务起始时间
actual_serve_end_date 实际服务结束时间
实际分摊时先以 actual_apportion_start_month 为准，如果 actual_apportion_start_month 为空，则以 actual_serve_begin_date 和 actual_serve_end_date 为准，当两字段为空时，再以合同服务期限为准
当初不知为什么添加了 actual_apportion_start_month 字段，感觉与 actual_serve_begin_date 字段的作用有些重复，如果仅在此处有引用时，后期可考虑删除
重分类数据
重分类对应的分录数据源表是 fin_journal_reclassify
根据业务表（fin_crm_contract_head）和 分录数据源表（fin_journal_apportion）数据生成对应的分录数据源数据（fin_journal_reclassify）
对应的Service是JournalReclassifyCreateServiceImpl
DANGER
重分类数据是在收入确认数据生成的基础上生成的，否则生成结果可能有误
重分类关键字段解释
账期是指生成哪个月的账务，当前的结算月，一般都是当前月的前一个月，比如4月计算3月的帐，账期就是3月摊销余额是指当月账期(包含账期当月)欠款总额，- 摊销余额 = 历史所有分摊月分摊预收总额 - 历史收款月所有收款总额（可以这样理解）
- 摊销余额 = 上月摊销余额 + 本月（账期月）分摊预收 - 当月收款，（代码中实际是这样计算，考虑到一些初始化数据，只能拿上个月数据去计算）
重分类生成规则
上个账期的摊销余额 + 本月（账期月）分摊预收 - 当月收款 > 0 ? 是重分类 ：不是重分类1月账期
比如当计算1月账期数据时，以上述分摊为例，用户在 2025-01 月结束时至少应交 50 + 33.33 = 83.33元，
即应有一张对应的收款单数据，实际收款金额为 83.33元或以上
如果目前对应的合同只有一张 收款金额为 30 元的含收款单流水的收款单，则用户实际交款小于应交款，即为重分类
此时会生成一条该合同的重分类数据，摊销余额为 83.33 - 30 = 53.33元
2月账期
当计算2月账期时，用户当月应交 49.45 + 32.97 = 82.42 元，加上 上个月应交的 53.33 元， 假设当月对应的合同有一张 收款金额 为 100 元的含收款单流水的收款单，虽然用户当月交款大于当月应交款，但因为上月还有未交款，并且 100 < 82.42 + 50.33 所以当月依然是重分类数据，摊销余额为 53.33 + 82.42 - 100 = 35.75 元
3月账期
当计算3月账期时，用户当月应交 50.82 + 33.88 = 84.70 元，加上 之前几个月应交的 35.75 元， 假设当月对应的合同有一张 收款金额 为 300 元的含收款单流水的收款单，因为 300 > 本月应收(84.70) + 之前月应收(35.75)， 所以当月不是重分类，且用户剩余179.55元
4月账期
当计算4月账期时，用户当月应交 50.00 + 33.33 = 83.33 元，加上 之前几个月应交的 0 元， 假设当月没有收款，但因为用户剩余余额（179.55） > 83.33 + 0,
所以当月不是重分类，且用户剩余179.55 - 83.33 = 96.22元
TIP
摊销余额可以理解为 用户欠款总额，不知是否正确
坏账计提数据
坏账对应的分录数据源表是 fin_journal_bad_debt
根据业务表（fin_crm_contract_head）和 分录数据源表（fin_journal_apportion）数据生成对应的分录数据源数据（fin_journal_bad_debt）
对应的Service是JournalBadDebtCreateServiceImpl
坏账数据是在收入确认数据生成的基础上生成的，否则生成结果可能有误
坏账关键字段解释
账期是指生成哪个月的账务，当前的结算月，一般都是当前月的前一个月，比如4月计算3月的帐，账期就是3月坏账月是指哪个月的分摊金额还没有完成付款账龄天数是指对应分摊月应交的欠款天数， 欠款天数 = 账期月的最后一天 - 坏账月（分摊月）的最后一天 + 1原金额是指应交欠款数
坏账生成规则 产生的坏账进行抵消时是从服务开始月（最早的分摊月）开始抵消
还是以上述分摊为例，
1月账期
- 应交83.33元
- 实交30元
- 当月没有完成应付款，产生1条坏账
账期 坏账月 账龄天数 原金额（欠款金额） 2025-01 2025-01 1 53.33
2月账期
- 应交 82.42 + 53.33 = 135.75 元
- 实交 100元，因为用户在2025-01月应交欠款为 53.33，坏账从分摊起始月开始抵消，即2025-01月欠款已交完，2025-01月没有对应坏账，但2月应交82.42，拿100中的53.33已经抵消了2025-01月欠款，剩余的46.67元不足以抵消2025-02月的应交欠款82.42，所以产生坏账
- 当月付款已抵消1月欠款，2025-01分摊月无对应坏账，2025-2分摊月产生坏账，原金额 = 82.42 - 46.67 = 35.75
账期 坏账月 账龄天数 原金额（欠款金额） 2025-02 2025-02 1 35.75
2月账期
- 应交 82.42 + 53.33 = 135.75 元
- 假设当月用户没有交款
- 则2025-01分摊月和2025-02分摊月均产生坏账
账期 坏账月 账龄天数 原金额（欠款金额） 2025-02 2025-01 29 53.33 2025-02 2025-02 1 82.42