数据回收站
01删除先标记，列表页一键回到回收站
日常运营最怕的不是功能少，而是不敢给权限——给谁删除权，谁就可能删掉别人正在用的东西。回收站把这件事拆开：删除先把记录标记下架，记录仍留在库里，需要的人可以从回收站把它放回去。
看机制与例子
PAIN POINTS
连锁老板的七个"不敢"，都不是功能问题
不敢给删除权、不敢给后台账号、不敢让一线改价、不敢让店长自己收场、不敢让财务在网页版翻去年的账——每一句"不敢"，根子上都是这台系统对某件事的定法不够让人放心。
01
不敢给权限
基础资料、成本价、导出这几处最敏感：给出去怕出事，收着又变成老板一个人当运维，凡事等他登录。
把"能不能进、能不能按、能不能看这一列"分成三层控制，删除还留了回退的余地，权限才真的敢下放。
02
单据只能整单照抄
订单一次订、分几次出是常态。整单流转的系统逼着人改小上游单或另开无源单，数量关系当场断掉。
下游单从上游单的明细行里逐行勾，每行各算剩余，一张订单能派多张出货单。
03
审批卡在"找不到人"
老板在门店、在机场、在饭桌上，单据就在系统里躺着；微信里发张截图批过，事后没有凭据。
审批走法可按单据切换，能挂到钉钉那类办公软件上；每个环节留下阶段、步骤、人、状态、时间、意见六项。
04
该办的事靠人记
会员快到期、备料该开始了、调拨引进来还没处理——忘一件的成本都不小，而且没人知道忘了。
各模块声明可提醒事项，开关与提前天数一处配、接收人一处定，结果汇总成一个能翻的清单。
05
出事查不回
历史单据金额对不上、进价表被人导出过、仓库被谁删了——传统答案是"应该是吧"。
删除可查、动作有权、审批有痕、平台有日志，六道闸门分散在各层；首页那张体检表把结论收到一处。
06
三年后越来越慢、端越来越混
开到第三年，库存明细账一开就转圈；门店那台和总部的浏览器谁该干什么没人说清，出错就互相借账号。
账分两层：运行库只装最近一年，一年以前的数据按年自动进历史库；端按场景分工，现场动作走客户端，管理与看数走网页版。
07
底层机制没人讲清
客户问"你们和别家差在哪"，多数只能报功能清单；而真正决定能不能长期用的，是这些看不见的定法。
每一项机制都写清楚：它在哪一层生效、界面上能看到什么、什么时候不能用。
WHAT MAKES IT WORK
八项机制，撑住连锁扩张的底层秩序
每一项都把"出事之后能不能收场、三年后还跑不跑得动"当成目标：删除留退路、授权分层、单据按行走、审批留痕、提醒集中、安全有体检表、两端各按场景、旧账不陪跑。下面十二点，是已经在客户现场跑住的机制。
01
删除是"下架"，不是"抹掉"
被删的记录仍在库里，列表默认不显示；勾一下"显示已删除"能查回来，回收站在功能页里就能进。
02
授权分三层，各配一次
页面进不进得来、按钮按不按得动、这一列给不给他看，是三件事；成本相关列没有权限就整列不下发。
03
机构是一棵树
总部、片区、门店逐层挂；分店档案取的就是机构节点，"这家店归哪个片区"在系统里是结构不是一个文本框。
04
上下游按明细行流转
引入弹窗的勾选单位是行，确认时问的是"引入选中的几行"，剩余量由系统逐行算好。
05
审批走法四选一
内部审批、钉钉、飞书、企业微信；同一后台里不同单据当前用的不是同一种，说明可按单据分别定。
06
一张单在四个状态之间走
草稿、审批中、已生效、已关闭；审批没走完的单不会把数量压到库存与账上。
07
提醒是平台级公共通道
新开一个业务方向，只要声明"该提醒什么"，开关、接收人、汇总清单三段全是现成的。
08
带走数据是单独一档权
导出与导出选中各算一格，可以配出"能看报表但不能把明细导出去"。
09
每条记录带账套归属
同时经营两个品牌、两套账时数据彼此分开，界面上甚至不需要出现这一列。
10
安全有一张体检表
后台首页就是数据安全管家：六个检查项各给条数与结论，分安全、警告、风险三档，点「查看详情」落到名单。
11
两端读的是同一套账
门店那台走客户端、总部浏览器走网页版，账号与权限配一次两端都认；不是二选一，是按动作分。
12
旧账不陪今天的报表跑
运行库只装最近一年，一年以前的单据按年自动进历史库；翻旧账回客户端，日常查询轻下来。
PLAYBOOK
每一项机制，都对应一个会失控的环节
每一项机制都讲清：解决什么问题、在哪一层生效、一个真实例子、使用边界、与旧做法的对比、上手步骤与常见问题。业财一体化属于财务管理，这里不再重复。
数据 · 删错了还能自己收场2 项
数据安全管家
06首页一张体检表，六道闸门各在一层
连锁老板对数据安全的实际担心是三个具体的问题：谁删了这条仓库、这份成本表被谁导出去过、这张历史单据的金额怎么变了。这台系统把答案做成了一张体检表——登录后台，首页位置就是数据安全管家，六个检查项各自给出条数与结论，顶部直接写"发现 2 项高风险问题，建议立即处理"；它背后还有六道各自在跑的闸门。
看机制与例子
权限 · 敢把后台交给员工1 项
工作岗位权限体系
02机构成树、角色定权、人只归岗
一家连锁几十号人，逐个员工勾权限必然勾漏、也必然勾多。这台系统把授权拆成三层：先看这个人属于哪个机构、再归哪个角色，最后由角色决定他能进哪些页面、能按哪些按钮、能看哪几列数据。
看机制与例子
单据 · 一单分几次走、谁点头才生效2 项
端与库 · 三年后还跑得动、说得清2 项
现场动作走客户端，管理与看数走网页版
门店那一台机器要接钱箱、小票、电子秤，晚市排队时不能卡；老板和片区那一端要的是打开浏览器就能并排看六家店的账。这两件事用同一个界面兼顾不好，所以系统是两端并行：现场走客户端，管理与看数走网页版，两边读的是同一个账套。
看机制与例子
一年以前的数据自动进历史库，旧账回客户端查
连锁开到第三年，最难看的不是当月数，是查询越来越慢：库存明细账一翻就是几十万行，日销售汇总开一次要等。这套系统把库分成两层——运行库只装最近一年的业务，一年以前的单据按年自动归到历史库；日常查询走运行库，翻旧账回客户端。
看机制与例子
DECISION TABLE
按此刻要回答的问题，找到对应机制
把此刻碰上的那件事说出来，下面就能找到对应机制，以及它不可替代的地方。
| 你要回答的问题 | 对应能力 | 为什么是它 |
|---|---|---|
| 店长删错了一个仓库，谁去救？ | 数据回收站 | 回收站与"显示已删除"两条路都在功能页上，店长自己几分钟收场，不必停业务还原备份 |
| 新人入职，怎么当天就能上系统？ | 工作岗位权限体系 | 归到机构、归到角色即可；几十项开关固化在角色上，人只填一次身份 |
| 客户订了五项，今天只出三项怎么办？ | 单据上下游行级流转 | 销售单从订单按行勾，未勾的行原样留在订单里，剩余量系统算 |
| 老板常年不在电脑前，单据谁批？ | 审批流程自定义 | 审批走法可按单据切到钉钉那类办公软件，批过的记录六项齐全 |
| 会员到期、备料节点这些事谁记着？ | 系统提醒中心 | 提醒设置定开关与提前天数，接收人在一处指定，结果汇总到提醒中心 |
| 员工离职，怎么保证他带不走成本表？ | 数据安全管家 | 导出是独立一档动作，成本列按人下发；停用账号后按钮入口随角色消失 |
| 门店那台和总部的浏览器各干什么？ | 多端应用：客户端与网页版 | 现场动作走客户端，跨店看数、审批与配置走网页版，两端读同一套账 |
| 报表开到第三年越来越慢，先做什么？ | 运行库与历史库分离 | 先别加机器：运行库只压最近一年，一年以前的数据按年自动进历史库 |
| 单据生效之后，账从哪来？ | 业务财务一体化 | 业财一体化在财务管理里讲：二百多类单据逐类开关、导出凭证交给专业财务软件 |
SHARED SETTINGS
八项机制共用的那几处结构
机制之间的差别在管什么，但这六块是共通的：一个菜单、一套动作标记、一组单据状态、一条流转关系、一处已删除可见性、一份审批留痕。一次看懂，八页通用。
| 公共块 | 后台里长什么样 | 要注意的口径 |
|---|---|---|
| 系统管理这一个菜单 | 用户管理、机构管理、角色管理、提醒设置与提醒中心、单据管理与第三方平台、数据安全管家都挂在它下面 | 越靠近底层的入口，放开的人越少——"系统管理"这一类是配了机构范围的，不是对所有店开放 |
| 按钮上的动作标记 | 每个工具栏按钮各带一个动作标记，新增、导出、修改、删除互不代替 | 给权限时按动作给，不要按"这个人老实不老实"给；页面上没权的按钮是不出现的，不是灰着 |
| 单据的四个状态 | 草稿、审批中、已生效、已关闭，列表上有独立一列 | 只有已生效才把数量与金额压进库存与账；"审批中"占一格是为了让人知道这单还没算数 |
| 上下游的配对关系 | 下游单上配置可引入的上游单据类型，已打通销售订单→销售单、销售单→退货单、采购订单→进货单三条 | 不在这三条上的单据对，不能凭想象推广成"什么单都能上下游" |
| 被删记录的可见性 | 门店、仓库、分公司三类候选列表都带"显示已删除"这一开关，默认关闭 | 打开后那条记录名字前带一截删除标记；它是核查用的，不是日常视图 |
| 审批留痕的六项 | 阶段、审批步骤、审批人、状态、审批时间、审批意见；状态五种：待审、同意、拒绝、转交、退回 | 这六项就是"这张单被谁认可过"的凭据，比群里一句"批过了"值钱 |
ORDER MATTERS
这几件事有先后顺序，反过来就一定返工
底层机制上线最常见的翻车不是不会用，而是顺序错了：先给人配权限再想立岗位、先把所有单都设成要审批、一上来把提醒全打开、端没分工就配权限。下面八条比多记一个按钮在哪更有价值。
- 先机构、再角色、最后到人。顺序反了必返工：先给一堆人勾好权限，再想立岗位，就得一项项从人身上扒下来，扒不干净是长期隐患。
- 先规范上游单据，再谈行级流转。引入是按行取数的。上游订单的单位、数量、批号录三遍改三遍，下游跟着抖三遍。
- 审批先只加最贵的三类单：赊销、变价、超量采购。门店日常销售单一天几百张，压进审批只会让老板在手机上划到手软，最后关掉。
- 提醒先少开、跑两周再补。一上来全开，两周后所有人都不再看这一屏；先开三到五项真影响当天经营的。
- 删除的权限，跟回收站的权限一起给。给了删除不给回收站，等于让人踩在薄冰上；两者是一套动作的前后两半。
- 备份与这套闸门分开安排。回收站救一条、权限挡一次、留痕查一回；整库出问题只能靠备份，多久备一次、能不能恢复出来，得单独回答。
- 先定谁用哪一端，再谈权限。门店现场、总部职能、片区各用客户端还是网页版，先列清楚。端没定就配权限，最后会出现"该在门店那台办的事，被拿到微信里转一圈"。
- 把"旧账去客户端查"写进财务流程。一年以前的数据在历史库，网页版查不到。这句话不写下来，第一次翻旧账一定会被当成数据丢失，然后是一通排查。
WHO CARES
同一套机制，四个角色各看一面
底层机制不是 IT 一个人的事：结构由实施与老板定，日常操作落在店长与一线身上，审批与提醒归到具体岗位，生效之后的账归财务。
老
老板
只看两处：审批待办与提醒中心
他要的是"我在手机上点一下，这单就能生效"，以及"该做的事不用我提醒别人"。
店
店长
日常操作与收场
删错了自己回、开单从订单按行引、上班先开提醒中心一屏；权限给到位，他不需要找人。
实
实施与 IT
建结构的人
机构树、角色表、单据流转关系、审批通道与人员绑定是他的活；这张岗位表写得好，后面都顺。
财
财务与会计
看生效之后的账，也看去年的旧账
单据状态与审批记录决定这张单算不算数；一年以前的单在历史库，这一层要回客户端查；凭证与往来账在财务管理那一页继续讲。
GET STARTED
按第一天、第一周、第二周、第一个月的节奏上线
第一天：把结构立起来
在机构管理里画出总部—片区—门店这棵树；在角色管理里按岗位建 5 到 8 个角色，每个角色只回答三件事：进得去哪些页面、能按哪些动作、要不要看成本。顺手把"哪个部门用哪一端"写在同一张表上。
第一周：跑通一条单据链
选销售订单→销售单这一条，让一位店长按行引入两次分批出货，核对剩余量每一次都对得上；同时把回收站与"显示已删除"这两处教给他，让他体验一次自己收场。
第二周：加一道审批
只给最贵的那一类单加一级审批，选好是在系统内部还是钉钉上批，拿一张真单把提交、退回、再提交、同意四种情形都走一遍，确认六项留痕都对得上。
第一个月：把"别忘"这件事交给系统
在提醒设置里开三到五项，接收人在统一设置里指定到岗位；月底打开后台首页那张体检表，对照这六道闸门复核一遍，缺哪一格补哪一格。
FAQ
关于这套底层机制，常被问到的十一件事
因为它们不属于任何一个业务模块，而是所有模块共用的定法：删除怎么处理、权限分几层、单据怎么派生、审批走哪条通道、提醒由谁声明。定法一致，新加一个业务方向就不用重新发明一遍。
机制本身在后台真实存在，下面逐项看每项机制怎么用；涉及"明细页有哪些列、提醒推送走哪条通道"这类界面细节，以你实际使用的版本为准，实施时可在后台逐项确认。
已经单独写过一整页，包括二百多类单据的逐类开关、往来账与凭证导出。这里只讲底层机制，账的事不重复讲，见"财务与往来账"那张卡。
能。审批走法四选一，其中一种是系统内部审批，同意、拒绝、退回、转交四个动作都在系统里做，留痕一样。
权限管"谁能动"，审批管"这一单要谁点头"，回收站管"删错了怎么收场"。三者用同一批开关但方向不同，建议按这三问去对照自己的岗位表。
不会变难，只变多一步勾选。真正的成本在上游单据要录规范——这本来就是该有的要求，整单照抄的系统只是把这件事推给了月底对账的人。
后台另有微信应用下的消息模板与业务模板配置，提醒最终从哪一端发出，上线时按你的通知渠道一并配置；这里讲清三段：声明、开关与接收人、汇总清单。
每条记录都带账套归属，两套账的数据彼此分开，界面上甚至不需要出现这一列。同时经营两个品牌的客户，这是敢用同一套系统的前提。
不是，两端读同一个账套，账号、角色、权限配一次两端都认。差别只在能到哪一层：一年以前的数据在历史库，那一层只有客户端可达，网页版查不到。
先别花钱。把时间轴切开更管用：运行库只装最近一年的业务，一年以前的单据按年自动进历史库，日常查询不再背着几年的行数跑；真要翻旧账，回客户端查。
适合连锁烘焙企业的老板与实施负责人一起看：老板看"敢不敢把后台交给员工"，实施看"结构怎么立、顺序怎么走"。具体业务玩法，在对应的功能板块里展开。