改了什么,
一条条记在这里。

记账规则表多了「账套」一栏（内账／外账），总账页可以一键去看明细

• 记账规则表原本同一个事件会出现两列、逐字一模一样——让人以为资料重复；其实两列差在账套（内账／外账），而那一栏没有显示。现在多了「账套」一栏，两列当场分得出来。
• 总账页原本只读到一句「后端已经有了、前端还没接上」，读完不知道下一步去哪；现在给一颗「去试算表看明细 →」直接跳过去。
• 会计页的页签名称与面板标题统一（税那一页）。

日结的人力那一格，会说明「人力按 ¥0·未含提成」

• 日结「人力成本」那一格原本只给一个金额（例如 ¥0），没有说这个 0 代表什么。
• 现在有值时补上「人力按 ¥0·未含提成」；门店没设预设时薪时写「未设置（门店未设预设时薪·未计入）」，不印成 ¥0。

日结可以直接指名某一天；打错的网址会说「这个网址不是一个页面」

• 日结页现在可以直接用日期打开（网址带 ?date=），翻前／后一营业日时也会把日期写回网址——截图、读数、转给别人看，都能指名是哪一天。
• 后台里打错的网址（例：daily-close 这种拼法）不再静默显示成总览；会明说「这个网址不是一个页面」并且只给「回总览」。
• 日结页在没有数据时也保留字段骨架与口径说明，指标锚点在任何状态下都在。

日结多一列「低消补差」，赠送不再被当成扣减项

• 日结的账目阶梯多了一列「低消补差(加)」，来源与折扣同一组（已结单）。
• 阶梯现在可以当场对起来：原价合计 ＋ 低消补差 − 折扣 − 退款 ＝ 净销售。
• 「赠送」原本印成「赠送(减) −¥X」夹在折扣与退款中间，容易被拿去减——现在它列在阶梯外面、不带动减号，并注明它自己的母体不同（当日全部单·含未结）。
• 每一列都标了它的母体；同一母体内才可以相减。净销售的值没有因为这个改动而变化。
• 某一格后端还没给时，写「后端还没给这一格」，不会印成 0。

现金流水：短款／长款讲出来，全页只剩一种负号，折起来就看得到「应有现金」

• 班次差异原本只印一个金额（例如 ¥-400），没有方向词——对账的人会读成「负业绩」而不是「抽屉少了钱」。现在写「短款(Short) −¥400」／「长款(Over) +¥X」。
• 同一页原本有两种负号写法（一种在金额后面、一种是另一种字符），现在统一成一种：符号在前、负号用同一个字符。
• 折叠状态下也会显示「应有 ¥X」——「交班 100／应有 4,088」与「交班 100／应有 500」在列表上就能分辨，不用先展开。
• 净额那一行补上说明：净额 ＝ 收入合计 − 支出合计。

出品看板上几天前的漏单，不再印成「已超时 31550 分钟」

• 出品看板每一张票卡右上角原本都印「已超时 N 分钟」；跨日的漏单会把好几天前的时间也换算成分钟，实测出现过「已超时 31550 分钟」（约 22 天）。
• 现在本营业日内的照旧印分钟；跨日的一律换单位并标出来：「逾 N 天未出餐」。
• 还在等的单照显示、照排序，不会为了好看被清零。「跨日」标签、以及给机器读的年龄属性一起带上。

对账说「检查 0 项，全部一致」的时候，现在会直接说「无可检查项（不适用）」

• 对账页里每一项检查原本都印「检查 N 项，…」；当某一项**一笔都没扫到**时，它也印「检查 0 项，全部一致」——读起来像「查过了、没问题」，其实是什么都没查。
• 现在扫到 0 笔的那一项直接写「无可检查项（不适用）」，与「查过且一致」分开。
• 分母本来就算得出来（就是这一项实际扫过的单据笔数）；后端没给分母时会写「分母未提供」，不会印成 0。
• 有分母的那几项一个字都没动（例如「检查 128 项，全部一致」照旧）。

供應商門戶：多租戶的情況不再被說成『檔案不存在』

• 供應商在自己的入口查不到東西時，畫面說「档案不存在」——而真正的原因是跨租戶，不是檔案不見了。
• 這一條把那句假話換掉（`supplier_portal_views.py`）。說法改了、供應商讀得到，所以是產品更新。

供應商公開報價頁補上圖片／最小起訂量／交期三欄：三樣資料庫都有，那頁一樣都不給

• 供應商打開公開報價頁看不到商品圖、最小起訂量與交期——而這三樣在資料庫裡都有。
• 這一條把它們補上（`quote_link_service.py`）。供應商感覺得到，所以是產品更新。

客人菜單的圖片全破：`image` 欄吐的是儲存體 key，不是簽名網址

• 客人在菜單上看到的圖片全部是破的——序列化出去的是儲存體 key，前端拿它當網址用。
• 改成吐簽名網址（`apps/publicapi/serializers.py` 等）。這是客人直接看到的修復，所以是產品更新。

廚房出品看板：排隊顯示「幾項 · 幾張單」，跨日未出餐另外列、不再算進今天的等待

• 出品看板的標題原本只說「待做 N」（**品項數**），現在是「**待做 N 項 · M 張單**」，店長一眼看得出是幾張單在等。
• **跨日**還沒出餐的單，原本與今天的單混在一起算「已等幾分鐘」（21 天前那筆會顯示成三萬多分鐘）⇒ 現在**另外列**：「跨日未出餐 N 項 · 最久 D 天」，且**不參與今天的超時顏色**。

厨房出品

月度出勤把「还没到的班」记成旷班——演示店 14 个班全标旷工，其中 10 个在未来

• 用受限账号打开「人事 → 排班 → 月度出勤」，第一眼看到的是：演示店长 排班 14 · 准时 0 · 迟到 0 · 早退 0 · 旷班 14。
• 点开明细才发现，当天是 9 月 22 日，而那 14 个班排到 9 月 27 日 ⇒ 其中 10 个在未来，包括「今晚 18:00 的班」。系统把一个还没发生的班，写成了这个人旷工。
• ⚠️ 这比一般的「读不到当成 0」严重一级：旷班不是一个空值，它是对一个有名有姓的员工的指控，而且它会进工资（没来＝不给钱）。老板看到「旷班 14」会去找这个人谈。
• 根因是判定函数里完全没有时间判断：只要找不到对应的打卡记录，就无条件算旷班。⇒ 这对任何店都成立，不是演示数据的问题——只要这个月里有还没到的班就会发生，而「这个月剩下的班」本来就永远是未来的。
• 判准用「班结束了没有」而不是「班开始了没有」：一个 10:00–18:00 的班，中午十二点他可能还没打卡但人在路上，这时候说旷班一样是假的。只有班都结束了还没有任何打卡，才谈得上没来。
• ⚠️ 下一个人：跨夜班必须看排班的结束时刻，不是看日期。22:00–06:00 的班日期是「昨天」，用日期判会让它在第二天早上六点前都被误判成旷班。已经有测试钉住这一格（凌晨三点 ⇒ 未开始）。
• 现在多一栏「未开始」，不标红色——它不是坏消息，只是还没发生。标红会让老板去找一个没做错事的人。

排班打卡

班表上那句解释只在「读不到名册」时出现，而 65% 的情况走的是另一条路

• 上一轮补的那句解释挂在「名册读取失败」上。但名册读得到、而这个排班对象不在名册上时，格子照样只显示编号，而那句解释不出现——看到的跟修之前一模一样。
• 查了生产库：排班表未删 150 行、不同的排班对象 34 个。其中账号表里找得到的只有 13 个，查无此人的 21 个，账号存在但已停用的 1 个 ⇒ 22 / 34 = 65% 走的是没有解释的那条路。
• 根因不是业务状态，是孤儿数据：排班行上的员工字段是一个裸 UUID，不是外键 ⇒ 删掉账号不会连带清掉排班行，也没有任何约束会出声。前端把它渲染成「这个员工怎么了」，而真相是「这一行指向一个不存在的人」。
• 现在两句话分开，而且互斥：读不到名册（店长自己解决得了——去要权限）／有 N 个排班对象不在名册上（店长解决不了，那是数据的事）。两句话的行动不同，所以不能合并成「你没有权限」。
• ⚠️ 文案刻意不讲时间。第一版想写「这几个人的班还排在这一周」，查了之后是假的：那些行的日期全部落在一个月前，排在今天及以后的 0 行（对照：非孤儿且排在今天及以后的有 52 行，证明那个 0 是真的 0）。而且这一页可以往回翻，我们不知道用户站在哪一周。
• ⚠️ 下一个人：数的是不同的人，不是格子数。一个人排七天是十四格，报「14 个排班对象」会让店长去找十四个不存在的人。
• 🟡 那 34 行孤儿数据没有清，它横跨 11 个门店 / 2 个租户。稽核性质的历史排班该不该留是产品决定，这里只负责把它量出来。

排班打卡员工账号与权限

全站统一说「登录 / 退出 / 设备」——原来一半页面说的是台湾话

• 「登入」「登出」「装置」是台湾用法。产品面向大陆市场，这几个词读起来就是「外国软件」——而它们每一个字本身都是简体，所以繁简检查对它们永远是绿的。
• 这一轮改的是用户看得到的每一处：登入→登录、登出→退出、装置→设备。页首那颗按钮现在写「退出」，未结单的提示现在写「换设备／刷新后也能从这里接手结账」。
• ⚠️ 动手前先查了两格，因为机械替换最怕改到的不是显示文字：这四个词被当成比较值的地方 0 处（同一支检查对「任意中文字符串比较」命中 11 处，所以那个 0 是真的 0）；被当成对象键的 1 处是误报，那个冒号是三元运算符。
• 最该担心的一处逐行读了：操作日志的动作标签表里写着 user_login: '登入'。键才是后端存进日志的动作码，中文只是显示标签 ⇒ 改值不会让改动前后的日志对不上。
• ⚠️ 验收条件是「检查对这四个词回 0」，不是「我改了多少处」。改动数是过程量，会因为别人同时在改而对不上；回 0 才是状态量。改前 47/0/49/10，改后全部 0。
• ⚠️ 下一个人：这四个词已经收进检查的词表了，而且收表和清空是同一次提交——所以它从来没有以「一上线就红 N 处」的状态存在过。一个一上线就红一堆的检查，教会大家的是绕过它。
• 🟡 注释里还留着约 130 处「装置」。这是刻意的（这一轮的范围是用户看得到的文字，不碰注释也不碰标识符），但它跟上一轮「连注释一起改」的做法不一致——要不要统一是另一个决定，没有在这里顺手抹平。

员工账号与权限结账收款收款与小程序

发卡表单自己知道是不是记名卡，却没把这件事用在旁边的有效期栏上

• 礼品卡发卡表单里，输入购买人手机号之后它会即时告诉你「将绑到会员档案」还是「对不上本店会员，发成不记名卡」。而紧挨着的那个到期日输入框，原本任何日期都收，包括明天。
• 按《单用途商业预付卡管理办法》：记名卡不得设有效期；不记名卡有效期不得少于三年，超期还有余额的要能激活或换卡。⇒ 这张表单一步就做得出两种违规，而判断所需的信息就在它自己身上。
• 现在会出声：绑了会员还填日期，直接说记名卡不能设有效期；不记名卡填了不足三年的日期，直接给出最早能填的那一天。
• ⚠️ 是警告不是拦截。那个办法的备案义务按发卡企业规模分级，不是每家店都适用，硬拦会挡掉合法情况。把信息放在做决定的那一格，比替他决定好。而且抛开法规还有一条不分规模都成立的：卡到期而余额还在，等于你收了钱又留下。
• ⚠️ 母体是 0：正式机上 309 张礼品卡，设过有效期的一张都没有。所以这不是在修一个正在发生的问题，是在一个还没有人走过、但一步就走得到的路口放一块牌子。而 159 张是记名的——一旦有人开始填，比较可能踩的正是被禁止的那一种。

股东与分红

周排班上的「员工 0730170f」现在会说清楚为什么没有名字

• 整页 14 格都显示一串十六进位,店长看下周班表看不出是谁。
• 现在分四种说法:看不到姓名(没有员工名册权限)/ 姓名还没读到 / 不在本店名册上 / 没填姓名。
• 「不在本店名册上」这一种以前完全看不出来——它的意思是这个人离职了或调去别店,而他的班还排在这一周。

排班打卡

班表上一个人被排满七天、每天十三个半小时，而这页一个字都没说

• 用受限账号真的打开「人事 → 排班」，看到的是同一个人被排满周一到周日，每天两班：10:00–18:00 加 18:00–23:30，等于每天 13.5 小时、一周 94.5 小时。整页没有任何提示。
• 排班是少数「按下去之前就算得出后果」的画面——打卡记录是事后的，班表是事前的。事后的页面再准，也救不回一个已经排错的月份。
• 现在会按人给出提示：连排七天没有休息日（《劳动法》第三十八条）、单日超过 11 小时（第四十一条：加班每日一般 1 小时、特殊 3 小时）、整周超过 44 小时（第三十六条）。
• ⚠️ 只提示、不拦，措辞一律「请确认」不写「违法」。两个理由都是实的：综合计算工时制和不定时工时制是合法的（餐饮很常见，要人社局审批），拦下去就是拦一个合法经营；而且这个判断看不到请假、调休、代班、以及这个人在别的门店的班。
• ⚠️ 下一个人：这里最贵的坑是跨夜班。酒吧常见 20:00–02:00，结束时间比开始时间小，直接相减会得到负数，负数加进周总时数会让一个排了 90 小时的人算出 60 几小时——提示消失，而画面上一切正常。已按加 24 小时处理并校准过。
• ⚠️ 版面是一个人一行，不是一条提示一行。演示店只有一个员工所以看起来还好，但八个人的店会变成二十四行橙字堆在格子上面，没有人会读完。提示的单位是人，因为店长的动作是「去调某个人的班」。

排班打卡

班表上十四格全写「员工 0730170f」，而那个人的姓名后台里存得好好的

• 用受限账号打开周排班，整张表十四格印的都是「员工 0730170f」。查了后台：那个人的姓名是存着的，而且全库 615 个账号里，姓名为空的有 0 个。
• 所以这串编号从来不是「姓名没填」——它百分之百是「名册没读到」。写法上一个 ?? 把三种完全不同的情况折成同一串字：名册读不到、名册里没这个人、这个人没填姓名。
• 为什么一直没人发现：员工名册要的是「用户管理」权限，而这一页的门槛是「排班查看」权限。两个不同的码，所以店长进得来、名册读不到。用全权限账号走查永远看不到这一格。
• 最麻烦的一格：正确的那句解释本来就写好了，就在同一个文件里——但它在「新增排班」表单内，而表单只对有编辑权限的人显示。⇒ 只读的人看得到症状、看不到解释。
• 而他唯一看得到的权限说明是「安排/调整需要排班管理权限」，讲的是另一个权限。⇒ 这比没有说明更糟：它会把人指到错的方向。
• 现在把解释放到格子上方（只读也看得到），并且明写这是两个不同的权限。另外「找到了但姓名为空」改成一句不一样的话——今天走不到，但哪天真的出现，它不可以再混进「读不到」那一堆里。

排班打卡员工账号与权限

刚好充到 5000 的礼品卡会被警告「超过上限 5000」——浮点数加出来的那个零头

• 发卡和充值那两格会算「充完之后的余额」，拿去跟《单用途商业预付卡管理办法》第十八条的限额比：记名卡 5000、不记名卡 1000。
• 我第一版写成 Number(余额) + Number(充值额)。而计算机做小数加法时，4999.9 + 0.1 的结果是 5000.000000000001 ⇒ 一张刚好踩线、完全合法的卡会跳出一句「超过上限 5000 元」。
• ⚠️ 这个错的症状是安静的：画面上显示的金额是原值不是这个和，看起来完全正常。店员只会看到一句他无从查证的警告，然后学会忽略所有警告——这比直接报错更贵。
• 改成以「分」为单位相加再还原，并且抽成一个共用函数放进规则模块，五个发卡入口共用一份。抽出来而不是各改各的，是为了让下一个新增发卡入口的人在 import 那一行就撞见它。
• 同一轮还修掉：不记名卡三年有效期下限原本用设备时钟自己拼日期（库里规定这种日期只能有一份实现）；以及五处警告文案上我自己加的「⚠」前缀——库里既有的同类提示一个符号都没有，样式本来就由样式表给。
• ⚠️ 下一个人：别把它改成 Number((a + b).toFixed(2))。那看起来也对，但小数四舍五入之前得先做一次浮点加法，踩线那一格照样错，而且更难查——因为代码里已经有一个看起来像在处理精度的调用了。

礼品卡顾客 CRM

厨房那颗按钮写的是「全萤幕」——这一类字全是简体，所以繁简检查永远说它没问题

• 打开厨房出餐页，第一眼看到的按钮是「⛶ 全萤幕」。大陆说「全屏」。顺着查下去不是孤例：库存页有五句写着「连线暂停…网络恢复后会自动重试」——同一句话里台湾词和大陆词各用一次。
• 为什么一直没人发现：检查用的是繁→简的逐字比对。而「萤幕」「连线」「侦测」「记忆体」每一个字本身都已经是简体，逐字比对对它们永远是绿的。
• 这一轮改掉 22 处用户看得到的文案：全萤幕→全屏、网路连线→网络连接、连线暂停→网络中断、伺服器→服务器、侦测→检测、记忆体→内存。
• ⚠️ 母体量了两次差很多：不挖注释是 89 处，挖掉注释只剩 24 处——注释占了 65 处。报 89 会让人以为满库都是，而注释不是用户看得到的字。
• ⚠️ 24 处里还有 1 个误报：「请尽快取餐」被当成「快取」。子串比对必须逐条看，不能只数个数。
• 顺带修掉 54 处「帐」写成「账」：结帐→结账、帐号→账号、对帐→对账。对照库里正确的写法有 608 处 ⇒ 不是方言选择，是 8% 的钱字写错了，混在正确的里面看不出来。
• 改之前查了两格：前端零处把这些字当成比较值或对象键；后端也不产生这些字给前端显示。所以改文案不会改行为。

厨房出品进销存结账收款