后端企业应用【免费下载链接】erpnextFree and Open Source Enterprise Resource Planning (ERP)项目地址https://gitcode.com/GitHub_Trending/er/erpnext点击查看免费下载导读本文基于当前仓库中的官方版本说明 erpnext/change_log/v13/v13_0_2.md逐条拆解 ERPNext 13.0.2 补丁版本包含的四项核心修复DocType 方法的frappe.whitelist授权、销售退货Credit Note的入库价incoming rate计算错误、意大利 e-invoicing电子发票的校验与税额计算以及调度器检查时间的更新。通过结合仓库内的源码实现与测试用例你将理解每项修复背后的业务逻辑、触发场景与底层调用链从而能在自己的 ERPNext 实例中准确判断升级影响、排查相关问题。一、v13.0.2 版本概览一次聚焦正确性的补丁发布v13_0_2.md全文虽然精炼却精确列出了该补丁版本的完整修复清单全部为 bugfix修复性质不涉及新增功能或破坏性变更fix: frappe.whitelist for doc methodsPR #25231fix: incorrect incoming rate for the sales returnPR #25306fix(e-invoicing): validations tax calculation fixesPR #25314fix: update scheduler check timePR #25295从修复类型可以推断13.0.2 的目标是提升凭证处理特别是退货场景、区域化合规意大利电子发票和系统后台调度三个方向的正确性。仓库中完整的版本演进记录集中在 erpnext/change_log 目录其中 v13 的历史版本说明位于 erpnext/change_log/v13可作为对比相邻补丁变更范围的参考。二、修复一为 DocType 方法正确启用 frappe.whitelistPR #252312.1 修复背景在 Frappe 框架中服务端方法默认不允许被客户端浏览器或移动端直接调用。只有通过frappe.whitelist()装饰器标记的方法才能通过frappe.call从前端安全调用同时仍会执行框架内置的权限检查。当 ControllerDocType 控制器中的自定义方法缺少正确标记或装饰器与框架对 doc methods 的识别逻辑存在偏差时前端调用会抛出 Method not found 或权限类错误。2.2 仓库内的实际用法在当前仓库中frappe.whitelist()遍布各类 DocType 控制器。例如 账户余额时间线数据源 在数据源类上直接标注frappe.whitelist()账户 Doctype 控制器 内多个方法第 459、470、503、555、620、659 行附近均通过frappe.whitelist()暴露给报表和前端工具调用科目表导入 中也有多处同类用法。此外批量付款工具 的入口方法同样使用了frappe.whitelist()。这一修复的意义在于确保这些作为文档方法doc method即隶属于 Doctype 控制器的实例方法暴露的接口在经过frappe.get_doc(...)获取文档实例后依然能被白名单机制正确识别从而避免因装饰器判定逻辑差异导致的调用失败。三、修复二销售退货入库价incoming rate计算修正PR #253063.1 问题现象当用户基于销售发票Sales Invoice或交货单Delivery Note创建销售退货Credit Note时系统需要确定退回物品的入库价用于生成库存估价分录stock value difference。在 13.0.2 之前的某些路径下退货行使用了错误的 incoming rate导致库存价值stock balance与总账GL Entry之间出现偏差。3.2 底层实现get_rate_for_return 的取价链路退货取价的核心逻辑位于 erpnext/controllers/sales_and_purchase_return.py 中的get_rate_for_return()函数约第 766 行起。其取价优先级可以概括为采购侧直接读取库存分录的 incoming_rate 字段当凭证类型为 Purchase Receipt、Purchase Invoice 或 Subcontracting Receipt 时直接查询 Stock Ledger Entry 上的incoming_rate列销售侧按库存分录计算对 Sales Invoice / Delivery Note则从 Stock Ledger Entry 计算ABS(stock_value_difference / actual_qty)即实际入库均价回退到凭证行的 incoming_rate若上述取不到值且存在return_against则读取销售明细行上缓存的incoming_rate字段调用 _get_incoming_rate 兜底仍未取到时调用 erpnext/stock/utils.py 中的_get_incoming_rate()封装入口为get_incoming_rate()约第 292–308 行按批次、序列号或 FIFO/Moving Average 估值方法重新计算入库价最终兜底为销售价当物品允许零估值allow_zero_valuation_rate未开启时直接使用明细行的rate作为退货入库价保证退货分录不会因估价缺失而中断。此外该函数还处理了一个边界场景当启用set_zero_rate_for_expired_batch且退货涉及已过期批次时会将退货行的incoming_rate显式置为 0 后返回避免过期批次以错误价格入库。3.3 相关佐证调整入库价与测试采购发票侧的adjust_incoming_rate开关在 billing_status.py第 77 行与 gl_composer.py第 174、375 行附近中被读取用于在退货/成本调整时修正入库价说明 incoming rate 的准确性直接影响 GL 分录组成仓库测试 test_purchase_invoice.py 包含多组针对入库价调整与多币种、部分结算场景的断言如第 2161、2269、2318、3390、3446 行附近的用例验证默认计算与调整后的入库价数值销售发票侧测试 test_sales_invoice.py第 2022–2028 行附近也断言了退货/出货场景下incoming_rate与stock_value_difference的一致性。因此13.0.2 的该修复本质上是修正了销售退货场景下入库价取值路径的优先级与兜底逻辑确保 Credit Note 的库存估价与成本核算更贴近实际入库成本。四、修复三意大利 e-invoicing 校验与税额计算PR #253144.1 修复范围fix(e-invoicing)针对的是 ERPNext 的意大利地区化电子发票模块。意大利自 2019 年起强制企业通过 Sistema di Interscambio (SDI) 提交电子发票fattura elettronica因此 ERPNext 在提交销售发票时需同步生成符合 FatturaPA 规范的 XML 附件。13.0.2 的该修复集中于两处提交前的数据完整性校验validations与税额汇总计算tax calculation。4.2 提交前校验sales_invoice_validate实现位于 erpnext/regional/italy/utils.py 的sales_invoice_validate()约第 221 行起该函数作为 Sales Invoice 的 validate 钩子执行校验项包括公司侧必须设置公司地址company_address且地址含 pincode、city、country_code公司必须设置税制fiscal_regime、税号tax_id与财政代码fiscal_code客户侧个人客户必须设置 fiscal_code公共行政机构is_public_administration需设置 fiscal_code其余企业客户需设置 tax_id必须存在客户地址税务侧Taxes and Charges 表至少一行若税率为 0 且税额为 0则必须填写免税理由tax_exemption_reason付款侧付款计划payment_schedule中的付款方式缺失时自动回填对应mode_of_payment_code。同时在提交钩子sales_invoice_on_submit()约第 305 行起中若公司所在国家为意大利含 Italia、Italian Republic、Repubblica Italiana 等写法会强制校验付款方式及其代码随后调用prepare_and_attach_invoice()生成 XML 附件取消发票时由sales_invoice_on_cancel()清理对应附件。4.3 税额计算修正update_itemised_tax_data()第 14 行起按物品明细重算税额row.tax_rate flt(tax_rate, row.precision(tax_rate)) row.tax_amount flt((row.net_amount * tax_rate) / 100, row.precision(net_amount)) row.total_amount flt((row.net_amount row.tax_amount), row.precision(total_amount))即tax_amount net_amount × tax_rate / 100total_amount net_amount tax_amount并依据字段精度做浮点规整——这正是税计算修正的核心避免因舍入或重复累计导致 XML 中的应税基数与税额不一致。汇总侧get_invoice_summary()第 144 行起将税额按税率归组key 为税率字符串支持仅计入 VAT 类税款charge_type Actual的印花税等被排除但 2 欧元的 Bollo 印花税会在prepare_invoice()中被单独识别为stamp_duty将On Previous Row Total/On Previous Row Amount类型的附加费以 charges 形式追加为 e-invoice 行项目append_row_as_charges()税率为 0 时记录免税理由tax_exemption_reason与法律依据tax_exemption_law。最终 XML 由模板 erpnext/regional/italy/e-invoice.xml 渲染生成发票命名遵循IT{税号}_.#####的渐进编号规则get_progressive_name_and_number()。五、修复四调度器检查时间更新PR #252955.1 修复意图ERPNext/Frappe 依赖后台调度器scheduler周期执行定时任务如自动报表、规则评估、重过账等。系统需要记录最近一次调度器检查时间以判断调度器是否健康运行若该时间戳未被正确更新系统可能误判调度器停止从而在界面上给出误导性的调度器未运行警告或在事务性数据库中造成不必要的重复调度。5.2 仓库中的调度器相关实现在 银行对账单导入 中通过frappe.utils.scheduler.is_scheduler_inactive()第 87–90 行检测调度器是否停用来决定是否必须立即执行导入run_now——这体现了检查时间/运行状态对用户操作路径的实际影响银行交易规则 中的scheduler_run_rule_evaluation()第 225 行则是典型的调度器驱动任务说明调度器的准时性直接关系到银行交易自动匹配等后台功能财政年度控制器第 111 行附近的注释还提示了调度事务在 PostgreSQL 上的原子性考量佐证了调度器时间戳维护需要谨慎处理事务边界。13.0.2 对该问题的修复即确保调度器每次健康检查后都及时刷新检查时间戳让调度器状态判断与界面提示保持准确。六、升级与验证建议确认当前版本本仓库为 v13 分支快照完整变更记录见 erpnext/change_log/v13生产环境升级前请对照自身版本与 v13_0_2 之间的差异。回归重点创建基于销售发票/交货单的退货单Credit Note核对退货行的 incoming rate 与库存价值差异可参照 test_purchase_invoice.py 与 test_sales_invoice.py 中的断言思路若使用意大利本地化提交销售发票时确认公司/客户税号、财政代码、地址与免税理由等必填项校验并检查生成的 XML 附件中税额汇总是否与发票一致观察系统调度器未运行提示是否因时间戳更新逻辑而消失。回滚考量四项均为修复型变更不引入新的必填字段或数据迁移如遇异常可结合 erpnext/change_log 中相邻版本说明判断是否存在已知的后续回归修复。小结ERPNext 13.0.2 是一份小而精的补丁版本四项修复分别落在 API 授权边界frappe.whitelist、库存估价正确性销售退货 incoming rate、区域合规意大利电子发票校验与税额与系统健康监测调度器检查时间四个维度。通过 销售退货取价实现、意大利 e-invoicing 工具 等源码可以清晰还原每个修复的业务上下文也为后续排查同类型问题提供了直接的代码级参考。赞分享后端企业应用【免费下载链接】erpnextFree and Open Source Enterprise Resource Planning (ERP)项目地址https://gitcode.com/GitHub_Trending/er/erpnext点击查看免费下载相关推荐flutter_lints 使用指南为 Flutter 项目启用官方推荐静态分析规则集flutter_lints 使用指南为 Flutter 项目启用官方推荐静态分析规则集 导读 flutter_lints 是 Flutter 团队维护的官方后端企业应用ERPNext v5.0.11 版本更新解读销售订单字段改名、POS Profile 化与购货发票简化ERPNext v5.0.11 版本更新解读销售订单字段改名、POS Profile 化与购货发票简化 本篇文章基于 erpnext/change_log/v后端企业应用Vitess v13.0.2 版本深度解读Go 1.17.12 安全升级与查询服务关键修复Vitess v13.0.2 版本深度解读Go 1.17.12 安全升级与查询服务关键修复 导读 Vitess v13.0.2 是 13.0 稳定分支上的第二数据库分布式数据库云原生后端数据存储上一篇终极zsh语法高亮指南提升Shell脚本代码风格的10个最佳实践下一篇告别手写JSONJsonCpp反射式序列化实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考