功能梳理
接口定义
暂无前端页面
接口定义相当于也是一种配置，配置CRM相关接口，比如合同接口信息，收款接口信息等
定时任务根据配置的请求接口信息定时请求CRM接口拉取数据
后端相关表
define_head 接口定义头表
define_line 接口定义行表
| 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://test:8001/api/receipt | {"endTime": "approveTimeMax", "startTime": "approveTimeMin"} | 2024-10-17 | 2099-12-31 | 0 | 1 | collection | |
| 2 | CRM_合同头 | CRM_合同头描述 | http://test:8001/api/salesOrder | {"endTime": "updatedTimeMax", "startTime": "updatedTimeMin"} | 2024-10-22 | 2099-12-31 | 0 | 1 | contract_head | |
| 3 | CRM_流水 | CRM_流水描述 | http://test:8001/api/cashDeposit | {"endTime": "transferDateMax", "startTime": "transferDateMin"} | 2024-10-22 | 2099-12-31 | 0 | 1 | bankflow | |
| 4 | CRM_合同行 | CRM_合同行描述 | http://test:8001/api/salesOrder | {"endTime": "updatedTimeMax", "startTime": "updatedTimeMin"} | 2024-10-23 | 2099-12-31 | 0 | 1 | contract_line | detail_Products |
| 5 | CRM_发票 | CRM_发票描述 | http://test:8001/api/salesInvoice | {"endTime": "invoicedTimeMax", "startTime": "invoicedTimeMin"} | 2024-12-09 | 2099-12-31 | 0 | 1 | invoicing | detail_Products |
接口定义的作用是 通过定义 请求URL，请求参数，然后为 CRMGetDataExecuteJob 类 创建定时任务 比如 infra_job 表
该表表示创建或更新的定时任务
| 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://test:8001/api/salesOrder |
|---|---|
| request_body | { 'updatedTimeMin':'1999-01-01T00:00:00', 'updatedTimeMax':'2025-03-31T00:00:00' } |
TIP
定时请求CRM接口返回的数据会先以 text 字段类型的格式存储在 public_head 和 public_line 表中
public_head 可以理解为 每一次的请求记录
public_line 则是记录着每次请求返回的数据，比如以分页方式请求， 每页10条， 则每一个head下对应着10条line记录，最后一页例外
业务表
暂无前端页面
业务表存储的是解析过后的每一个字段的值，即解析过text的具体的字段信息，具体的解析路径为 interface_define_head 表的 analyze_path 字段定义的解析路径，为空则表示解析整个json
| 业务表名称 | 描述 |
|---|---|
| crm_collection | 收款单信息业务表 |
| crm_bankflow | 现金流水单信息业务表 |
| crm_contract_head | 合同头信息业务表 |
| crm_contract_line | 合同行信息业务表，即合同下具体购买的每个产品数据的信息 |
| crm_invoicing | 开票信息业务表 |
分录数据源
分录数据源主要包括五类数据 对应着五类事件集，分录数据源与凭证共用， 每类事件集下对应着一类或多类事件
WARNING
事件集原先定义在 account_sum_type 表中，后迁移到代码的枚举中，AccountSumTypeEnum，确定无逻辑再依赖 fin_account_sum_type 表时，可将其删除
事件原先定义在 account_type 表中，后迁移到代码的枚举中，AccountTypeEnum，确定无逻辑再依赖 fin_account_type 表时，可将其删除此事件非会计事件，此事件仅用于分录数据源
业务表与分录数据源表字段对应关系原先记录在 account_type 和 account_type_mapping 表中
后已将对应关系直接写在代码中，确保两表再无引用后，可删除
收款数据
收款数据对应的分录数据源表是 journal_collection
根据业务表（fin_crm_collection）数据 生成对应的分录数据源数据
对应的Service是JournalCollectionCreateServiceImpl
无具体逻辑，只是将一定区间范围内的业务表字段直接赋值给对应的分录数据源表字段
开票数据
开票数据对应的分录数据源表是 journal_invoicing
根据业务表（fin_crm_invoicing）数据 生成对应的分录数据源数据
对应的Service是JournalInvoicingCreateServiceImpl
无具体逻辑，只是将一定区间范围内的业务表字段直接赋值给对应的分录数据源表字段
收入确认数据
收入确认对应的分录数据源表是 journal_apportion
根据业务表（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
但后来因为加入了产品分摊确认功能，导致产品实际分摊可以在服务月之外，所以为 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 为准，当两字段为空时，再以合同服务期限为准
重分类数据
重分类对应的分录数据源表是 journal_reclassify
根据业务表（crm_contract_head）和 分录数据源表（journal_apportion）数据生成对应的分录数据源数据（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
摊销余额可以理解为 用户欠款总额，不知是否正确
坏账计提数据
坏账对应的分录数据源表是 journal_bad_debt
根据业务表（crm_contract_head）和 分录数据源表（journal_apportion）数据生成对应的分录数据源数据（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
分录查询
会计事件
会计事件可以理解为是凭证的一种分类，一条会计事件对应着一种事件（凭证），此处需要与分录数据源中的事件相区分，因为会计事件是支持增删改查的，所以没办法与分录数据源中对应的固定的事件共用一个逻辑
会计事件相关数据表
accounting_event 会计事件
分录规则
分录规则是某一个会计事件下（某一类凭证）具体的凭证,是凭证数据的基本单位，一条凭证数据对应着一条分录规则
分录规则相关数据表
accounting_event_journal_rule 分录规则
分录规则明细
分录规则明细则是对生成某种凭证（生成某个分录规则对应凭证数据）的规则的具体配置
它体现着 分录数据源表 与 账务表 字段之间的对应关系 凭证数据的生成都依赖于分录数据源，凭证的生成并没有复杂的逻辑关系， 凭证表每个字段的取值方式分为三种，
- 常量
- 直接取分录数据源对应字段的值并赋值给相应的凭证字段
- 映射关系，在分录数据源分别选取一列作为映射列和数据源列，并配置对应的映射ID。当映射列的值符合映射条件时，选取公共值集中的映射值填充该字段，如果没有条件相匹配，则选取数据源列的值填充该凭证字段
分录规则明细相关数据表
accounting_event_journal_rule_detail
公共值集映射相关数据表 value_mapping
value_mapping_detail
TIP
公共值集体现着数据之间的映射关系，而分录规则明细体现着 分录数据源表 与 账务表 字段之间的关系。
简单理解就是拿分录数据源表哪一列数据去做映射，映射成功后，将映射值赋值给账务表的哪一个字段。
这也就是之前说公共值集目前只用来生成数据时映射的解释。
会计事件-> 分录规则 -> 分录规则明细在表中体现着上下级的关系
分录
分录生成步骤
- 根据前端页面的条件筛选分录数据源
- 根据每一个分录规则定义的筛选组筛选数据
- 求两个集合的交集
- 按照对应的分录规则下设置的分录明细生成凭证
产品分摊确认
没有一个专门的表用来存储分摊确认的数据，所有分摊确认的数据都是从业务行表查询到的
产品分摊确认数据的作用也是生成收入确认分录数据源，可以理解为是收入确认分录数据源的一种特例，它并不会按上述收入确认的规则去生成对应的收入确认分录数据源
比如 如果选择 实际分摊方式为一次性，可自定义每个月分摊的百分比，但必须分摊在账期月以及账期月之后 因为在前账期月之前的分摊数据已经生成了凭证并推送到了金蝶，即使再修改也毫无意义