惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

F
Fortinet All Blogs
V2EX - 技术
V2EX - 技术
The Last Watchdog
The Last Watchdog
宝玉的分享
宝玉的分享
T
Tenable Blog
WordPress大学
WordPress大学
K
Kaspersky official blog
Microsoft Security Blog
Microsoft Security Blog
大猫的无限游戏
大猫的无限游戏
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Hacker News - Newest:
Hacker News - Newest: "LLM"
P
Palo Alto Networks Blog
Help Net Security
Help Net Security
V
Vulnerabilities – Threatpost
Know Your Adversary
Know Your Adversary
C
CXSECURITY Database RSS Feed - CXSecurity.com
A
Arctic Wolf
Forbes - Security
Forbes - Security
Microsoft Azure Blog
Microsoft Azure Blog
爱范儿
爱范儿
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
The Cloudflare Blog
Hugging Face - Blog
Hugging Face - Blog
H
Hacker News: Front Page
W
WeLiveSecurity
博客园 - 【当耐特】
G
Google Developers Blog
Martin Fowler
Martin Fowler
TaoSecurity Blog
TaoSecurity Blog
Hacker News: Ask HN
Hacker News: Ask HN
人人都是产品经理
人人都是产品经理
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
AI
AI
N
Netflix TechBlog - Medium
C
Cisco Blogs
I
Intezer
aimingoo的专栏
aimingoo的专栏
博客园 - 聂微东
G
GRAHAM CLULEY
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Apple Machine Learning Research
Apple Machine Learning Research
月光博客
月光博客
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
www.infosecurity-magazine.com
www.infosecurity-magazine.com
小众软件
小众软件
Blog — PlanetScale
Blog — PlanetScale
MyScale Blog
MyScale Blog
L
Lohrmann on Cybersecurity
Engineering at Meta
Engineering at Meta

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
ERP——采购模块产品设计
koi · 2023-01-11 · via 人人都是产品经理

在进行特定的业务之前,都需要采用商品,采购由专门的部分与人员进行需求的计划、执行。那么,为了支撑以上需求,需要采购系统来从中规范流程,提高效率。本文详细介绍了采购模块的产品设计流程,希望对你有所帮助。

一、采购简介

采购的日常工作用一句话总结就是在合适的时间,选择合适的供应商,以最合适的价格,采购合适质量和数量的产品。这也是采购的 5R 原则。

上述的采购的工作准则,但是在采购前需要做计划,也就是常说的备货计划,一些具体的公司有专门的计划部门,来决定什么商品进行采购,采购多少量。然后将这些信息形成一个采购需求,下推给采购部门进行采购。

要支撑上面的描述,离不开采购系统的支持,虽然各公司对采购部门的职责和工作内容都有出入,单大体都相同。

二、采购流程

本文介绍一下采购模块的系统设计,了解任何业务的第一步就是先了解主流程,采购模块的下单主流程如下:

上面只是一个采购的主流程,并不涉及一些细节,仅供参考,具体还是需要根据实际业务进行设计。

三、采购管理系统功能构架

四、采购的方案设计

4.1 备货计划

再聊备货计划前,先聊一下在公司中常见,也是最简单的一种备货场景,销售发现自己负责的一款产品,订单量很稳定,销量也高,但是产品的库存不足,为了保证订单的履约时效,销售会提采购需求让采购提前采购一批货放到仓库。

根据上面所描述的场景,备注第一步就是需要知道哪些产品需要补货,根据下面表格的数据,你会选择哪些产品进行备货?

  • A001是最理想需要备货的产品,每天的销量不高,但是每天的销量稳定;
  • A002某2天的销量较高,但单量不稳定,备货有滞销风险;
  • A003几乎每天都有订单,也可以进行备货,但是存在少量滞销的风险。

站在销售的角度,在备货的考量中“稳定的订单量>销量”,滞销是备货重点考量的一个因素,同时也是根据历史订单量和销量数据来判断产品是否需要备货,备货多少数量。

根据历史数据推断总会出现误差,比如某个产品的历史数据很好,之后这个产品就一直不出单,如果恰好这个产品的采购单价很高,那么这个产品的滞销成本也就非常高,这就引出了备货的第二个重点考量因素,采购单价。

试想一下,如果某个产品的采购单价为1W,备货1000个,就是1000W,针对这种高货值的产品,备货往往也是非常谨慎。

针对上面谈到的2点,来做一个小结:最理想的备货产品为每天销量高,订单量稳定,采购单价不高的产品。

备货计划的公式分析:

所有的备货逻辑都可以用一个公式概括,备货量=目标库存-当前库存。要触发备货计算,需要知道产品的备货点,备货点的设计常见有以下3种:

  1. 以安全库存作为备货点;
  2. 以过去X天的销量作为备货点;
  3. 以安全库存+过去X天的销量作为备货点。

类似水库的水位,当水库的水低于水位,就触发警报。采购中的备货点的逻辑也是这样,以上述第3种方式为例,备货点=日均销量+安全库存,这个备货点的计算并不完善,如果备货点的库存只支持5天的销量,但是供应商平均的采购交期需要7天,这样就会出现一种情况,在第5天的时候,公司的货已经买完了,但是供应商还有2天才把货送到。

所以备货点=采购交期*日均销量+安全库存,当然这个公式其实也不完善,做的更加精细化,可以将“采购处理时间”,“仓库的入库时间”等等因素,若涉及到海外仓,还需要考虑头程时间,海外仓的入库时间等等。

我们知道了备货点的计算,当货品的库存低于备货点,生成备货计划,那么备多少货,首先需要知道当前的库存有多少。当前库存=采购需求中的库存+在途库存+可用库存,其中在途库存=采购在途+调拨在途,若涉及海外仓,还需要考虑海外仓在途。

这里在多说一句,我之前待过的一家公司,供应商把货送到仓库,理货组把货签收了,此时并不计算货品的库存,只有上架后,才计算货品的库存,那么这种情况,当前的库存还需要加上采购待上架的库存,当然还是需要根据公司业务来设计方案。、

目标库存比较好理解,就是业务方想备多少货,通常这也会根据历史销量来推断备货量,如被10天销量的货,那么目标库存=日均销量*10+安全库存。

同样的目标库存的计算也需要考虑采购交期、采购处理时间等因素,根据上面计算公式,举个例子:安全库存为0,需要备10天的货,目前库存=100,当前库存为20,采购交期为3,根据这些因素得知,需要采购80=100-20个库存。又因为当前库存为20,采购交期为3,在采购到货的前一天,当前库存就卖完了,所以最终只备货了80个,8天的库存。

所以最终目前库存=(日均销量+采购交期)*10+安全库存,采购的处理,入库时间是否需要考虑,就根据公司业务处理。

借用木笔大佬的备货计划图,如下所示:

我上面说的是一个非常简单粗暴的公式,实际上要考量的因素会比较多,如:节假日、季节等因素。目标库存的计算(销售预测)有几下几种方案

平均法:

y=(x1+x2+x3)/3

如预测9月份的销量,9月份的销量=(8月销量+7月销量+6月销量)/3,这样就能够计算出来9月份的销量,从而来计算备货量。我上述推演的备货计划计算公式使用的就是这种方法,其中目标库存的公式中,“日均销量”采用的就是这种方法。

移动加权平均:

y=x1*n1+x2*n2+x3*n3

上述公式中的n为权重系数,预测9月份的销量,其中8月、7月、6月的权重系数为:0.5、0.3、0.2,那么9月份的销量=8月销量*0.5+7月销量*0.3+6月销量*0.2

易仓、店小秘在计算备货量时,提供了这种方案供用户选择。

指数平滑法:

y=a*x1+(1-a)*x2

  • y:本期预测销量;
  • a:0-1之间的权重系数;
  • x1:上期的实际销量;
  • x2:上期预测的销量。

指数平滑法本质就是一种特殊的移动加权平均,通过调整a来进行销售预测,如:上期实际销量为20,预测销量为10,a为0.7,本期销售预测=0.7*20+(1-0.7)*10,计算出来的结果为17,那么本期预测的销售为17。

调整过来a,来优化计算模型,a越大就越偏向实际销量模型计算,反之则偏向预测销量模型计算。

相似品预测法:

对于新品,没有历史数据,不能用上述的3种方法进行销售预测,可以根据商品的属性,如:分类、颜色、价格等等属性,找到相似的商品,根据相似商品的销售数据来推测新品数据。

小结:销售预测是一个非常复杂的功能,需要庞大的数据来搭建公司的销售预测模型,这里只是提几种方法。

4.2 采购需求

整个采购需求的业务流程如下:

采购需求的页面如下(仅供参考):

采购需求该功能主要是给销售等业务部门使用,由业务部门来确定要什么货(产品),要多少(数量)。

因为业务部门人员水平有差异,有些业务人员提出的需求并不合理,可能导致采购的需求过多造成产品的滞销,所以在业务员提采购需求后,不过直接给到采购,而是会在两者之间设一道审核的坎,一般由组长或专门的审单员进行采购需求的审核。

上面说的是由人工提交的采购需求需要审核,那么低于备货点自动生成的采购需求是否需要进行审核呢?这个根据个人的经验来说这个逻辑可以做成可配置,或者做成对应策略。如:采购货值<XX,就不需要审核之类的。

采购需求还需要有合并的功能,如果多个业务人员提出的采购需求相同,应该将采购需求合并,避免多次找同一个供应商采购产品。

MOQ:

MOQ为最低的起订量,如:必须采购10个,供应商才会发货。所以在创建采购需求时,系统自动选择满足MOQ最低的采购价。

此时采购A产品10个,根据“满足MOQ最低报价”的规则,系统会选择单价10的报价。

是否需要在采购需求阶段使用“满足MOQ最低报价”规则,需要根据公司业务而定,我上家公司需要在需求阶段展示,是因为销售在提交采购需求时,需要计算采购商品的利润。

4.3 采购单

采购单创建流程如下:

手动创建采购单,当时我发现有的系统手动创建有2种方式,一种是一种是有业务部门发布采购需求,下推生成采购单;另外一种则是由仓库负责发布采购单。

当时觉得很奇怪,一个货品是否需要采购,是由业务部门决定的,仓库肯定不能决定采购什么货品,后来和一些同事聊天得知,这2者主要是公司的业务和岗位职责的划分有关。

在外贸公司几乎不涉及到原料,公司的大部分产品都是成品,由销售负责货品的销售,销售把控库存,这种情况就是由销售下发采购需求,采购只需要执行采购需求。

在一些生产公司,销售和其它业务部门对原材料和辅料的感知程度较低,库存采购负责,这个时候就需要采购创建采购单,进行采购。

这里说一下销售转采购,本质就是用户下的销售订单缺货,然后吧缺货的部分快速生成采购单。

采购单的界面如下所示(仅供参考):

根据上面的原型图,结合业务一步一步展开来说,首先就是采购的下单,有2种方式方式:

  1. 线上下单:采购在1688或者淘宝等网站上寻找货源,并直接在网上下单采购,通过接口与1688网站进行数据交互。
  2. 线下下单:采购与供应商进行线下采购和交易,在系统进行采购单的数据补录。

线上下单,必须是采购选好货品后付款,供应商才会发货,类似我们在淘宝上购买东西,只有我们下单付款,供应商才会发货,整体的流程如下(以1688下单为例):

由上述流程可知,线下和线上采购的区别在在于线上需要,线上采购需要调用平台接口,与第三方平台进行交互。在跨境电商行业,采购单的创建区分了线上和线下(如:马帮、店小秘等),而国内电商则没有进行区分。

线上与线下下单,在财务方面的区别就是,线上下单必须“先付款再下单”,以1688为例,1688可以开通类似“花呗额度”,可以先使用额度给供应商付款,后期在还款。

线下下单通常走预付款、货到付款、账期几种形式。

  • 预付款:预先支付供应商付款的X%。
  • 货到付款:供应商把货送到仓库,且成功签收后,进行付款。
  • 账期:账期与预付款可以结合,供应商把货送过来后,XX天后结尾款,这个XX天就是账期。

因为线上和线下采购的缘故,在采购时就会有一些特殊场景:

下单的数量不满足MOQ(最小起订量),但是向供应商买一些其他的产品,保证供应商发货;

  • 供应商一些产品在线上卖,一些产品没有上架到线上,这种情况可以创建分别创建线上和线下采购单;
  • 供应商线上卖的是组合产品,但是我们只需要其中一个,这个时候也只能在系统层面创建一个线下采购单;
  • 同一个供应商有几个线上马甲。

上面说的都是系统流程,在业务层面的流程更加复杂的多,采购在下单之前会和供应商确定是否有货,下单的数量和单价供应商是否接收,是否能够在货期内到货等等,业务流程如下:

采购成本的计算:

在采购单中除了产品本身的货款,还有货物的装卸费、运费、供应商优惠额度等等费用,在计算采购成本时,需要将这些费用分摊到SKU,常见的分摊方式有3种:按照采购数量分摊,按照采购重量分摊,按照采购金额分摊。

这里以采购重量分摊为例,把运费进行分摊,计算公式:SKU的采购成本=采购货款+(SKU的重量/采购单中所有SKU的重量)*运费

其它分摊的计算公式也如上述一致,可能有同学不懂这个计算的意义在哪里,这个数据主要用于毛利的计算。如:A产品采购10个,计算出来的采购成本为100元,如果毛利想要达到50元,那么就需要卖150元(每个售价定15元)。

注意:这里的毛利和净利润不一样,具体毛利和净利和区别,我就不细说了,请大家去百度吧。

其中采购单到货后,采购将到货的数量下推到仓库,生成到货通知单。

采购单:到货通知单=1:N

最后在说一下采购单的状态,任何单据,订单的状态机都是非常重要的。采购有业务状态流和财务状态流,可以根据有“入库状态”和“结算状态”字段展示不同流程的状态。

入库状态:

  • 待入库
  • 部分入库
  • 已完成

付款状态:

  • 待付款
  • 部分付款
  • 全部付款

这里说一下“已完成”状态的细节,当WMS系统签收的数量=采购数量,代表全部入库,此时采购单自动标记为“已完成”。

还有一个手动标记“已完成”的场景,采购的商品只有部分签收,剩余的商品供应商不送了,这时需要手动标记“已完成”。

4.4 采购退货

采购退货的整个流程,如下图所示:

采购退货其中有2种退货方式,一种是直接退货,另一种是退换补发,上图的业务流程描述的是退货,代表这个货不要了,供应商需要将相应的货款退给公司,所以生成相应的采购结算单。

另一种则是退换补发,最常见的就是不良品,需要供应商重新发一批货过来,整个的流程与上述一致,只是不需要生成采购结算单。

采购退货单的设计和采购单的设计非常像,但是采购退货单是关联采购单,采购退货单的交互图如下:

采购退货单都是引用采购单,因此一个采购单可以生成多个采购单退货单,但是退货的数量不能>采购的数量。

这里有一个细节需要注意,因为采购退货单的创建,需要输入采购单号,那么退货的采购单价,直接读取采购单的采购单价。这个细节需要注意是因为我知道某个大公司并不是这样做的,以至于埋下了一个大坑。

如果供应商也有信息化系统,可以做一个采购退货的通知功能,通知供应商你已经发货。

4.5 采购费用开单

采购的费用开单主要作用于费用的补充和费用数据的对冲,常见的场景有:采购单的运费填错了,费用少了;采购过来需要有卸货费用等等,这些费用需要计算到采购单,计算采购单中SKU的采购成本。

交互图如下:

这里说一个题外话,根据我的项目经验,采购单中所有的信息都有可能填错,最常见的就是运费填写,因此我们可以将这些信息分成2类,业务信息和财务信息。

  1. 财务信息:运费、装卸费、采购费等等;
  2. 业务信息:接收仓库、采购员、签收员、供应商、SKU等等。

其中财务信息填错了,可以使用“采购费用单”进行数据对冲;业务信息填错了,个人建议重新创建新的采购单,至于原填错的采购单,如果下推到了仓库,进行了签收,那么在仓库创建“出入库单”进行“库存平账”。

4.6 采购结算单

一个采购单和采购退货款产生的所有费用会生成一个采购结算单。

采购单/采购退货单和采购结算单的关系为1:N。

结算常见有3种方式:

  1. 预付:采购预付款
  2. 按账期结算:与供应商协定,如每月月底结算货款
  3. 到货后结算:每完成1/N次履约后,就进行结算

不同的结算方式,采购结算单的创建也不同,如:预付,在成功创建采购单后,预付金额就生成相应“待审核”的采购结算单;账期的话就按照账期,生成相应“待审核”的采购结算单。

采购结算单审核通过后,提交给财务进行销账。

采购异常情况:

商品质量不合格:

签收100件商品,其中10件为次品,那么正品库存+90,次品库存+10。后续在通过采购退款,仓库的次品库存-10。

数量不符合:

1)少货

少货有2种情况,一种是供应链送过来的货确实少了,这种情况需要供应商吧剩余的货送过来;另一种则是供应商分批送货,并没有告知公司。

如:采购100个,供应链送了80个,这80个商品是否生成采购结算单?还是等到剩余的20个送过来后生成采购结算单?这种情况就根据公司业务设计,我之前的公司的业务为必须采购单完成才会生成结算单。

2)多货

有2种处理方案,一种是直接签收上架,另一种则是将多余的部分退回给供应商。

如:采购100个,供应商送了120个。

  • 签收120个,上架120个,结算时按照120个结算
  • 签收120个,上架100个,20个退回给供应商,结算时按照100个结算

错货:

采购100个,供应商送了100个,其中40个错货。

  1. 方案1:全单全部拒收,等待供应商重新送货
  2. 方案2:签收60个,并先上架,剩余部分退回给供应商,至于是先按照60个结算,还是等供应商把剩余部分送到仓库再结算。这2种方案都可以

五、总结

供应商模块文章就不进行更多说明了,实际上本文说的是市面上通用的产品设计方案,其中整个采购的难点在于采购的费用相关,如:采购的费用对冲影响历史数据、供应商的评分等。

一些偏向生产类型的公司,有自己长期合作的供应商,采购的商品也复杂多样,涉及原料、半成品、成品等。这些公司的会将采购模块抽离出来,单独做一个SRM系统,这就会涉及到采购合同、样品、供应商考核、供应商评分、询报价、比价、供应商返利等等操作。

在财务方面本人接触的不深,比如和供应商的对账出现了差异,生成差异单的处理。供应商的应付和财务的核销等等操作,有懂的老哥可以在本文留言,一起探讨。

本文由@koi 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash, 基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。