小型零售 POS 系统
一家独立门店靠的是微薄的利润、现金与刷卡混杂的收款，以及老板打烊后能对上的那点账。大多数现成的 POS 套装按每台收银终端收租，把你的商品硬塞进泛泛的分类里，还把你的数据留在他们的子域名上；而「表格加读卡器」这种凑合的做法，则会悄无声息地把税、收款方式和库存都算乱。本文将带你走一遍一家小零售商真正需要的收银台，以及如何把它作为一个运行中、托管的应用搭建在 ybuild 上、通过你自己的域名对外提供服务。
痛点
- 销售税不是一个数字。在许多州，服装、食品杂货和某些商品是免税或减征的，而持有有效证书的转售商则一分不缴，所以对整个购物车套用一个统一税率，会向顾客多收钱，也会把你该缴的税报错。
- 现金是会凭空消失的真金白银。拆分收款、找零、从钱箱里付款整天都在发生，如果没有开机备用金、也没有「应有金额对点数金额」的收班对账，晚上的长款或短款就只会隐形，而不会被追查。
- 库存数字一周之内就会漂移。每一笔销售、退货和作废都必须以同样的方式影响库存，否则屏幕上的数字和货架上的数字会在下一次进货之前就分道扬镳。
- 你在向一个掌控着你商品目录的供应商按台缴租。价格、分类、收据和报表都住在他们的盒子里、他们的域名上，想改动其中任何一项，都得等他们的产品路线图。
你能搭什么
一个适合触屏操作的收银台：扫描条码或搜索商品、组建购物车、套用行项或整单折扣，看着税额按每一行的税种、以你门店的税率逐行计算。收款可在现金与刷卡之间拆分，自动算出找零，收据可打印或邮件发送。从第一次构建起，它就在 ybuild 上以在线托管的方式运行，跑在你自己的域名上。
一套商品目录，每件商品都带有成本、售价、税种、在手数量和补货点。一笔销售扣减库存，一次退款把它加回来，一次作废则从不触碰它，而低库存视图会标出所有低于补货点的商品，让你在周末之前就下单，而不是等断货之后。
一套班次模型：收银员以点好的备用金开出一个钱箱，整天收银，到收班时系统会显示应有现金对点数现金，并记录长款或短款。一张 Z 报表会汇总当天以及整个纳税期的销售额、已收税额和每一种收款方式，可随时导出给你的记账员，全部都在你那个在线运行的 ybuild 应用里完成。
数据模型
系统里的一天
- 开班：收银员登录并以点好的开机备用金开出一个钱箱班次，比如 150 美元的小面额钞票。收银台现在上线，本班次的每一笔销售都绑定到这个班次上。
- 第一笔销售：你扫描条码，商品以各自的价格和税种落入购物车，一张 10% 的优惠券作为行项折扣套用，税额只在应税行项上、按你门店的税率计算，然后汇总并只四舍五入一次。
- 收款：顾客一部分付现金、一部分刷卡。刷卡这一笔走你的支付处理商，回来的只有一个令牌、卡号后四位和卡组织品牌；找零在现金那一笔上计算，收据以邮件发送，每一行都扣减对应的商品数量。
- 退货：有人拿着收据把商品退回来。你按收据号把它调出来，以一条新的、相互关联的记录发起退款，精确冲销原来的税额和收款方式，并把商品放回货架。
- 更正：一次扫错在收款前作废，从不触碰库存；一笔已完成但开错的销售是退款、而不是删除，于是审计轨迹和库存数字都保持完整。
- 免税销售：持有转售证书的转售商免税购买。你把整单标记为免税、录入证书编号，任何一行都不收税。
- 补货检查：下午过半，低库存视图列出所有低于补货点的商品，让你在周末高峰之前就向供应商下单，而不是等卖光之后。
- 收班：收银员清点钱箱。系统显示应有现金（开机备用金加现金销售，减去现金退款和付款）对点数现金，记录长款或短款，并打印一张汇总销售额、已收税额和各收款方式合计的 Z 报表，全部托管在 ybuild 上。
AI 容易出错的地方
- 存储完整卡号。粗糙的做法会把整张卡号存下来，好让退款或补打收据更方便，可这会让你直接落入 PCI DSS 的合规范围，把门店变成一场数据泄露的连带责任。应用必须把卡交给支付处理商，只保留一个令牌、卡号后四位和卡组织品牌，永远看不到原始卡号。
- 用一个税率对整个小计征税。税额必须按每一行的税种、只对应税商品逐行计算，然后汇总并只精确到分四舍五入一次。对整个购物车套用一个统一税率，你就会在免税商品上多收、在别处少收，也会把该上缴的数额报错——而这恰恰会触发一次审计。
- 编辑或删除已完成的销售。作废和退款都必须是关联到原始记录的新记录，绝不是编辑或删除。已完成的销售一旦可以被改动，你的 Z 报表、你的税额合计和你的库存就再也对不上，你也熬不过一次审计。销售是只可追加的。
- 给刷卡建了模，却忘了现金。真实的门店会拆分收款、找零，还会从钱箱里付款，然后在收班时对账长款或短款。没有钱箱班次和「应有对点数」的核算，现金就这么消失，还无从查起。
- 任由库存在边角处漂移。退款必须把商品加回来，作废绝不能扣减，数量也绝不该悄悄变成负数。这里面漏掉一样，库存一周之内就成了虚构，补货点也就成了瞎猜。
- 收银台加库存这个内核：一套带有价格、税种和数量的商品目录，一个能扫描商品的购物车，按门店税率的逐行计税，现金与刷卡的拆分收款，以及销售即扣减的库存。
- 只可追加的销售，退款与作废都作为关联的冲销记录，于是每一笔已完成的销售、退货和更正都是一条能够对账的不可变记录。
- 带有日终收班的钱箱班次：开机备用金、应有对点数现金、长款或短款，以及一张汇总销售额、已收税额和各收款方式合计的 Z 报表。
- 一套完整的会计总账。把每日合计和已收税额导成 CSV 给你的记账员或 QuickBooks，而不是在收银台里重建一套复式记账。
- 多门店、按地址计算的税务引擎。v1 是一家门店、一张按税种索引的税率表；日后再加上不同税区和按地址查询税率。
- 电商、会员积分和营销自动化。先把柜台做出来，等收银台可信之后，再挂上线上商店或积分计划。
常见问题
我可以存下顾客的卡号，好让退款和收据更方便吗？
不行。存储完整卡号会让你落入 PCI DSS 的合规范围，是一项严重的连带责任。把卡交给你的支付处理商，只保留一个令牌、卡号后四位和卡组织品牌。退款引用处理商的交易 ID，所以你永远不需要原始卡号，而你的数据库即便被攻破，也不会泄露任何可用的卡数据。
系统怎样把免税商品的销售税算对？
每件商品都带有一个税种，比如标准、免税或减征。税额按每一行、只在应税行项上、以你门店的税率计算，然后汇总并只精确到分四舍五入一次。对于像持有有效证书的转售商这样的免税顾客，你把整单标记为免税并录入证书编号，于是万一日后被问起，凭证也在。
顾客退货时会发生什么？
你按收据号把原始销售调出来，以一条新的、相互关联的记录发起退款。它精确冲销原单的税额和收款方式、把商品加回库存，并作为一笔退款出现在你的 Z 报表上。原始销售从不被编辑或删除，于是这一天依然对得上账。
它能处理现金，还是只能刷卡？
都能，包括在一笔销售里拆分收款。收银员以点好的备用金开出一个钱箱班次，系统在整个班次里追踪现金销售、退款和付款，到收班时会显示应有现金对你点出的现金，并记录任何长款或短款。这套每日对账，正是一台真正的 POS 与一个只能刷卡的玩具之间的分界线。
我怎样摆脱现有 POS 的按台租金和子域名？
你描述想要的收银台、商品目录、税种和报表，ybuild 就会把这个运行中的应用构建出来，并托管在你自己的域名上。你的商品、价格和销售历史都存放在一个归你所有的托管数据库里，而不是被锁在某个供应商的终端里；而且为了敲一笔销售，你也不必再按台缴租。
参考来源
- PCI 安全标准委员会：PCI DSS — 发布 PCI DSS 的机构——这套支付卡数据安全标准适用于任何受理银行卡的商户，也正是 POS 必须对卡数据做令牌化、绝不存储完整卡号的原因。
- NRF 全美零售安全调查 — 美国零售联合会（NRF）关于零售损耗的基准报告，在其 2022 财年数据中，损耗率达到销售额的 1.6%（约 1120 亿美元）——一份准确、与销售相关联的库存盘点正是要把这部分损失控制住。
- Sales Tax Institute：经济联结与 South Dakota v. Wayfair 常见问答 — 一份被广泛引用的销售税科普资料，解释零售商在何时必须代收并上缴销售税——一旦门店开始做线上或跨州销售，这一点就变得至关重要。
描述它，一次性上线到你自己的域名——托管、全栈、无需服务器。免费开始。