财务这块干久了你会发现很多术语在不同公司、不同系统里叫法五花八门。今天想聊的“抛帐”和“过账”就是一对经常被混用、但实际处理逻辑完全不同的操作。我一开始接触这两个词时也绕了不少弯子后来在几个项目里反复核对数据、排查差异才算把它们的边界彻底摸清。这篇就把我实际踩过的坑、总结出来的套路连同底层逻辑一起摊开来讲。简单说“抛帐”更偏向于前端业务单据向财务模块传递的动作比如销售出库单抛到总账生成凭证“过账”则更侧重财务凭证本身在账簿体系里的登记动作比如凭证从草稿状态正式写入总账。抛是“入口”过是“落库”。很多对账差异、月末调整、审计追踪的问题根源都出在这两个环节的衔接没理顺上。这篇内容适合谁看刚接手财务系统运维、正在做ERP上线或切换的顾问以及被月末对账逼到崩溃的会计。我会把整个流程拆开讲清楚每一步为什么要这么做配上实操中真正能用的检查方法。1. 整体设计与思路拆解1.1 先搞懂“抛帐”和“过账”到底在做什么“抛帐”英文系统里常见的是Posting或Transfer中文语境下叫法很多有些公司叫“抛转”“抛送”“导入总账”。它本质上是把业务系统里的单据按预设的会计规则生成会计分录再传递给总账模块。比如销售发货后库存减少、成本增加、收入确认这些动作不可能靠会计手工一笔笔录入而是通过抛帐规则自动映射。“过账”则是把这些已经生成的凭证从“草稿”“暂存”状态正式登记到总账科目余额里。过账之后这笔业务就真正影响到科目余额表、明细账和财务报表了。如果你的系统里过账是可逆的通常也只是用“冲销”而不是“反审核”。这两个动作用白话类比就是抛帐是写“记账凭证”这个草稿过账是把凭证上的金额登记到“总分类账”这个大本子上。草稿可以涂改、删除但一旦登记上去了就得留着痕迹。1.2 为什么必须把这两个动作拆开设计我见过不少小型系统把“抛帐”和“过账”合并成一个按钮点一下直接生成凭证并登记总账。这种做法短期内省事但后患无穷。拆开设计核心价值有三个第一可控性。抛帐后你可以先检查生成的凭证科目、金额、辅助核算是否准确有问题在过账前修正。合并操作等于跳过了这个质检环节错误会直接污染账套。第二可追溯。拆开后每笔业务都能分清“是前端单据抛过来的”还是“手工填制后过账的”审计时能快速定位来源。合并操作的话所有凭证都长一个样子查询效率极低。第三可调度。有些企业业务量很大白天的抛帐操作会影响系统性能拆开后可以设置夜间批量抛帐次日早上财务人员一到岗先做复核然后统一过账。所以当你接手一个项目时第一件事永远是先把这两个操作的触发时机、操作主体、控制逻辑分清楚。含糊的地方就是以后出问题的位置。1.3 一个典型项目的整体流程说明以我最近参与的生产制造业ERP项目为例整体数据流大致是供应链录入销售订单仓库做发货过账这里有个“过账”但属于库存模块系统根据发货单自动生成应收凭证和成本凭证——这一步是“抛帐”凭证传到总账模块后呈“已生成/待过账”状态财务复核无误后点“过账”——这一步才是真正的总账过账。采购入库、生产领料、费用报销的逻辑完全一样只是映射的会计科目不同。整个项目的核心其实就四步配置基础数据包括会计科目表、凭证类型、过账码。配置业务单据到总账的映射规则明确哪些单据类型生成哪些凭证。设计凭证复核与过账策略包括谁来做、什么时候做、要不要二次审批。设计异常处理机制比如抛帐失败的重试策略、过账被锁的解锁流程。这四步里最花时间、最容易出幺蛾子的永远是第二步的映射规则。我后面会详细讲。2. 核心细节解析与实操要点2.1 会计科目与凭证类型的优先级设定很多团队在配置映射规则时一上来就埋头写中间表这是错误的启动姿势。第一步应该是梳理会计科目和凭证类型。科目表要保证同一类业务在不同模块里对应的科目是唯一的。比如“库存商品”科目生产入库、销售出库、盘盈盘亏都必须指向同一个一级科目差异只能体现在辅助核算或二级科目上。否则后续抛帐规则会越写越乱。凭证类型决定了凭证编号规则和过账时的权限控制。像SA总账凭证、RV销售发票凭证等都是常见类型。凭证类型还决定了哪些字段必填、哪些字段允许留空。比如RV凭证里客户字段必须存在否则过账时会直接报错。这块我的经验是先把科目表导出来逐一核对每个科目是否启用了“未清项管理”和“行项目文本”等属性。未清项管理尤其关键它决定了这笔业务后续能不能做账龄分析和清账处理。很多抛帐错误根源其实是科目属性没配好而不是规则本身写错。2.2 抛帐规则与字段映射的确定到了这一步就进入真正的核心。抛帐规则的实质是把一张业务单据里的字段搬运到会计凭证的字段里。常见的映射逻辑有三类方向映射库存增加记哪个方向库存减少记哪个方向。科目映射什么物料、什么费用类型落到哪个科目。金额映射以单据上的净值为准还是含税额为准币种怎么转换。以销售出库为例一张发货单至少要映射出五条行项目主营业务收入、销项税额、主营业务成本、库存商品减少、应收客户款。这五条分录的金额来源、借贷方向、科目取值逻辑都要明确写出来。这里最容易犯的错是把金额直接取成含税总额。实务上收入科目必须是未税金额税额单独走科目。如果系统里没有拆分逻辑宁可多配置一条科目取值规则也绝不在底层改金额否则月末增值税申报时差异会让你怀疑人生。2.3 过账控制策略与审核流程过账环节最常见的设计方案是“先复核后过账”。财务人员在总账模块里查询所有状态为“待过账”的凭证逐张检查科目、金额、说明确认无误后勾选并批量过账。很多系统支持“过账前凭证打印”和“过账后报表回溯”的功能这些都要提前配置好。打印模板里最好包含业务来源单据号方便跨模块对账。如果企业有严格的内控要求还可以在过账前加一道“预算检查”或“资金计划检查”不满足条件的凭证禁止过账。需要特别留意的是过账本身是一个耗时的批量操作特别是在月底几千张凭证同时过账时系统会出现锁表或超时。一个稳妥的策略是把大凭证拆成多个批次每批次控制在200张以内逐批过账。既能避免锁表也方便定位哪几张凭证导致过账失败。2.4 辅助核算与多维度的处理现代财务系统里辅助核算已经成了标配。所谓辅助核算就是给科目增加额外的统计维度比如部门、客户、供应商、项目、业务员、成本中心。在抛帐环节辅助核算的取值逻辑通常是从业务单据上的对应字段带的。比如销售发货单上有“销售部门”字段映射时就应把它带到凭证行项目的“部门”辅助核算里。如果单据上这个字段为空那过账后做部门利润表时就会出现大面积的“无部门”数据非常被动。所以在设计映射规则时强烈建议把辅助核算字段单独做成一个映射列表逐一检查每个科目需要哪些辅助核算每种辅助核算从哪来。宁可多配几个默认值也不能允许关键辅助核算字段为空。2.5 反审核、冲销与红蓝字处理没有不出错的业务。一旦过账后发现问题处理方式就跟过账前的修改完全不同。过账前你可以直接修改或删除凭证草稿。过账后任何删除操作都是不规范的必须通过“冲销”来处理。冲销在系统操作上又分“红字冲销”和“蓝字冲销”。红字冲销是生成一张金额为负数的凭证把原凭证对科目的影响抵消掉蓝字冲销则是生成一张借贷方向完全相反的凭证。国内企业多数用红字冲销因为不会虚增借方的发生额。这块的实际操作难点在于冲销凭证必须与原凭证建立关联关系审计时才能从冲销凭证反查到原始凭证。很多系统用“冲销原因”字段加“关联凭证号”来实现。如果你发现冲销后两张凭证之间的关联断了先查关联字段有没有被覆盖或清空。3. 实操过程与核心环节实现3.1 环境准备与初始配置清单动手之前先把环境理干净。需要准备的配置包括会计科目表确定所有要用的科目并维护其属性。凭证类型至少要有标准总账凭证、销售凭证、采购凭证、成本结转凭证四类。过账码定义每一类业务对应的借贷方向。SAP里有标准的过账码比如BSX是库存记账61是收入。抛帐规则表定义哪些单据类型生成哪些凭证类型以及行项目映射逻辑。单据编号范围确保每个凭证类型有独立的编号规则。我当时做新系统切换时整整花了两天时间把科目表从旧系统导出来与新系统的科目模板做对照把每一个科目都核对了一遍这个基础工作做得越细后面遇到的问题越少。3.2 分模块抛帐实现的详细步骤整个系统如果按模块拆开来看各模块的抛帐实现方式略有不同。这里选三个最常见的场景展开销售模块销售出库单抛帐本质上是在发货过账时同步生成收入和成本凭证。你需要在后台的“复制规则”里维护销售订单到出库单的字段复制关系同时配置“按发货生成凭证”的开关。配置时最重要的一件事是确定“开票时点”和“确认收入时点”是否一致。很多企业是按发货确认收入也有企业坚持按开票确认收入。两者在税法层面和财务核算层面的意义完全不同相当于一个权责发生制一个收付实现制搞反了会直接影响当期利润和应纳增值税。采购模块采购入库的抛帐相对简单核心是“暂估应付”和“实际应付”的差异处理。货到票未到时按暂估价生成应付暂估凭证发票到时再用发票金额调整暂估。很多系统把这种调整做成自动冲销。我建议项目上线初期暂估冲销的逻辑先不要做得太自动化宁可多花人工复核的时间也要确保每一个调整都有据可查。因为暂估冲销一旦做错会导致两个月的成本同时失真。费用模块费用报销抛帐核心在费用类型与科目的映射。差旅费、业务招待费、办公费、通讯费在不同行业里核算科目可能完全不同。建议把费用类型表与科目映射表做成Excel底稿由财务负责人审核后导入系统。3.3 从抛帐到过账的完整闭环操作实操当天我的标准操作流程长这样第一步在业务模块里做单据操作比如过一张发货单。第二步打开总账模块的“待处理凭证”列表查看系统生成的凭证。这里重点看三样东西借贷是否平衡、科目是否正确、辅助核算是否完整。第三步如果有问题回到业务模块修正对应的字段重新抛帐。如果没问题直接勾选并执行过账。第四步过账完成后跑一张“科目余额表”核对总账的发生额与业务模块的汇总数据是否一致。检查是否一致最简单的做法是各模块做一个“月报表”然后把总账科目余额表中的对应科目余额与它对比。差额就是问题所在。这一步最考验人的是耐心。一个项目上线首月差异金额常常不是几万就是几十万但真正的错误往往就藏在一两笔几十块钱的差异里。按单排查别用平均数去衡量重要性。3.4 参数选择与系统配置的逻辑参数配置这块最容易引发混乱的是“过账期间”。每个模块都有独立的过账期间定义比如物料模块的过账期间和财务模块的过账期间要一致否则会出现库存已经记到10月财务凭证还停留在9月的尴尬情况。我遇到过一次这样的典型问题仓库月底盘点后做了一张盘盈单物料模块直接过了账但因为财务模块的过账期间还锁定在9月导致这张盘盈单抛到总账后状态变成“待过账”。财务人员没注意看只审核了9月的凭证盘盈凭证就一直挂在系统里。到了10月结账时才发现库存金额和总账对不上折腾了整整一天才把问题定位到这张跨期凭证。所以我的习惯是在月结前专门过一遍“模块期间状态表”确认所有模块的过账期间已经推进到同一期间再启动财务结账流程。3.5 月末集中处理与凭证归档方案月末是“抛帐过账”问题的高发期也是最考验之前设计是否合理的时段。月末要做的事情很固定暂估入账、成本结转、费用预提、折旧摊销、汇兑损益。这些业务都涉及大量凭证而且它们之间相互依赖比如成本结转要在收发存结存确认后才执行折旧摊销要在固定资产模块完成月结后才抛到总账。实操上我建议做一个“月末结账任务清单”按依赖关系排好序。每一步完成后确认对应的过账状态已经是“已过账”再进入下一步。凭证归档方面电子凭证要按年月、模块、凭证号范围做备份纸质附件的归档编号要与凭证号建立对照表。现在很多系统支持凭证导出PDF后自动加水印存档这个功能一定用上能省去不少审计准备时间。4. 常见问题与排查技巧实录4.1 业务已过账但总账无凭证这个问题几乎每个项目都会遇到。业务单据显示已经过账了但总账里找不到对应凭证。排查思路分三步走第一步查看该业务单据上的“凭证状态”字段是“已生成”、“待过账”还是“生成失败”。第二步如果是“待过账”说明抛帐已成功只是财务还没执行过账操作。到总账模块查“待过账凭证列表”。第三步如果是“生成失败”查看日志里的错误信息。常见原因是映射规则缺失比如某个新加的物料组没有配置到对应科目。别一上来就怀疑是系统丢了数据。我见过太多次所谓“凭证丢失”其实只是状态还挂在“待处理”里查询筛选条件不对就没看到。4.2 抛帐提示科目未创建系统提示非常明确就是会计科目表里没有对应的科目。但背后的原因值得深挖。很多情况下是因为业务部门用了新的物料类型或费用类型而财务部门完全不知情。等到月底抛帐时一批单据集体报错。解决思路除了创建一个新科目并把映射规则补进去之外更重要的动作是建立“新主数据审批机制”。所有新的物料类型、费用类型、成本中心创建时必须经过财务审核确认对应的科目映射已维护后才允许生效。这个机制能从根本上减少这类问题。4.3 凭证过账提示“请检查必填字段”这类问题看着简单实际排查起来却可能很费劲。系统只会告诉你某个字段必填但不会告诉你这个字段应该从哪个上游字段取。最常见的必填字段包括业务范围、利润中心、成本中心、功能范围、订单号。它们通常是行项目里的辅助核算或内部单据号。排查时先打开一条完整的、能正常过账的凭证行项目把每个字段的值记下来再跟报错的凭证逐字段对比。差异就是问题所在。如果这条报错凭证是从业务模块抛来的那就需要回业务单据里维护对应的字段然后重新生成凭证。4.4 冲销失败与锁定解除方法月末冲销操作特别多也特别容易出问题。最典型的报错有两种一是“已清账凭证不允许冲销”二是“冲销时点不允许”。“已清账凭证不允许冲销”的意思是这张凭证下的未清项已经被后续的清账操作处理掉了。比如你冲销一张客户的收款凭证但对应的应收已经做了清账这时必须先清掉这笔清账关系才能做冲销。处理逻辑上比较安全的做法是先找清账凭证把它反冲销掉再冲销原凭证。“冲销时点不允许”则比较麻烦。很多系统规定已关账期间的凭证不允许冲销。如果确实需要调整已关账期间的数据只能用“重开过账期间”的方式。这块实际操作时必须谨慎因为任何对已关账期间的改动都会导致该期间报表重出而这个动作本身是能被系统日志记录的。4.5 抛帐重复与数据完整性校验有一次我在测试环境里做抛帐参数调整连续点了三次“重新抛帐”结果总账里出现了三张一模一样的凭证。排查后才发现系统的重新抛帐逻辑并不会自动检查“单据是否已经生成过凭证”必须在后台配置幂等性检查规则。也就是同一单据只能成功生成一次凭证。重复抛帐的预防靠的是“唯一索引”级别的控制而不是靠操作人员的自觉。这块的判断方法是把“流程单据号凭证类型年份”设成唯一组合当第二次抛帐时系统会提示“已存在关联凭证”从而终止操作。4.6 凭证总额平衡但明细方向错误这类问题是排查中比较容易漏掉的。系统在过账时只校验“借贷总额是否平衡”不会校验“每一条行项目方向是否合理”。举一个实际踩坑的例子某次销售出库抛帐仓库做出库操作后系统居然生成了两行贷方红字却没有对应的借方蓝字。借贷总额是平的但科目余额的增减方向完全反了。这类问题要提早预防。建议在抛帐规则里针对每个过账码配置“允许的方向”比如库存减少只允许记贷方库存增加只允许记借方。一旦生成凭证的方向与预设不一致直接抛错并终止生成而不是等月底对账时再发现问题。5. 配置脚本与常用查询SQL参考5.1 根据单据类型查询待过账凭证项目上线阶段我经常要通过后台数据库验证数据是否正常。下面的SQL适用于大多数MySQL系数据库方便你快速查看某个时间段内、某类业务单据产生的凭证状态SELECT bukrs AS 公司代码, belnr AS 凭证号, gjahr AS 会计年度, blart AS 凭证类型, bldat AS 凭证日期, budat AS 过账日期, cpudt AS 录入日期, usnam AS 录入人员, tcode AS 事务代码, statu AS 凭证状态 FROM bkpf WHERE budat BETWEEN 2024-10-01 AND 2024-10-31 AND blart IN (RV, SA, KZ) ORDER BY budat, belnr;如果只想看待过账的凭证再加一个状态过滤条件不同系统这个字段的名字不一样常见的是status、bstat或rjct。加过滤条件前先看看历史正常凭证的状态值是多少别上来就猜。5.2 查询凭证行项目与辅助核算凭证头表只是入口真正查明细还是得看行项目表。以SAP为例可以使用SELECT bseg.bukrs AS 公司代码, bseg.belnr AS 凭证号, bseg.gjahr AS 年度, bseg.koart AS 账户类型, bseg.hkont AS 科目, bseg.shkzg AS 借贷标志, bseg.dmbtr AS 本币金额, bseg.prctr AS 利润中心, bseg.kostl AS 成本中心, bseg.aufnr AS 订单号 FROM bseg WHERE bseg.bukrs 1000 AND bseg.gjahr 2024 AND bseg.hkont IN (10010101, 60010101) ORDER BY bseg.belnr, bseg.zeile;运营阶段查辅助核算缺失时这条SQL最实用。如果查出来的结果里利润中心或成本中心字段大量为空那就说明抛帐规则里没有配置辅助核算映射或者源单据上就没有填这些信息。5.3 快速判断借贷是否平衡如果怀疑某批凭证存在借贷不平衡的情况直接用这一条SELECT bkpf.belnr AS 凭证号, SUM(CASE WHEN bseg.shkzg S THEN bseg.dmbtr ELSE -bseg.dmbtr END) AS 余额 FROM bkpf JOIN bseg ON bkpf.belnr bseg.belnr AND bkpf.gjahr bseg.gjahr AND bkpf.bukrs bseg.bukrs WHERE bkpf.gjahr 2024 AND bkpf.budat BETWEEN 2024-10-01 AND 2024-10-31 GROUP BY bkpf.belnr HAVING ABS(SUM(CASE WHEN bseg.shkzg S THEN bseg.dmbtr ELSE -bseg.dmbtr END)) 0.01;余额不为0的凭证就是借贷不平的凭证。注意比较时不能直接用等号要用绝对值差因为浮点数存储会产生极小的误差。5.4 配置映射规则时参考逻辑映射规则的存储方式不同系统差异很大。有些是配置表有些是API接口有些是低代码平台里的业务规则。但核心逻辑是相通的可以用一段伪代码来表达IF 单据类型 销售出库 THEN 生成凭证类型 RV 行项目1: 科目 映射(收入科目, 客户组, 产品组) 方向 贷方 金额 单据含税金额 / (1 税率) 辅助核算 { 客户: 单据.客户代码, 部门: 单据.销售部门, 业务员: 单据.业务员 } 行项目2: 科目 映射(销项税科目, 税率, 是否出口) 方向 贷方 金额 单据含税金额 - 单据含税金额 / (1 税率) 行项目3: 科目 映射(应收科目, 客户的信用组) 方向 借方 金额 单据含税金额 END IF这套逻辑写出来以后建议拿最近三个月的历史单据做一遍“回归测试”看看同一张单子用新规则生成的凭证是不是和旧系统生成的凭证一致。不一致的地方要么是旧系统本来就有错要么是新规则还需要调。从我的经验来看这一步别省。直接上线新规则的代价是月底对账时你连错误源头都找不到。6. 跨模块协同与权限控制6.1 抛帐、过账职责分离设计财务内控里有一项基本要求叫职责分离。落到“抛帐过账”上就是不能由同一个人既做抛帐又做过账。哪怕是同一个财务人员负责全盘账务系统层面也要设置成业务单据的审核人与总账凭证的过账人必须不同。如果人员实在不够建议把业务单据审核权限和总账凭证过账权限分给两个不同的账号哪怕这两个账号实际上是同一个人在用也要人为制造这个操作壁垒。这个设计不是为了防内鬼而是为了防止错误和舞弊在同一个环节里被掩盖掉。一旦单据有问题过账人通常能看出来但如果是同一个人既做单据审核又做凭证过账错误的概率会明显更高。6.2 模块间数据一致性校验方法模块间数据不一致是抛帐过账项目上线初期最常见的问题。原因不外乎两个一是抛帐规则漏配二是过账期间不一致。校验方法其实不复杂。最实用的做法是每月底分别从业务模块和总账模块拉出“月度汇总表”对比关键科目余额和关键报表项目。比如销售模块的发货金额汇总与总账主营业务收入贷方发生额对比。采购模块的入库金额汇总与总账库存商品借方发生额对比。仓库的收发存结存余额与总账库存商品科目余额对比。如果差异不等于0优先检查的事是业务模块有没有单据已经过账但抛帐规则没有匹配上导致总账没生成凭证。其次检查辅助核算字段是否映射正确因为有时候金额对得上但挂错了部门也会导致利润中心报表失真。6.3 新业务场景上线时的检查流程企业新增一个业务场景比如新开电商渠道、新上一条产品线、新开展售后维修业务都必然要改动抛帐配置。这时候最忌讳的是直接在正式环境里加规则改完就跑。正确的做法是先在测试环境里把整个流程走一遍录入测试单据执行抛帐检查生成的凭证执行过账检查科目余额表。确认无误后再把配置迁移到正式环境。迁移后还需要用一笔小金额的真实单据做一次端到端验证。只有这单走通了才能认为新流程是安全的。7. 其他需要关注的细节7.1 外币业务与汇率取数逻辑有外币业务的企业抛帐时一定会遇到汇率取值问题。这里最常犯的错是把“业务单据上的汇率”和“过账当天的汇率”弄混。原则上业务单据上的汇率应该保持一致。也就是单据录入时用的是哪个汇率抛到总账时就用哪个汇率过账动作本身不能改变汇率。如果系统设计成“过账时重新取汇率”就会导致同一张凭证的币种金额不连贯月末评估时差异非常大。建议把汇率类型固定为M平均汇率或指定单一汇率并在过账校验中增加一致性检查。7.2 含税与未税金额的转换逻辑国内增值税环境下金额字段的来源必须清楚。抛帐时行项目上的金额到底是含税还是未税直接决定了收入科目和税金科目的准确性。最简单的处理方式是单据上保存含税金额和未税金额两个字段同时保存税率。抛帐时收入科目取未税金额税金科目取税额应收科目取含税金额。如果系统里没有现成的“税额”字段那就在规则里用公式计算税额 含税金额 - (含税金额 / (1 税率))这个公式本身很简单但执行中容易出问题的是税率的小数位。比如13%的税率含税金额113元未税金额是100元税额是13元。但如果你用浮点数直接算0.130000000000004这种误差就出来了。所以建议所有税额计算都通过整数分单位来做或者统一做四舍五入到分。7.3 审计追踪与凭证连查的实现审计追踪靠的是凭证上保存的“来源信息”。在抛帐环节必须确保每一张凭证都能反查到原始业务单据。标准的做法是在凭证行项目里保存两个字段来源单据类型和来源单据编号。过账后审计人员可以通过凭证联查功能直接跳转到原始单据。这块的坑在于很多系统默认不保存这两个字段导致凭证只能看到金额和科目看不到来源。等到审计需要时再补就非常痛苦了。所以建议项目上线前就和顾问确认好这两个字段的存储方案并出一个简单的凭证联查报表。8. 总结一点个人心得写了这么多其实核心还是那几句抛帐是入口设计过账是出口控制中间夹着的是映射规则和审核流程。每一个环节都不是孤立的它们相互影响也是整个财务信息系统里最容易出问题、也最能体现实施顾问水平的地方。我个人在实际操作中的体会是预算再紧、时间再赶也一定要在项目早期就把映射规则表做出来拉上财务、业务、IT三方一起评审而不是等开发完再返工。规则表一份Excel就够每一行注明科目、方向、金额来源、辅助核算取值逻辑、异常处理方式。这张表做得越好后续整个项目的实施周期越短、遗留问题越少。最后再分享一个小技巧月末结账前一定把“待过账凭证”清零。这不是说财务非得把所有凭证都过账而是要确保“待过账”列表里每一张凭证都是有明确用途的。如果放任不管T-3个月后你会连某张凭证为什么一直挂着都说不清楚审计一问就露怯。把列表维护成空说明整个流程是闭环的这是月结最核心的卫生习惯。