一个集装箱从离开堆场到最后一张发票，要经过许多环节：执行放箱的堆场、归还集装箱的客户、计算超期费的团队、负责收款的财务。在 MG-Atlantic，这整个过程都在一份档案里完成，平台是 Krak Stack，一款专为集装箱租赁商和贸易商打造的平台。本文说明这为我们的业务带来了哪些变化，以及运营方在选择工具前应当核实什么。
要点
一笔普通的单程租赁会产生约十个事件：客户需求、发给堆场的放箱指令、出场（gate-out）、运输、还箱指令、进场（gate-in）、还箱时的箱况、提箱费（pick-up charge）发票、超期费发票，有时还有一份损坏索赔。
当这些事件分散在不同工具中（库存表格、堆场邮件、发票模板、财务导出），每一次交接都意味着重新录入。代价高昂的错误正是在这里产生：按错误还箱日期计算的超期费、已归还却仍显示在租的集装箱、从未开票的提箱费、仍处于放箱状态却被挂出销售的集装箱。
箱队越大、合作堆场越多，这些核对就越费时，整体情况也越模糊。
在 Krak Stack 上，基本单位是集装箱，而不是合同。每个单元以经过校验且唯一的 ISO 6346 箱号识别，并记录其箱型（20DC、40HC、冷藏箱、框架箱等）、箱况、所在堆场和业务状态。
业务规则由系统执行，而不是靠团队记忆。一个集装箱不能同时出现在两份放箱指令或两份还箱指令中。提箱数量不能超过放箱数量，还箱数量不能超过还箱指令。每一次状态变更都会被记录、注明日期并可查阅。
对团队来说，这意味着一个问题只有一个答案：这个集装箱在哪里，还有什么需要开票？
MG-Atlantic 的租赁合同包括提箱费、免费天数、超期费（per diem）、堆存条件和损坏处理。Krak Stack 的租赁模块为每份合同保存这些条款。
免费天数根据系统记录的提箱和还箱日期逐箱计算。超期费发票直接由这些日期生成：没有人在表格里重新数天数。发票按类型区分（提箱费、超期费、堆存、损坏、买卖），增值税按开票对象处理。
对已结束租赁的核查还能确认没有任何提箱费或超期费漏开发票，并且每张发票都关联到正确的档案。
MG-Atlantic 既做租赁也做销售。在 Krak Stack 上，租赁和买卖共用同一份库存：租赁归来的集装箱可以挂出销售，以 gate buy 方式买入的集装箱与堆场中的集装箱一样进入库存。
交付条件记录在数据中。pick-up 方式下，买方在堆场提取箱子；gate buy 方式下，箱子尚在途中，落地前即已售出。这两个术语都不表示交易方向：gate buy 并不是买入，系统将这两个维度分开管理。
mg-atlantic.com 库存页面上显示的库存直接来自 Krak Stack：城市、箱型、箱况和状态。对于敏感数据，连接是刻意单向的：任何价格、成本或利润都不会从 ERP 流向公开网站。MG-Atlantic 的参考价格则走相反方向：由我们的团队决定，再传送到 ERP。
这种分离也让我们能够毫无例外地执行合规规则，例如绝不公布位于受限制国家的库存。
第一个收获是清晰。整个箱队在一个地方一览无余：哪些在堆场、在租、在途或已售，哪些已归还，哪些还待开票。集装箱一旦出场、归还或变更状态，团队立刻就能知道，无需等到月末核对。
第二个收获是工作量。如今，这个平台承担的工作原本至少需要三名操作员和一名财务控制人员：录入箱子动态、计算超期费、准备发票、在堆场、合同和财务之间交叉核对。
正因为这两点，我们把全部业务放在 Krak Stack 上运营，并向仍在使用分散工具的租赁商和贸易商推荐它。
无论选择 Krak Stack 还是其他工具，要问的问题都一样。
档案是否以集装箱为单位？只跟踪合同而不跟踪箱子的工具，无法说清某个箱号还有什么待开票。
超期费是否来自箱子的实际动态？如果天数要重新录入，错误只是被转移，而没有被消除。
租赁和买卖是否共用同一份库存？维护两份库存的混合型运营方，迟早会卖出一个仍在租的集装箱。
现场作业是否覆盖？在堆场闸口完成的记录，胜过晚上再誊写的清单。Krak Stack 提供包含全部界面的移动应用，还提供银行对账，以及自动读取堆场通过电子邮件发送的库存报告。
数据是否可追溯、托管位置是否合适？状态历史、角色与访问权限，以及面向欧洲运营方的欧洲托管。
Krak Stack 由日内瓦数字代理机构 EEvolve Me SA 开发并销售。MG-Atlantic 在实际业务中使用该平台，并作为试点运营方参与了它的打磨。
问题