PMIS科普 -- 上报案例
本文意在展示预算上报后系统如何进行数据汇总，尤其是在“系统待付”数据上的处理策略。
在本文的最后总结了预算数据的组成结构，请大家仔细阅读。读懂效率翻倍，读不懂天天维护。
本例已做过用户测试，高智商秒懂。
- 样例一（计划未变，依计申请）：
| 2019-03 | 2019-04 | 2019-05 | 2019-06 | |
|---|---|---|---|---|
| 上报操作 | 添加 2019-04：3000；添加 2019-05：2000；添加 2019-06：1000 | |||
| 发生事件 | 假定0基 | 按计划提交了3000元的付款申请，其中2000元已经支付 | 按计划提交了2000元的付款申请，全部未支付。 | 按计划提交了1000元的付款申请，全部未支付。 |
| 汇总数据 | 系统待付：0；2019-04：3000 ；2019-05：2000 ；2019-06：1000 | 系统待付：1000 ；2019-05：2000 ；2019-06：1000 | 系统待付：3000 ；2019-06：1000 | 系统待付：4000 |
此例意在说明：只要做了计划，并按照计划提交了申请，系统会自动将这部分预算统计到系统待付中，无需月月重复维护。
- 样例二（计划多变，错误案例）：
| 2019-03 | 2019-04（提前） | 2019-05 | 2019-06（错后） | 2019-07 | |
|---|---|---|---|---|---|
| 上报操作 | 添加 2019-04：3000 ；添加 2019-05：2000 ；添加 2019-06：1000 | ||||
| 发生事件 | 假定0基 | 按计划提交了3000元的付款申请，其中2000元已经支付，提前提交了5月的2000 | 提交6月未提的1000元 | ||
| 汇总数据 | 系统待付：0 ；2019-04：3000 ；2019-05：2000 ；2019-06：1000 | 系统待付：3000 ；2019-05：2000（预算多出2000） ；2019-06：1000 | 系统待付：3000 ；2019-06：1000 | 系统待付：3000 ；预算少了1000 | 系统待付：4000 |
此例意在说明：计划有变一定要去维护初始上报的数据，否则就会像“倾斜”标识出来的一样，不是多了就是少了。
- 样例三（计划多变，正确使用方式） ：
| 2019-03 | 2019-04（提前） | 2019-05 | 2019-06（错后） | 2019-07 | |
|---|---|---|---|---|---|
| 上报操作 | 添加 2019-04：3000 ；添加 2019-05：2000 ；添加 2019-06：1000 | 删减 2019-05：2000 | 调整 2019-07：1000 | ||
| 发生事件 | 假定0基 | 按计划提交了3000元的付款申请，其中2000元已经支付，提前提交了5月的2000 | 提交错后的1000元 | ||
| 汇总数据 | 系统待付：0 ；2019-04：3000 ；2019-05：2000 ；2019-06：1000 | 系统待付：3000 ；2019-06：1000 | 系统待付：3000 ；2019-06：1000 | 系统待付：3000 ；2019-07：1000 | 系统待付：4000 |
本例是上例正确的使用方式，区别就在“倾斜”标识出来的操作上。
- 数据构成 ：
| 序号 | 构成元素 | 性质 | 说明 | 上报人 | 数据粒度 |
|---|---|---|---|---|---|
| 1 | 系统待付 | 历史 / 计划外 | 系统中已提交的流程（未被终止、退回），系统认为是预计的负债。会被统计进“系统待付”。 “系统待付”包含着 临时发生（未计划） + 按计划提交，但未支付 的内容。 | 系统自动统计 | 项目级，从采购付款、借款、报销提取进行中的数据，再经过”功能 -- 成本分类“转化模型进行转化 |
| 2 | 业务部门、上报数据 | 新报 | 以项目为基本上报单元，重点以合同为依据，根据系统中的已发生和正在发生情况统计为参考，填写未来计划要发生的。 | 业务部门 | 上报方式：项目级 -- 预算细项 ； 逐级汇总：项目预算细项 → 项目月度预算 → 事业部月度预算 |
| 3 | 职能部门 、上报数据 | 新报 | 按职能角度上报一些预算 | 财务中心：融资、税金等 ；人资：工资 | 事业部级 |
上一篇： 预算上报
下一篇： 预算管理