一套连锁真的能长进去的收银系统
一家餐饮连锁被自己收银机拖住的速度，快过它拥有的任何东西。Wezly 让每一家门店和每一个营业点跑在同一套符合 TSE 要求的收银系统上——并且已经支撑 HPC GmbH 经营了六年。
服务员真正拿来结账的那个收银界面：加料、折扣、滚动的总额，一次点按完成收款。 每一笔销售、退款和现金进出都记在同一本流水上——这正是一笔已签名交易必须留下的记录。 Kassensicherungsverordnung 要求随时可提供的 Kassensichv 导出文件，由实时交易记录生成，而不是事后拼凑出来的。 营业额、销售笔数和利润，从收银写下的同一批数据里，按月读回成一门生意的样子。
- 行业
- 零售与餐饮
- 市场
德国 - 交付年份
- 2020
Wezly 是我们为 HPC GmbH 构建的收银系统。它 2020 年上线，至今仍在运行。
它也是本站在别处那句主张背后的系统：从第一个版本起就满足德国税务要求的收银系统——而不是在一次稽查之后才满足。
多数收银系统搞错的结构
一家店需要一台收银机。一个打算变成好几家店的生意需要一套层级，而事后补上这套层级，正是没人会列进预算的那次迁移。
Wezly 从一开始就带着三层。一个企业有门店，一个门店有营业点，一个营业点有收银机。商品带变体，其属性按营业点解析，可以由规则决定，也可以手工设定——因为同一件商品在两个地点确实是不同的东西：不同的价格、不同的税务处理、周日不同的可售状态。
正是最后这一点，决定了总部能否真正管住这张网，还是每家分店悄悄变成自己的一座电子表格孤岛。
德国那部分为什么是难的那部分
在别的地方，收银系统是一块屏幕、一台打印机和一个读卡器。在德国，它是一个受监管的对象。依 Kassensicherungsverordnung，每一笔交易都必须由经认证的技术安全元件签名，而税务机关可以要求导出往前数年的结构化交易记录。
这不是等点单流程跑通之后再加的功能。它在第一行代码写下的那天，就决定了一笔销售如何被存储——因为一笔签过名的销售，事后不能被悄悄改动。把它当作后期需求的系统，最后都会被重写。
对标市场领先者，而不是对标一个模板
参照物是零售商原本会去买的那些产品，其中包括 Vend。整个开发过程中的问题不是「一台收银机最少需要什么」，而是「什么才会让一个人离开现有供应商」——这是更苛刻的一份规格，做出来也是另一种软件。
技术栈，在它要紧的地方
前端 Angular 配 NgRx，后端 Nest.js 与 Node，交易记录用 PostgreSQL 经由 TypeORM，需要即时反应的现场用 Firestore，底下是 Docker 与 Google Cloud。一个人从头做到尾。
这正是本站在别处概括的那种安排：您第一次会面时见到的工程师，就是写代码的那个人，而团队是刻意保持小规模的。
值得引用的结果是六年
不是一个上线数字。一套 2020 年建成的受监管系统，穿过中间发生的规则变动和平台升级，至今仍在服役。衡量标准是：五年之后，一套系统还能不能被一个当初不在场的人维护下去——而这一套已经越过了那道线。
本页内容
您的那一套需要做到什么？
与将要动手的那位工程师聊三十分钟，不是销售。关于范围、关于成本，以及关于真正的风险落在哪里，都会给直接的答案。