商链广布，四通八达，然其全渠道经营，竟遇物量难明之障，速于所期。每店之POS，示其库之存；电商之网，显仓之货；客服之讯，乃昨日之景。当客问曰："吾之尺码，近处店铺可有此？"则无人能答全矣。

所试之修，常不效。其宜修者，乃二D365之组件，专为此弊而设也。

何故批量导出与每店数据库皆败

夜批作业导出至电商。電商庫存，一日而舊。客訂昨日售罄之「有貨」之物。退款之率漸高。履約之師惡之。

POS设备自各店铺数据库中取货。每店自成壁垒，跨店查询无从谈起。客访一店，不悉他店所藏，转手悬停之舞，必亲力为之。

仓储精管，唯及店铺。WMS虽合于仓储之务，然其初非为跨渠道库存之层而设。其重，不适于店铺；其不显实时之视于电子商务。

得法之式

二物相协而作

库存可见性插件。 乃近实时之库藏服务，能聚诸处（店铺、仓廪、途次）之货，汇于一览可询之境。为高读流量设——POS之器、电商之页、客服之吏，皆击同一服务，迟滞不过秒秒。F&O之实物流转，瞬息可达库藏可见之境。

散布之订单管理（DOM）。 订单既至，DOM遍察诸配货之库，依既定之则，择其最优之源（近店、运费廉、仓廪丰者）。支持自店发货、网购店提（BOPIS）、分批运及仓储预留。

共为零售之链，通渠道而明其所在，答“物在何处”之问，亦解“孰承此命”之惑。

货存可见之扩展

F&O之固有货存表，不能应零售之实时读——其优化于交易之完整，非高并发之查询。货存可见乃别之服务（Azure所托，微软所理），其：

• 受F&O货变之讯
• 保有非规范化、读优之视
• 显外系查询之 REST API
• 支持在库、预留、承诺可用量计算

零售之站指向库存可见性，可容万计查询每秒，不致 F&O 之 SQL 负荷

DOM 供源之则

或許有訂單至，DOM則審諸候補履約之處，依規則而斷：

• 距離——近於客者為優；
• 庫存——勿令倉廪空竭，失於安儲；
• 容量——店舖一日之能，不能過於N訂，自倉發往；
• 費用。 - 每承运商每区域之运费
• 优先级 - 旺季时优先仓库，淡季时优先店铺
• 除外 - 部分SKU仅能自仓库发货，部分则需自特定店铺发货

规则由人配置，非由码设定。零售团队依季节调整采购逻辑，无需工程师介入。

商务整合

此商务平台于二处整合：

• 展示 - 商品页显ATP于库存可见性，暂存而频新。标"有货——今日即发"，非"常需三至五日方达"。
• 结账 - 订单负载经由订单管理API，入DOM之DOM储备货品，于F&O中造履行之序。

Shopify、Magento及定制电子商务平台，有标准之连结器。此集成，一次性构建，后则恒定。

店铺级POS集成

Dynamics 365 Commerce（零售产品）可原生集成。第三方POS系统通过库存可见性REST API进行集成。店铺员工查询"此商品在我顾客尺码且附近任何店铺均有"只需调用一个服务端点。

已预留与可用

架构须精准处理之细节：何为"可用"？

• 现货 = 实际库存
• 已承他单，不纳新求；
• 可售 = 现有减已承之数
• ATP（承诺可得量） = 可供加承诺期内预计到货之数

库存可见性，于各处所及聚合层级，皆细算之。电商之站，或显可用；履约之队，重在手头；财会之司，系于已订。

架构之设，须明定此义，非临事方思。

架构所载何物

通渠道库存之栈，须具：

• 库存可见性插件，配置位置聚合（店铺、区域、全球）
• DOM采购规则，契合零售连锁之履行策略
• 电商集成，缓存调优以减显示迟滞
• POS集成（Commerce原生，第三方API驱动）
• 监控仪表盘，于库存可见性查询量与DOM决策迟滞
• 新增履行地点或调整规则之手册

模式可扩展。失败于此架构之团队，多尝以F&O本地库存服务零售规模之读取。此非其设计之本。用其所能。