后端企业应用【免费下载链接】erpnextFree and Open Source Enterprise Resource Planning (ERP)项目地址https://gitcode.com/GitHub_Trending/er/erpnext点击查看免费下载v12.1.0 是 ERPNext 在库存Stock与会计Accounting两个核心领域的关键版本它首次引入了面向仓库拣货场景的Pick List拣货单单据同时对Accounts Receivable应收账款报表进行了彻底重构使其底层改为基于 Payment Ledger Entries 计算。本文以 v12.1.0 发布说明 为骨架结合当前仓库中的源码、DocType 定义与测试逐项拆解这两大功能的字段设计、工作流与底层实现帮助你理解如何在仓库拣货、制造领料和账龄分析中落地使用。Pick List 拣货单从需求单据到库存拣选的桥梁为什么需要 Pick List在 v12.1.0 之前仓库人员要完成“按销售订单拣货”“按工单领料”等操作只能依赖人工对照单据再手工登记出入库缺少一个专门的中间环节来记录“拣了多少、从哪个仓库拣、拣的是哪些批次/序列号”。Pick List 正是为了解决这一痛点而新增的独立可提交is_submittable单据它位于 erpnext/stock/doctype/pick_list/ 下核心实现集中在 pick_list.py、pick_list.json 与 pick_list.js。从源码结构看Pick List 是一个典型的三段式工作流单据引用来源从销售订单Sales Order、物料申请Material Request或工单Work Order拉取待拣货明细确定位置通过“Get Item Locations”按钮或自动分配算法把需求数量拆分到具体仓库、批次与序列号生成后续单据提交后一键创建 Delivery Note销售交货或 Stock Entry库存转移。核心字段与三种 Purpose在 pick_list.json 中purpose字段定义了三种业务场景它决定了 Pick List 能关联哪些上游单据、以及最终生成什么下游单据Purpose上游引用下游单据典型场景Material Transfer for ManufactureWork OrderStock EntryMaterial Transfer for Manufacture工单领料按成品数量倒算原料需求Material TransferMaterial RequestStock EntryMaterial Transfer仓库间/仓库到需求的原料转移DeliverySales OrderDelivery Note / Sales Invoice面向客户的销售拣货与发货其他关键字段均可在 pick_list.json 中核对company必填拣货所属公司所有仓库行必须与公司一致见下文校验naming_series默认STO-PICK-.YYYY.-即按“STO-PICK-年份-序号”自动编号customer仅当purpose Delivery时显示用于筛选该客户的未交付销售订单work_order仅Material Transfer for Manufacture场景使用for_qty成品数量由工单剩余需求自动带出material_request仅Material Transfer场景使用并在前端按material_request_type purpose过滤parent_warehouse指定后系统只建议该仓库及其子仓库中的库存位置对应仓库的is_group层级结构consider_rejected_warehouses勾选后允许把“拒收仓库”中的物料也纳入拣货分配pick_manually勾选后系统不自动覆盖已录入的仓库/批次/序列号交给用户手工指定ignore_pricing_rule由 Pick List 生成的 Delivery Note 不再应用定价规则scan_modescan_barcodeprompt_qty条码枪扫描拣货模式scan_mode下提交时要求picked_qty必须达到stock_qty否则报 “Pick List Incomplete”group_same_items打印时把同一物料、同一仓库的多个行合并展示对应 before_print 中的group_similar_items。三种上游单据的映射入口Pick List 的表头字段变化会触发前端映射逻辑见 pick_list.js具体入口分别为销售订单 → 拣货单erpnext/selling/doctype/sales_order/mapper.py 中的create_pick_list前端通过“Get Items”按钮按客户与公司过滤per_delivered 100的未交付订单工单 → 拣货单erpnext/manufacturing/doctype/work_order/mapper.py 中的create_pick_list选择工单后弹出“Qty of Finished Goods Item”确认框按成品数量展开 BOM 原料需求物料申请 → 拣货单erpnext/stock/doctype/material_request/mapper.py 中的create_pick_list。映射完成后明细行落入子表locations类型为 Pick List Item每个子行记录 item_code、qty、stock_qty、warehouse、batch_no、serial_no、sales_order_item / material_request_item 等引用以及 picked_qty、delivered_qty、transferred_qty 等进度字段。自动分配库存位置set_item_locations 的核心逻辑Pick List 最核心的能力是“自动决定从哪里拣”该逻辑集中在 set_item_locations前端“Get Item Locations”按钮与保存前before_save都会触发除非勾选了pick_manually。整体流程为聚合数量aggregate_item_qty把相同物料、相同 UOM/仓库/批次/引用来源的行合并并跳过已设置picked_qty的行同时过滤非库存物料is_stock_item 0且非产品包确定候选仓库范围有parent_warehouse时取该仓库及其全部子仓库有work_order时优先取工单物料上配置的source_warehouse及其子仓库对应 Work Order Item.source_warehouse否则取公司根仓库查询可用库存get_available_item_locations结合 Bin 表实际库存、已存在的其他 Pick List 占用量与预留reservation计算“可拣数量”并考虑consider_rejected_warehouses生成位置行按可用位置把需求数量拆成多行写入locations若某行picked_qty已超过可分配量则截断为可分配量空表兜底如果更新后locations为空且单据已提交会把原行保留但stock_qty/picked_qty置 0并弹出 “Out of Stock” 红色提示要求补货后通过“Update Current Stock”按钮重算。值得注意的是代码中对 PostgreSQL 数据库使用了按物料加事务级咨询锁transaction_advisory_lock((pick-allocate, item_code))避免并发分配同一物料时重复占用库存这是多仓并发拣货场景下的关键细节。提交与校验链库存足够性、批次与序列号Pick List 是可提交单据提交前后执行多层校验与状态回写见 pick_list.pyvalidateL110-L115校验过期批次expiry_date 今天的批次直接拒绝、数量有效性、picked_qty不得超过对应 Batch 余量或 Bin 的actual_qty、序列号必须存在于指定仓库、以及与上游销售订单的 company 一致性validate_warehouses逐行要求 Warehouse 必填且仓库所属公司必须与单据公司一致否则抛出IncorrectWarehouseValidationErrorbefore_submit校验Sales Order是否已有库存预留有预留则禁止重复建拣货单、工单场景下各行的拣选量不得超过对应 Material Request 的待处理量、扫描模式下不得低于需求数量非扫描模式下若用户未填picked_qty提交时自动补齐为stock_qtyon_submit为序列号/批次行生成 Serial and Batch Bundle回写上游引用单据——更新 Sales Order Item 的picked_qty、调用update_sales_order_picking_status更新销售订单的per_picked、通过 RequiredItemsService.update_picked_qty_for_required_items 回写工单已领数量状态机status字段取值Draft / Open / Partly Delivered / Partially Transferred / Completed / Cancelledpick_list.json其中 “Partly Delivered / Partially Transferred” 由per_delivered与transferred_qty驱动delivery_status另有Not Delivered / Fully Delivered / Partly Delivered三态。Pick List 还会通过 status_updater 自动把拣货量回写到Material Request Item.picked_qty形成“物料申请—拣货—转移”的闭环追溯。从拣货单生成下游单据提交后用户可以在表单上通过“Create”按钮生成后续单据映射实现位于 erpnext/stock/doctype/pick_list/mapper.pyDelivery 场景 → Delivery Note / Sales Invoicecreate_delivery按“客户 收货地址”分组一个客户生成一张交货单无销售订单引用的行单独归入一张单据。子表行把picked_qty - delivered_qty换算为目标单据数量并回填against_pick_list、pick_list_item、批次与序列号L223-L254。产品包Product Bundle场景下目标单据会自动补上父级捆绑物料行Material Transfer / 制造领料场景 → Stock Entrycreate_stock_entry根据purpose分别走工单、Job Card、物料申请或无引用四条分支把s_warehouse来源仓库、t_warehouse目标仓库、transfer_qty等属性带进 Stock Entry其中transfer_qty只取尚未转移的差额picked_qty - transferred_qty见 get_pending_transfer_stock_qty多拣货单合并交货create_dn_for_pick_lists支持从多个 Pick List 汇总为一张面向指定客户的 Delivery Note。这一系列映射均可通过frappe.model.mapper的map_child_doc复用销售订单的既有映射逻辑保证与现有交货/开票流程完全兼容。测试覆盖仓库为 Pick List 提供了完整的自动化测试见 test_pick_list.py覆盖了从销售订单创建拣货单、自动位置分配、批次/序列号拣选、提交后生成 Delivery Note 与 Stock Entry、取消拣货单回写等关键路径可作为理解该功能预期行为的“可运行文档”。重构后的 Accounts Receivable 报表基于 Payment Ledger Entriesv12.1.0 的另一项重要变更是对应收/应付报表的重构。旧的应收报表直接聚合 GL Entry新实现改为以Payment Ledger Entry为数据源并让应收Receivable与应付Payable共用同一套报表引擎。统一报表引擎 ReceivablePayableReport重构后的核心是 erpnext/accounts/report/accounts_receivable/accounts_receivable.py 中的ReceivablePayableReport类应收报表通过execute传入{account_type: Receivable}实例化它L42-L47应付报表 accounts_payable.py 则以account_type Payable复用同一实现。文件头部的注释L26-L39概括了重构后的报表语义发票既可以来自 Sales/Purchase Invoice也可以来自 Journal Entry一行报表的核心余额字段为Invoiced Amount发票金额、Paid Amount已付金额、Credit/Debit Note Amount贷/借项通知金额、Outstanding Amount未结金额带明确付款条款如 30% 预付、30% 到货付、40% 尾款的发票会按付款条款拆成多行报表日期之后的远期post-dated付款会显示在额外的“未来金额”列中账龄分组0-30、30-60 天等通过过滤器可配置超付金额会以额外行呈现销售人员、交货单等信息会以逗号分隔拼接到明细列金额默认以公司币种展示勾选in_party_currency后以对方币种展示。可配置过滤器与账龄计算在 ReceivablePayableReport.init中可以看到关键过滤器的默认行为report_date默认当天nowdate()用于界定“截至某日”的未结余额age_as_on账龄计算基准日默认“Today”也可显式指定报表日期range账龄分段默认30, 60, 90, 120系统按逗号拆分生成 “0-30 / 30-60 / 60-90 / 90-120 / 120 以上” 的分段列group_by_party按往来方分组并输出汇总行in_party_currency是否使用对方币种显示金额数据拉取方式receivable_payable_fetch_method读取 Accounts Settings 配置默认Buffered Cursor用于大表查询时的游标优化。报表还支持按销售人员Sales Person与销售伙伴Sales Partner过滤对应get_sales_invoices_or_customers_based_on_sales_person与get_invoices_based_on_sales_partner并可接入会计维度Accounting Dimensions做多维度拆分。汇总报表与测试与明细报表配套的还有按往来方汇总的 accounts_receivable_summary 及其应付侧对应物二者共用同一数据源逻辑。重构行为的正确性由 test_accounts_receivable.py 与 test_accounts_receivable_summary.py 等测试保障覆盖付款条款拆分、远期付款、账龄分段等场景是验证报表口径的最佳参考。小结v12.1.0 的两项核心改动为后续版本奠定了重要基础Pick List 从无到有地建立了“需求单据 → 拣货位置 → 交货/领料”的完整拣货链路其自动分配、批次序列号处理与多映射入口的设计在后续版本中持续演进例如后来的库存预留 Stock Reservation 功能即通过 create_stock_reservation_entries 挂接到 Pick List 之上应收/应付报表则完成了一次底层数据源的统一重构让账龄分析的口径更贴近支付流水为财务对账与多币种、多公司场景提供了更稳健的报表基础。若要深入实践可直接阅读上述源码文件及其测试或在本仓库环境中按“Sales Order → Pick List → Delivery Note”与“Work Order → Pick List → Stock Entry”两条路径实测完整流程。赞分享后端企业应用【免费下载链接】erpnextFree and Open Source Enterprise Resource Planning (ERP)项目地址https://gitcode.com/GitHub_Trending/er/erpnext点击查看免费下载相关推荐ERPNext 会计模块指南从复式记账到 Payment Ledger 的余额管理架构ERPNext 会计模块指南从复式记账到 Payment Ledger 的余额管理架构 本指南围绕 ERPNext 开源 ERP 的 accounts 会计后端企业应用flutter_lints 使用指南为 Flutter 项目启用官方推荐静态分析规则集flutter_lints 使用指南为 Flutter 项目启用官方推荐静态分析规则集 导读 flutter_lints 是 Flutter 团队维护的官方后端企业应用ERPNext v6.16.3 版本解析交付/收货单据账单状态追踪、库存入库附加成本重算与新加坡科目表ERPNext v6.16.3 版本解析交付/收货单据账单状态追踪、库存入库附加成本重算与新加坡科目表 导读 本文深入解析 ERPNext v6.16.3 版后端企业应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考