业财通识01:企业花钱的第一步——从采购需求到法律合同
当我们为新项目申请几台云服务器时,背后触发的,其实就是这套"商业源代码"中最基础的一个函数调用。这个调用,最终会转化为公司资产负债表上的一笔数字。这背后,是一套严谨、环环相扣的流程——采购到付款(Procurement to Pay, P2…
围绕业财一体、采购、销售、库存与财务模型,按顺序组织为长期可阅读的专栏。
适合正在建设复杂业务系统、ERP 或流程平台的研发与架构读者。
当我们为新项目申请几台云服务器时,背后触发的,其实就是这套"商业源代码"中最基础的一个函数调用。这个调用,最终会转化为公司资产负债表上的一笔数字。这背后,是一套严谨、环环相扣的流程——采购到付款(Procurement to Pay, P2…
收货,绝不仅仅是"签收快递"那么简单。在企业管理中,它是一个充满细节、关乎数据准确性的关键节点。 收货是仓库管理人员(仓管)依据采购订单(PO),对供应商送达的货物进行实物数量、外观质量核对与检验的过程。它是连接"订单"与"实物"的桥梁。…
在任何一家管理规范的公司,收到发票到真正付款之间,都存在一道至关重要的控制关口。设置这一关口,是为了避免以下风险: 采购员和供应商私下改了价格,公司为高价买了单。 仓库明明只收了 98 箱货,供应商却开了 100 箱的发票。 一笔订单被重复…
至此,P2P(Procurement to Pay)的前半段——Procurement(采购)环节已经完成。现在,我们进入通往资金出口的最后一个关键环节——Pay(付款)。 付款流程的核心目标是:在正确的时间,以正确的方式,将正确的金额,付…
你一定在电商平台上买过东西。当你打开某个商品页面,比如"iPhone 17 Pro"时,你会发现页面下方有多个选项: 颜色:银色、深空黑、原色钛金属、蓝色钛金属 存储容量:256GB、512GB、1TB 当你选择了"银色 256GB"后,系…
如果你不考虑这批"在路上"的货物,可能会发生什么? 销售部门询问:"这个 SKU 还有货吗?"你回答:"当前库存只有 50 台,没货了。"但实际上,还有 100 台正在路上,3 天后就能到。 采购部门看到库存不足,又下了一笔 100 台的订…
场景一:月底最后一天入库,发票下月才到 月底最后一天,货物入库了,但供应商的发票要下个月才能寄到。如果等发票来了再记账,9 月份的财务报表就会失真。 场景二:供应商发票开具有延迟 有些供应商发票开具有延迟,可能晚 1-2 个月才寄到。如果一…
O2C 流程与 P2P 流程在结构上有着奇妙的对称性: 理解这种对称性,能帮助你更快地建立对 O2C 流程的认知框架。今天,我们就一起走进 O2C 的第一个关键步骤:从发现商机到签订销售订单。 想象一下,你是一名销售,在展会上遇到了一位潜在…
在上一篇文章中,我们已经把销售机会转化为了销售订单。现在,销售团队带来一笔新的大额订单:客户计划下达 50 万元的采购需求,并承诺 30 天内付款。 从销售视角看,这似乎是一笔值得推进的订单;但从财务或风控视角看,首先需要确认的是:这个客户…
在上一篇文章中,我们成功地将销售订单通过了信用检查,订单状态变为"已确认"。这意味着企业已经对客户做出了正式的销售承诺:我们会在约定时间,将约定的商品交付给你。 现在,时间到了。仓库管理员收到了发货指令,开始拣货、打包、装车。当货物离开仓库…
在上一篇文章中,我们成功地将货物发出,库存资产减少了,销售成本也结转了。从业务角度看,订单已经基本完成;但从财务角度看,还有最关键的一步:收回货款。 在O2C流程中,企业"赚钱"的完整路径是: 找到客户,签订订单(销售机会 → 销售订单)…
在前面的 O2C 文章里,客户一直都在场。 第 8 篇里,销售要先识别客户需求,才能把商机转成销售订单。第 9 篇里,系统要检查这个客户的信用额度,决定订单能不能放行。第 11 篇里,财务还要把客户的付款和发票做核销,确认这笔钱到底有没有收…
在第 12 篇中,我们聊完了 CRM 的三层模型。客户已经被分层、被识别、被管理,接下来一个很自然的问题就是:面对不同客户,同一个商品到底该卖多少钱 如果你说"统一定价,一视同仁",财务可能会摇头:大客户一年采购上千万,和小客户买一两件,怎…
在第 11 篇文章中,我们讲完了开票与收款核销的完整流程:货物发出,发票开具,应收账款确认,客户付款,收款核销。在第 13 篇文章中,我们讨论了价格策略如何影响订单金额和利润空间。 但这里有一个更根本的问题被忽略了:发票开出去了,钱真的能收…
从本篇开始,我们进入库存模块。 回顾前面的 14 篇文章,P2P 流程讲完了企业怎么花钱买东西,从采购申请到订单下达,从收货入库到付款结算。O2C 流程讲完了企业怎么卖货赚钱,从销售机会到订单确认,从发货出库到回款核销。 但不管是买来的、卖…
上一篇文章我们聊了入库,四种场景下的库存增加。有进就有出,今天我们来聊出库。 入库讲究的是"验"——验数量、验质量、验单据。出库讲究的则是"时机"——什么时候扣库存,什么时候确认成本,什么时候放行货物。扣早了,可能导致超卖,客户下单后仓库却…
在第 15 篇中,我们聊过入库——采购收货、生产完工、销售退货,都会让库存增加。在第 16 篇中,我们又看了出库——销售发货、生产领料、采购退货,都会让库存减少。 进进出出之后,系统里的数字每天跟着变。一年下来,系统显示我们还有 10,00…
在上一篇文章中,我们理解了盘点的价值。但盘点只能回答"账实是否一致",它解决不了另一个更现实的问题:当 A 仓库积压、B 仓库缺货时,企业该怎么办? 假设你管理着一家在全国有多个仓库的电商企业。双十一前夕,销售数据显示北京仓的某款热门商品即…
在上一篇文章中,我们聊完了库存的四大基础操作:入库、出库、盘点、调拨。这四件事解决了"货怎么进来、怎么出去、怎么核对、怎么搬运"的问题。 但有一个问题,这四篇文章都没有正面回答: 仓库的货架上明明放着 1000 件商品,销售打开系统,看到的…
在第19篇文章中,我们厘清了可用库存的计算逻辑:账面上的数字不等于真正能卖的数量,还要扣除锁仓、在途、预留等各种占用。知道了"还剩多少能卖"之后,下一个更本质的问题随之而来:应该备多少货才够? 这是一个采购经理每天都要面对的难题。某款热销…
在前两篇文章中,我们讨论了如何知道仓库里有多少货可用,以及如何科学地设置安全库存。这两个问题本质上都围绕"数量"展开:知道有多少、该备多少。 但数量只是库存管理的一半。对于财务和经营分析来说,还有一个同等重要的问题:这批货值多少钱? 同一个…
从第 8 篇到第 14 篇,我们走完了 O2C 的完整业务流程:从销售机会到订单确认,从发货出库到成本结转,再到开票收款与应收账款管理。从第 15 篇到第 21 篇,我们又深入了库存模块,理解了入库、出库、盘点、调拨和成本计价。 现在,让我…
在上一篇文章中,我们探讨了应收对账——如何确保客户欠我们的每一分钱都清晰可查、按时收回。 今天,我们把镜头转向企业的另一面:应付。 如果说应收对账是"盯紧别人欠我们的钱",那么应付对账就是"管住我们该付出去的钱"。一个是把钱要回来,一个是把…
在前两篇文章中,我们分别聊了应收对账和应付对账:与客户核对该收的钱是否到账,与供应商核对该付的钱是否准确。 但这里有一个容易被忽略的环节。与客户和供应商对完账后,企业的财务工作并没有结束。还有一笔最重要的账要对——与银行对账。 原因很简单。…
前面三篇文章,我们分别聊了应收对账、应付对账和银行对账。 这三类对账有一个共同点:对账的双方,至少有一方是外部机构——客户、供应商或银行。外部对账虽然有难度,但边界清晰、规则明确,对不上就是哪边出了问题,总能找到责任方。 但企业里还有一类对…
前面的 25 篇文章,我们一起走完了企业最核心的三条业务主线。 花钱的线:从采购申请到采购订单,从收货入库到发票校验,最后付款给供应商。赚钱的线:从销售机会到报价,从销售订单到发货开票,最后把应收账款收回来。管货的线:从入库出库到盘点调拨,…
在上一篇关于模块划分的讨论中,我们把 ERP 系统拆解成了采购、销售、库存、财务等功能模块。模块边界清晰了,但模块内部还面临一个更基础的问题:一张单据从诞生到终结,中间会经历多少种"身份"?谁来控制它什么时候能变成下一个身份? 回顾本系列的…
上一篇我们聊了状态机。状态机解决的是业务怎么流转的问题:一张采购申请从"草稿"到"待审批"再到"已审批",每一步都需要明确的事件触发,状态之间不能乱跳。 但状态机只管"规则",不管"人"。 想象这样一个场景:一个刚入职的实习生,在系统里看到…
在第 28 篇文章中,我们聊了 RBAC 权限体系。权限设计解决的是"谁能看、谁能改、谁能批"的问题——它给每个角色划定了操作边界,确保库管不能改订单、销售不能审付款。 但权限只回答了一半问题。剩下的一半是:即便一个人有操作的权限,他的每一…
从本篇开始,我们进入架构思维篇。 前面 29 篇文章,我们用业务视角理解了采购、销售、库存、财务、对账的完整流转,也用产品视角拆解了模块划分、状态机、权限和审批流的设计思路。现在,我们换一个视角:如果你是一位架构师,面对这套覆盖了企业核心命…
在第 30 篇中,我们用 DDD 的战略设计把业务领域拆成了一个个限界上下文。采购上下文、销售上下文、库存上下文……边界清晰,职责分明。 但划好了边界,只是解决了"哪里放什么"的问题。 如果你真正坐下来写代码,很快会遇到一个更具体的问题:一…
上一篇文章我们聊了 DDD 战术设计中的聚合根、实体与值对象。其中一个核心结论还记得吗:聚合内部的数据修改,通过领域事件来驱动状态流转。订单状态从"待审核"变成"已确认",本质上就是一次领域事件的发布与消费。 但这里有一个自然而然的追问:聚…
上一篇文章我们聊了事件驱动架构。它的核心思路很简单:模块之间不再直接调用,而是通过事件来通信。订单创建了,发个事件;库存扣了,发个事件;财务记账了,也发个事件。各模块各干各的,互不阻塞。 这个思路在解耦上很有效。但有一类问题,事件驱动本身解…
写完这 34 篇文章,我最大的感受是:即使已经长期从事服务端研发和架构设计,进入业财系统之后,技术判断依然必须接受业务事实、财务约束和经营逻辑的重新校准。 在很多纯技术语境里,"采购申请要关联预算科目"很容易被简化成一次字段关联;但在业财语…