M 安仕达烘焙ERP在线帮助 · 系统架构能力
8 项机制,一项一页 写法按后台真实界面读到的来 拿不准的标明"以实机为准"

一台系统能不能长期用,看的是这些看不见的定法

功能多不多,试用一天就能判断;而删除是抹掉还是可回退、权限按人勾还是按岗位给、单据能不能按行派生、审批能不能搬到手机上、该提醒的事由谁记着、门店那台和浏览器里那端各干什么、去年的旧账放在哪一层——这些决定三年后这家店还敢不敢把后台交给员工。这里把八项底层机制逐个拆开:它在哪一层生效、界面上读到了什么、什么时候不适用。

8项底层机制
4种审批走法可选
2端并行,读同一套账
9个页面读到回收站入口
数据回收站删除先标记,列表页一键回到回收站
工作岗位权限体系机构成树、角色定权、人只归岗
单据上下游行级流转按明细行引入,剩余量系统算
审批流程自定义四种走法按单据选,每环节留六项痕
系统提醒中心各模块声明事项,开关与接收人集中一处
数据安全管家首页一张体检表,六道闸门各在一层
多端应用:客户端与网页版现场动作走客户端,管理与看数走网页版
运行库与历史库分离一年以前的数据自动进历史库,旧账回客户端查
业务财务一体化单据生效之后,账从哪来

下面每张卡片对应一个独立说明页

本页 这套架构解决什么 能力亮点 机制目录 问题对照表 共用的几处 顺序与口径 四个角色 上线节奏 FAQ
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

8 项机制,按"敢不敢放手、跑不跑得动"分五组

点任意一张卡片进入该机制的独立说明页:解决的问题、在哪一层生效、一个真实例子、使用边界、与旧做法的对比、上手步骤与常见问题。最后一张卡片指向财务管理页——业财一体化这件事已经在那里单独讲透,这里不重复。

数据 · 删错了还能自己收场2 项权限敢下放的前提 · 删除是下架不是抹掉

删除先标记,列表页一键回到回收站

日常运营最怕的不是功能少,而是不敢给权限——给谁删除权,谁就可能删掉别人正在用的东西。回收站把这件事拆开:删除先把记录标记下架,记录仍留在库里,需要的人可以从回收站把它放回去。

看机制与例子

首页一张体检表,六道闸门各在一层

连锁老板对数据安全的实际担心是三个具体的问题:谁删了这条仓库、这份成本表被谁导出去过、这张历史单据的金额怎么变了。这台系统把答案做成了一张体检表——登录后台,首页位置就是数据安全管家,六个检查项各自给出条数与结论,顶部直接写"发现 2 项高风险问题,建议立即处理";它背后还有六道各自在跑的闸门。

看机制与例子
权限 · 敢把后台交给员工1 项按岗位给,不按人勾 · 入口、按钮、数据列三层分开

机构成树、角色定权、人只归岗

一家连锁几十号人,逐个员工勾权限必然勾漏、也必然勾多。这台系统把授权拆成三层:先看这个人属于哪个机构、再归哪个角色,最后由角色决定他能进哪些页面、能按哪些按钮、能看哪几列数据。

看机制与例子
单据 · 一单分几次走、谁点头才生效2 项上下游按行流转 · 审批可在钉钉上完成

按明细行引入,剩余量系统算

生意上的单子很少一次走完:客户订了五项货品,今天只有三项能出;采购下了八十个料,供应商分两车送。这台系统让下游单直接从上游客单的明细行里勾,勾一行带一行,行与行各算各的剩余量。

看机制与例子

四种走法按单据选,每环节留六项痕

烘焙连锁的审批经常卡在这里:单据在系统里躺着,老板在门店、在机场、在饭桌上。这套机制把审批环节搬到他手上那个软件里——钉钉、飞书、企业微信都行,点完同意,系统里的这张单自己就生效了。

看机制与例子
端与库 · 三年后还跑得动、说得清2 项每个部门按自己的习惯选端 · 旧账不陪今天的报表跑

现场动作走客户端,管理与看数走网页版

门店那一台机器要接钱箱、小票、电子秤,晚市排队时不能卡;老板和片区那一端要的是打开浏览器就能并排看六家店的账。这两件事用同一个界面兼顾不好,所以系统是两端并行:现场走客户端,管理与看数走网页版,两边读的是同一个账套。

看机制与例子

一年以前的数据自动进历史库,旧账回客户端查

连锁开到第三年,最难看的不是当月数,是查询越来越慢:库存明细账一翻就是几十万行,日销售汇总开一次要等。这套系统把库分成两层——运行库只装最近一年的业务,一年以前的单据按年自动归到历史库;日常查询走运行库,翻旧账回客户端。

看机制与例子
效率与账 · 该做的事系统记着2 项提醒集中一处 · 单据生效之后自然成账

各模块声明事项,开关与接收人集中一处

连锁日常里最容易丢的不是数据,是要办的事:会员卡快到期、订货单迟迟没引用、长期预订到了该备料的节点。这类事靠人记,人一忙就漏;这台系统把它做成一条链——各模块声明该提醒什么,一处配开关与提前几天,一处指定给谁,结果收进一个提醒中心。

看机制与例子

单据生效之后,账从哪来

单据生效之后自然成账:二百多类单据逐类开关,往来账按客户与供应商分开,凭证导出交给第三方财务软件。这一项已在财务管理那一页讲透,本页不重复。

跳去财务管理页财务管理方向 · 已在另一页讲透
DECISION TABLE

先想清楚此刻要回答哪个问题,再翻那一页

这张表按"你此刻碰上的那件事"倒推机制页,比按菜单列表找更快。左列是问题,中列是答案所在,右列是它不可替代的地方。

你要回答的问题看哪一页为什么是它
店长删错了一个仓库,谁去救?数据回收站回收站与"显示已删除"两条路都在功能页上,店长自己几分钟收场,不必停业务还原备份
新人入职,怎么当天就能上系统?工作岗位权限体系归到机构、归到角色即可;几十项开关固化在角色上,人只填一次身份
客户订了五项,今天只出三项怎么办?单据上下游行级流转销售单从订单按行勾,未勾的行原样留在订单里,剩余量系统算
老板常年不在电脑前,单据谁批?审批流程自定义审批走法可按单据切到钉钉那类办公软件,批过的记录六项齐全
会员到期、备料节点这些事谁记着?系统提醒中心提醒设置定开关与提前天数,接收人在一处指定,结果汇总到提醒中心
员工离职,怎么保证他带不走成本表?数据安全管家导出是独立一档动作,成本列按人下发;停用账号后按钮入口随角色消失
门店那台和总部的浏览器各干什么?多端应用:客户端与网页版现场动作走客户端,跨店看数、审批与配置走网页版,两端读同一套账
报表开到第三年越来越慢,先做什么?运行库与历史库分离先别加机器:运行库只压最近一年,一年以前的数据按年自动进历史库
单据生效之后,账从哪来?业务财务一体化业财一体化在财务管理那一页讲:二百多类单据逐类开关、导出凭证交给专业财务软件
SHARED SETTINGS

八项机制共用的那几处结构

机制之间的差别在管什么,但这六块是共通的:一个菜单、一套动作标记、一组单据状态、一条流转关系、一处已删除可见性、一份审批留痕。一次看懂,八页通用。

公共块后台里长什么样要注意的口径
系统管理这一个菜单用户管理、机构管理、角色管理、提醒设置与提醒中心、单据管理与第三方平台、数据安全管家都挂在它下面越靠近底层的入口,放开的人越少——实测"系统管理"这一类是配了机构范围的,不是对所有店开放
按钮上的动作标记每个工具栏按钮各带一个动作标记,新增、导出、修改、删除互不代替给权限时按动作给,不要按"这个人老实不老实"给;页面上没权的按钮是不出现的,不是灰着
单据的四个状态草稿、审批中、已生效、已关闭,列表上有独立一列只有已生效才把数量与金额压进库存与账;"审批中"占一格是为了让人知道这单还没算数
上下游的配对关系下游单上配置可引入的上游单据类型,实测已打通销售订单→销售单、销售单→退货单、采购订单→进货单三条不在这三条上的单据对,不能凭想象推广成"什么单都能上下游"
被删记录的可见性门店、仓库、分公司三类候选列表都带"显示已删除"这一开关,默认关闭打开后那条记录名字前带一截删除标记;它是核查用的,不是日常视图
审批留痕的六项阶段、审批步骤、审批人、状态、审批时间、审批意见;状态五种:待审、同意、拒绝、转交、退回这六项就是"这张单被谁认可过"的凭据,比群里一句"批过了"值钱
ORDER MATTERS

这几件事有先后顺序,反过来就一定返工

底层机制上线最常见的翻车不是不会用,而是顺序错了:先给人配权限再想立岗位、先把所有单都设成要审批、一上来把提醒全打开、端没分工就配权限。下面八条比多记一个按钮在哪更有价值。

  • 先机构、再角色、最后到人。顺序反了必返工:先给一堆人勾好权限,再想立岗位,就得一项项从人身上扒下来,扒不干净是长期隐患。
  • 先规范上游单据,再谈行级流转。引入是按行取数的。上游订单的单位、数量、批号录三遍改三遍,下游跟着抖三遍。
  • 审批先只加最贵的三类单:赊销、变价、超量采购。门店日常销售单一天几百张,压进审批只会让老板在手机上划到手软,最后关掉。
  • 提醒先少开、跑两周再补。一上来全开,两周后所有人都不再看这一屏;先开三到五项真影响当天经营的。
  • 删除的权限,跟回收站的权限一起给。给了删除不给回收站,等于让人踩在薄冰上;两者是一套动作的前后两半。
  • 备份与这套闸门分开安排。回收站救一条、权限挡一次、留痕查一回;整库出问题只能靠备份,多久备一次、能不能恢复出来,得单独回答。
  • 先定谁用哪一端,再谈权限。门店现场、总部职能、片区各用客户端还是网页版,先列清楚。端没定就配权限,最后会出现"该在门店那台办的事,被拿到微信里转一圈"。
  • 把"旧账去客户端查"写进财务流程。一年以前的数据在历史库,网页版查不到。这句话不写下来,第一次翻旧账一定会被当成数据丢失,然后是一通排查。
WHO CARES

同一套机制,四个角色各看一面

底层机制不是 IT 一个人的事:结构由实施与老板定,日常操作落在店长与一线身上,审批与提醒归到具体岗位,生效之后的账归财务。

老

老板

只看两处:审批待办与提醒中心

他要的是"我在手机上点一下,这单就能生效",以及"该做的事不用我提醒别人"。

店

店长

日常操作与收场

删错了自己回、开单从订单按行引、上班先开提醒中心一屏;权限给到位,他不需要找人。

实

实施与 IT

建结构的人

机构树、角色表、单据流转关系、审批通道与人员绑定是他的活;这张岗位表写得好,后面都顺。

财

财务与会计

看生效之后的账,也看去年的旧账

单据状态与审批记录决定这张单算不算数;一年以前的单在历史库,这一层要回客户端查;凭证与往来账在财务管理那一页继续讲。

GET STARTED

按第一天、第一周、第二周、第一个月的节奏上线

第一天:把结构立起来

在机构管理里画出总部—片区—门店这棵树;在角色管理里按岗位建 5 到 8 个角色,每个角色只回答三件事:进得去哪些页面、能按哪些动作、要不要看成本。顺手把"哪个部门用哪一端"写在同一张表上。

第一周:跑通一条单据链

选销售订单→销售单这一条,让一位店长按行引入两次分批出货,核对剩余量每一次都对得上;同时把回收站与"显示已删除"这两处教给他,让他体验一次自己收场。

第二周:加一道审批

只给最贵的那一类单加一级审批,选好是在系统内部还是钉钉上批,拿一张真单把提交、退回、再提交、同意四种情形都走一遍,确认六项留痕都对得上。

第一个月:把"别忘"这件事交给系统

在提醒设置里开三到五项,接收人在统一设置里指定到岗位;月底打开后台首页那张体检表,对照本页六道闸门复核一遍,缺哪一格补哪一格。

FAQ

关于这套底层机制,常被问到的十一件事

因为它们不属于任何一个业务模块,而是所有模块共用的定法:删除怎么处理、权限分几层、单据怎么派生、审批走哪条通道、提醒由谁声明。定法一致,新加一个业务方向就不用重新发明一遍。

机制本身在后台真实存在,本轮说明按功能级取证来写;涉及"明细页有哪些列、提醒推送走哪条通道"这类还没读到的界面细节,页面上都标注了以后台实机为准,没有编。

已经单独写过一整页,包括二百多类单据的逐类开关、往来账与凭证导出。这一组只讲底层机制,账的事不重复讲,见"财务与往来账"那张卡。

能。审批走法四选一,其中一种是系统内部审批,同意、拒绝、退回、转交四个动作都在系统里做,留痕一样。

权限管"谁能动",审批管"这一单要谁点头",回收站管"删错了怎么收场"。三者用同一批开关但方向不同,建议按这三问去对照自己的岗位表。

不会变难,只变多一步勾选。真正的成本在上游单据要录规范——这本来就是该有的要求,整单照抄的系统只是把这件事推给了月底对账的人。

后台另有微信应用下的消息模板与业务模板配置,但它们与提醒中心是不是同一条发送链路,本轮没有取证,所以我们不在页面上承诺渠道,只写能确定的三段:声明、开关与接收人、汇总清单。

每条记录都带账套归属,两套账的数据彼此分开,界面上甚至不需要出现这一列。同时经营两个品牌的客户,这是敢用同一套系统的前提。

不是,两端读同一个账套,账号、角色、权限配一次两端都认。差别只在能到哪一层:一年以前的数据在历史库,那一层只有客户端可达,网页版查不到。

先别花钱。把时间轴切开更管用:运行库只装最近一年的业务,一年以前的单据按年自动进历史库,日常查询不再背着几年的行数跑;真要翻旧账,回客户端查。

给正在评估系统的老板和要落地的实施同事都看:老板看"敢不敢把后台交给员工",实施看"结构怎么立、顺序怎么走"。业务方向的具体玩法请看各自的入口页。

从哪一页开始?建议先看「工作岗位权限体系」与「数据回收站」

这两页是一套因果:回收站让删除可以回退,权限才敢真的下放;岗位权限把结构立起来,单据流转、审批与提醒才有地方可挂。把它们看完,其余四页是同一套定法在别的环节的延伸。