SaaS架构:中央库存系统架构设计

  近年来,越来越多的零售企业大力发展全渠道业务。在销售额增长方面,通过线上的小程序、直播、平台渠道等方式,拓展流量变现渠道;在会员增长方面,通过各种各样的互动方式,全渠道触达消费者,扩大会员规模。

  全渠道库存管理也逐渐变成零售商在渠道运营中的核心活动,提高库存周转率,是保证利润的关键。在全渠道模式下,每个渠道都需要有足够的商品来满足客户需求,同时要有效管理总库存,平衡各渠道库存,以减少缺货或者滞销的情况发生。

在线上线下渠道融合的大背景下,如果没有管理好全渠道库存,会带来诸多问题:

➢各渠道库存分配不合理,不是缺货,就是库存积压。

➢各渠道库存数据更新不及时,有货下不了单,销售机会则会大量流失。

➢各渠道库存割裂,进行线上线下促销活动时,达不到库存数据共享,导致商品超卖,引起客诉,并且也无法知晓库存分布情况,无法统一采购/调拨。
➢无法根据用户的下单信息,进行智能分仓、就近发货。

 一、中央库存整体业务框架

  中央库存系统将库存管理总共分为了三层:销售层、调度层和仓库层,以最大限度地提高库存利用率,支持多仓库、多渠道模式下的各种业务场景。

1. 仓库层

  仓库层是分别针对各个仓库及门店实物进行管理,通过仓库WMS系统,门店系统及三方代发货ERP系统管理仓库进销存;通过出入库单据变更仓库的库存数量,即在货品入库时增加仓库库存,并在货品出库时扣减仓库库存。仓库库存的维度包括:货主、虚拟仓、SKU、批号、生产日期、库存状态、库位等。

➢货主:货物所有权的拥有者。

➢虚拟仓:同一个货主可能存在多个仓库或门店,该虚拟仓的定义就是与实体的仓库区分开来,有可能同一个实体仓包含多个虚拟仓。

➢SKU:仓库基于SKU进行货物的进销存。

➢批号:用于区分每一批投料生产出来的产品,为了事后能追踪这批产品的责任,每一批产品都有相应的批号,同一个SKU可能存在多个批号。

➢生产日期:生产线包装出可销售的成品的日期与时间。

➢库存状态:描述库存在不同业务场景下的不同状态,例如,可用、冻结、在途、不良品、废品等。

➢库位:SKU库存的最小粒度,一般是指在仓库中实际存在的库位,如:货架。

2. 调度层

  调度层是汇总各仓库或门店的所有库存状态的库存总量,但不同于仓库库存,调度层的实物库存无需管理批号、库位等细粒度的库存维度,只需管理每个库存状态下的实物库存总数即可,这是一种解耦的设计方式。实物库存的维度包括:仓库(或虚拟仓)、SKU、库存状态等。

关键概念包括:

➢在途库存:指供应商发货但尚未入库的库存,有时为了扩大销售机会,在途库存也会用于扩大销售库存数量。

➢可用实物库存:仓库实际可用于销售的库存。

➢不可用实物库存:仓库中的不可用库存。

➢销售预占库存:订单提交并分仓成功后,增加对应仓库的销售预占库存,订单取消或发货后,会扣减预占库存。

➢销售可用库存:销售可用库存=可用实物库存-销售预占库存(在计算分渠道库存时需要先算出仓库销售可用库存,销售可用库存发生变化时触发对分渠道销售可用库存的重新计算)。

3. 销售层

  销售层是管理各个销售渠道的渠道库存,为销售平台提供库存计算与库存同步的服务,并通过各种渠道库存分配策略进行库存分配,保证可销售数据和实物一致,防止超卖。销售库存的维度包括:销售渠道、销售店铺、送货方式、库存状态、发货区域、SKU等。

销售库存的相关属性包括:

➢销售渠道:代表各个销售渠道平台,包括自营的网店、门店线下渠道、天猫、京东、美团、移动医疗、电销及其他三方平台等。

➢销售店铺:销售的店铺或门店。

➢发货方式:包括配送和自提,分别汇总配送仓和自提仓相关数据。

➢库存状态:对于不同库存状态的库存需要分开处理。

➢配送区域:由于各个仓库覆盖的配送区域不一样,所以SKU能支持的配送范围也不同,可以按照区域维度分别汇总库。

➢销售可用库存:按照以上维度根据销售渠道、仓库、库存状态,SKU对所有分渠道销售库存数据进行筛选汇总;前台提交订单成功且订单分仓完毕则扣销售可用库存,发货前取消订单或订单同步到WMS系统则增加。在调度层的分渠道销售可用库存更新时,需同时触发销售层对相关销售渠道销售的SKU重新计算销售可用库存。

➢预售库存:如果商品未到货,可以开启预售模式,提前售卖。实物库存与预售库存是隔离开的,当实物到货后,预售库存统一推到实物库存进行履约。

➢预占库存:销售订单已提交但未支付之前,为给顾客预留商品,会先预占商品库存,待支付后再删除预占库存、扣减可销售库存,若取消订单,则会释放预占库存。

➢活动库存:主要是做促销活动时(比如特价、秒杀活动等),需设置活动库存,可从正常库存中分离出部分库存作为活动库存,在活动期间订单中商品有参加活动则扣减活动库存,未参加活动则扣减普通库存,最终在活动结束的时候将剩余的活动库存及产生的活动销售预占库存还回去。活动订单与普通订单,在库存处理逻辑上是一模一样的,如果无特殊要求,没必要单独把活动库存单独分出来,通过记录参加活动商品数量控制下单即可;分离活动库存的情况下,由于销售层的销售可用库存数量是需要根据调度层情况来变化的,相关逻辑设计起来比较复杂。

➢预留库存:若需要提前为某些促销活动预留库存,为了避免活动开始后库存不足,可设置预留库存。

➢可售库存:预售库存+销售可用库存-预占库存-预留库存。

二、逻辑模型设计

三、中央库存系统的定位

➢对接各地仓库或门店库存,将各地库存放在“一盘货”里,进行管理、统一调配。

➢打通所有销售渠道平台,实现全渠道库存共享、自动化运营。

四、中央库存系统的应用架构设计

五、库存的核心场景

1. 调度层同步

调度层的实物库存都来源于各仓库的库存,有两种同步模式:

➢数量同步模式:适用于外部系统对接,一般获取不到详细的库存流水,会通过商家后台或系统对接的方式同步库存实时数量。

➢流水同步模式:适用于内部系统打通,能获取仓库或门店的库存流水,通过回传流水,变更调度层的实物库存数量。这样存储了清晰的实物库存流水变更记录,方便查看每次库存变化明细,但要注意避免重复同步,防止库存数量变更出错。

2. 销售库存计算逻辑

  在多仓多渠道模式下,为了实现全渠道库存共享,库存汇总为“一盘货”管理,要充分考虑各个仓库或门店的特性,包括所支持的发货方式,配送范围等;为了合理分配库存,也需充分考虑各个销售店铺的库存占比。

下面来说几种常见的场景:

(1)单仓给多店供货    

  商家有1个电商仓,为商家的各个电商平台店铺提供仓储服务与发货服务,电商仓有100件iphone14。电商仓同时为京东店、天猫店供货,两个店铺仅支持快递发货方式,最大分配比例分别为80%、60%。

如下图,最终京东平台的iphone14的库存数量为80,天猫平台的iphone14的库存数量为60。

(2)多仓供货

  门店A和门店B为两个线下门店,门店A有100件iphone14,门店B有50件iphone14。假设商家有1个天猫店,门店A和门店B均给天猫店供货。天猫店仅支持快递发货方式,为了防止商品超卖,就设置快递的最大分配比例为80%。

如下图,最终天猫平台的iphone14的库存数量为120,并定期将数量同步到天猫平台。

(3)全渠道库存共享

  随着线上线下渠道加速融合,全渠道销售已经成为大部分零售商家的标配。并且现在的微信和小程序电商的发展迅速,有越来越多的门店都开启了云店模式,云店实际上就是门店的线上化交易渠道。

  很多连锁企业就会把线下门店接入到微信中,将门店所有商品上架到云店小程序,消费者无需到店,就能享受到门店的服务;同时门店的导购可以向自己的会员推荐所有云店商品。

如下图,门店A有100份的草莓蛋糕,门店A为自己供货,并共享草莓蛋糕的库存到多个销售渠道(美团外卖、云店、门店线下渠道),实现门店“一盘货”全渠道销售。

3. 渠道库存同步

  销售库存计算完后,将渠道库存同步到各个平台,这样消费者才能完成交易流程。根据渠道类型不同,渠道库存同步有两种处理逻辑:

➢自营系统:如果自营渠道与库存系统是一体的,则是一套系统,就不需要太过复杂的库存同步逻辑,自营渠道直接读取中央库存系统的渠道库存即可。

➢三方平台系统:像天猫,京东,美团等这些三方平台系统就属于外部系统,商家自身无法管控,所以就需要通过开发API,向三方平台同步渠道库存。一般都不会实时同步渠道库存,但只要有库存变动,就计算渠道库存,然后同步到三方平台。这种方式对系统压力会比较大,而且三方平台的API大多会按调用量来收取费用。所以大部分都会设定好时间间隔来定期同步渠道库存,例如10分钟一次。

4. 组合商品库存计算

  组合商品则是人为将几个单独售卖的商品组合在一起,进行商品合并后再售卖,例如:火锅套餐、美妆组合等等。组合商品会先在调度层,根据组合比例计算好虚拟库存,不影响子商品的供货逻辑,下单时,会根据组合商品标识,进行子商品的实物库存预占、扣减。

如下图,电商仓中,商品A有150件,商品B有200件,根据组合关系,可以算出组合商品C有100件。当下一单商品C时,会预占1件商品A+2件商品B的实物库存。

免责声明:本账号部分分享的资料来自网络收集和整理,所有文字和图片版权归属于原作者所有,文章仅供读者学习交流使用,并请自行核实相关内容,如文章内容涉及侵权,请联系后台管理员删除。
本文来源博客园,作者:汤师爷说,https://www.cnblogs.com/tangshiye/p/16768880.html

  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SaaS架构和微服务架构是两个不同的概念。SaaS架构是指软件即服务,是一种基于云计算的软件交付模式,用户通过互联网访问软件,而不是通过本地安装。而微服务架构是一种软件架构模式,将应用程序划分为一组小型服务,每个服务都可以独立部署、扩展和替换,服务之间通过轻量级通信机制进行通信。 下面是关于微服务架构的一些介绍和演示: 微服务架构的优点: - 每个服务都可以独立部署、扩展和替换,提高了系统的灵活性和可维护性。 - 服务之间通过轻量级通信机制进行通信,降低了服务之间的耦合度。 - 每个服务都有自己的数据库,避免了多个服务共享一个数据库的问题,提高了系统的可靠性和可扩展性。 微服务架构的缺点: - 系统的复杂度增加了,需要更多的管理和监控。 - 服务之间的通信变得更加复杂,需要更多的开发和测试工作。 - 部署和运维成本增加了,需要更多的人力和资源。 下面是一个简单的微服务架构示例,包含三个服务:用户服务、订单服务和支付服务。每个服务都有自己的数据库,服务之间通过REST API进行通信。 ```python # 用户服务 from flask import Flask, jsonify app = Flask(__name__) @app.route('/users/<int:user_id>') def get_user(user_id): # 查询用户信息 user = {'id': user_id, 'name': 'Alice'} return jsonify(user) if __name__ == '__main__': app.run() # 订单服务 from flask import Flask, jsonify app = Flask(__name__) @app.route('/orders/<int:order_id>') def get_order(order_id): # 查询订单信息 order = {'id': order_id, 'user_id': 1, 'amount': 100} return jsonify(order) if __name__ == '__main__': app.run() # 支付服务 from flask import Flask, jsonify app = Flask(__name__) @app.route('/pay', methods=['POST']) def pay(): # 处理支付请求 return jsonify({'status': 'success'}) if __name__ == '__main__': app.run() ```

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值