财务实时预警系统模型设计方案.docVIP

财务实时预警系统 目录 (一)总体系 2 (二)模型 4 1、凭证模型 4 1)总流程 4 2)用户设置界面1-凭证 5 3)用户设置界面2-条件设置 5 2、科目金额模型 6 1)总流程 6 2)科目目标金额预警 6 3)科目金额变动预警 7 4)科目金额关联预警 7 3、指标模型 8 (三)附录 8 1)实时数据接口的一些规则 8 2)凭证变动的推理 8 3)监管周期 9  (一)总体系 以下是预警监管体系 可以看到，目前我们应该分为凭证模型、科目金额模型、指标模型三大类，而检查的大致流程是一致的，但检查条件是不一致的。目前记录更新时间的仅凭证，科目余额是没有更新时间的，因此关于科目金额的更新时间必须依赖于凭证检查，即发生额的变化。目前暂时不考虑年初余额发生变化，这个问题主要考虑放在将来的周期检查，属于规范一类。 下面是各类模型设置与监管计划的关系。 其中监管方案列表是作为监管计划的有效组成部分，可以被多次选用，同时也是用户在监管结果汇总的统计方法。 监管方案列表 模型类别 监管方案类别 方案名 状态 凭证 凭证条件预警 采购监管 启用 科目金额 科目目标金额预警 银行余额预警 启用 科目金额 科目金额变动预警 营业收入减少预警 启用 指标 赢利能力分析 房地产企业若山风向标 未启用 指标 杜邦分析 房地产企业杜邦分析 启用 模型类别：是我们大的分类方法，涉及到整个监管模型，目前共三大类，凭证、科目金额、指标。 监管方案类别：是在大的分类方法下的小分类方法，涉及用户设置界面，监管的周期、监管结果的显示，可以自由扩展，但这是系统开发时候定义的，不能在实施过程中扩展，如果用户有需求可以由实施人员向开发人员申请，规划后作为方案类别放入系统中。 方案名：实施人员或监管人员设置条件后的起的名字。因为一个方案类别可能有多个设置条件应用于下属单位的不同类型企业。 状态：包含“启用”、“未启用”两种，表示是否纳入了监管计划，如果是“未启用”，则任何时候都可以修改该方案。如果是“启用”，则修改该方案提示用户“只会对修改时间以后的内容进行实时监管！”。 监管计划设置 监管计划 被监管的单位 监管人员 通知形式 预算金额控制 A公司、B公司等 张三、李四 杜邦分析预警 A公司 张三 银行余额 B公司、C公司等 李四、王五 监管计划是可以重复应用监管方案，区别是监管人员、被监管单位的不同，这个与原先基本相同，唯一的区别是原先的监管方案不能被重用，必须在计划下设置，而现在是可以从一堆已经设置好的监管方案中选取。 “通知形式”，这项参考原先邮件发送形式。 选择监管方案的界面 模型类别 监管方案类别 方案名 状态 凭证 凭证条件预警 采购监管 科目金额 科目目标金额预警 银行余额预警 √ 科目金额 科目金额变动预警 营业收入减少预警 √ 指标 赢利能力分析 房地产企业若山风向标 指标 杜邦分析 房地产企业杜邦分析 (二)模型 1、凭证模型 1)总流程 凭证模型是基础模型，但也可能是用户用的最少的，因为它过于细节了，用户可能没有这个耐性去使用。但这也是最容易抓问题的，因为它是最有规范可设置。以下就是凭证模型实时预警的流程。 部分关键点说明： 1)用户设置界面有两个，是用户可能有不同的设置习惯，我们应该把条件作为模板，而把用户设置界面设计多个，这样不同的用户可以选择不同的界面来进行设置。并且模板也可以作为实时查询条件来从新过滤数据。这里指出的是将来可能还会增加新的用户设置界面。 2)关于需要检查的凭证，需要检查的凭证应该按照一张完整的凭证(即凭证头记录)来归集，这主要因为我们预警条件是按照一张凭证来设置的。在现实中可能修改了一张凭证中的一条分录，这时候该分录的时间戳已经被更新，而凭证头的时间戳没有更新，而这个凭证头也是要纳入我们的检查范围，另外还有可能某些凭证已经被删除了，这样在正常的凭证表中也不存在。所以这数据来源应该是“凭证明细历史表”([dbo].[RWS_VoucherDetailhistory])，按照凭证头分类，然后在正常凭证表中做条件判断。在正常凭证表中存在的凭证只能是新增、修改的凭证，可以按照条件去过滤。 3)修改、删除凭证的处理，如果一张凭证已经被修改或删除，可能带来的问题是原先可能该凭证已经被预警条件给过滤出来了，而现在可能已经不符合条件了，或则虽然符合条件，但两次记录同一张也是不正确的，因此对于修改、删除的凭证，只要在预警记录中存在就应该将之标记为“无效”。 2)用户设置界面1-凭证 摘要 科目 辅助信息 方向 金额范围 类似凭证的输入界面 其中分录与分录之间是“而且”的关系，即都要满足。 分录上的“摘要”、