采购订单写了10台笔记本到货后实际收了9台另1台下周补发发票又可能晚到。若采购、验收、资产卡和财务凭证各自独立录入系统很容易出现“已经折旧却没验收”或“实物在用但台账没有”的断层。以一张采购订单为例申请10台验收9台暂估金额90,000元。系统要允许分次收货但不允许把“申请数量”直接变成“可折旧资产数量”。本文以 Spring Boot MySQL 8.x 的小型管理系统为教学边界。表名、字段和数值均为示例上线前仍应依据资产制度、财务口径、数据量和现有程序进行评审。实现时建议把一次业务动作拆成四层Controller只接收请求和返回结果Service加载当前状态、执行权限与业务校验Repository使用参数化SQL读写数据库用主键、唯一键、非空和金额精度守住最后边界。前端校验可以减少误操作但不能替代服务端规则。本文的SQL用于展示约束和核对思路不是可直接在生产库执行的完整脚本。执行DDL前应确认MySQL版本、存储引擎、表规模、磁盘余量、主从延迟和锁等待执行查询前应补充公司、期间等范围并查看执行计划。代码示例省略了DTO、Mapper和统一异常处理但不会省略幂等、权限、事务和审计这些决定数据是否可信的部分。如果系统已经存在历史数据任何“新增唯一键”“改变状态含义”或“补齐关联ID”的操作都要先做数据剖析。先统计空值、重复值和非法状态再选择清洗、映射或人工确认不能因为新程序要求字段非空就用0或空字符串批量填满旧记录。正式改造前还应保存三份基线当前表结构的SHOW CREATE TABLE结果、目标范围的数量与金额汇总、能够代表正常和异常路径的固定样本。发布后使用同一口径复查并记录程序版本、数据库迁移版本和执行批次。如果需要回退先判断新版本是否已经写入旧程序无法识别的数据代码回退并不等于业务数据自动回退。对于大表新增索引或约束还要先在相近数据量的环境评估执行时间与锁影响不能只根据空测试库的耗时安排生产窗口。文中的状态名和错误码用于说明设计方法。真正落地时应集中定义状态枚举、合法迁移和错误码说明并为关键状态变化编写自动化测试避免不同接口各自解释同一个状态。批量接口还应限制单批数量、记录处理进度并提供明确的重复提交策略统计和导出任务不能绕开同样的数据权限与状态规则。监控指标至少区分请求失败、业务拒绝和异步待处理避免把合理拦截误报成系统故障。对于可重试任务应记录下一次执行时间、重试次数和最后错误超过上限转人工处理不能无限循环也不能把待处理悄悄显示成完成。所有后台修复动作同样要经过授权、幂等和审计并保留修复前后的核对证据方便后续回归测试和责任追溯。接口返回、数据库记录和审计事件中的业务编号应保持一致便于跨层定位、复核和比较结果。目录一、先区分申请、订单、到货和可资本化二、验收通过才产生候选资产卡三、一物一码与批次关系一起保存四、价值确认不能覆盖验收事实五、状态推进要由合法动作触发六、采购数量和资产数量必须可对账七、上线前用分批到货做验收八、服务层实现不能只相信页面参数九、事务、并发和外部调用的边界十、失败结果要能指导下一步处理十一、上线前用SQL核对业务结果十二、可直接使用的技术验收表一、先区分申请、订单、到货和可资本化采购到入账不是一张单据不断修改状态而是四类业务事实逐步衔接。申请单回答“为什么买、谁使用、预算从哪里来”采购订单回答“向谁买、买多少、约定多少钱”验收单回答“这一次实际到了什么、合格多少”资产卡和资本化记录才回答“哪些实物进入长期管理、按什么价值入账”。建议至少拆成purchase_request、purchase_order_line、asset_receipt_line、asset_card和asset_capitalization五类数据。核心关系不是简单的一对一而是一条申请明细可以形成一条或多条订单行一条订单行可以分多次到货一条验收明细又可以拆成多张单件资产卡。对象保存的事实数量口径后续是否允许覆盖采购申请需求、预算、预计使用部门申请数量审批完成后保留版本采购订单行供应商、型号、成交价订购数量变更应留订单版本验收明细到货批次、合格与拒收结论实收/合格/拒收数量已确认验收不得直接改写资产卡资产编码、序列号、使用状态单件或受控批次通过业务动作变更资本化记录入账日期、原值、凭证号财务确认数量与金额冲销或调整不覆盖原记录把这些对象拆开以后“订单10台、第一批到货6台、第二批到货4台且1台拒收、最终建卡9张”才能被准确表达。若只在订单上保存一个status和一个received_qty第二次到货很容易覆盖第一次验收的人员、附件和结论。图1采购到入账是四类事实的衔接。二、验收通过才产生候选资产卡验收接口不能只接收一个“通过”按钮。它至少要接收订单行、到货批次、实收数量、合格数量、拒收数量、供应商批次或序列号附件并在事务内完成三类校验本次合格数与拒收数之和必须等于实收数累计实收数不能超过订单数同一个验收请求不能重复确认。下面的服务层示例把这些规则放在后端。前端禁用按钮只能减少误操作不能阻止重复请求和并发提交。Transactional(rollbackForException.class)publicLongconfirmReceipt(ReceiptCommandcommand){PurchaseOrderLineorderLineorderLineRepository.lockById(command.purchaseLineId()).orElseThrow(()-newBizException(采购订单行不存在));if(command.acceptedQty()command.rejectedQty()!command.receivedQty()){thrownewBizException(合格数量与拒收数量之和必须等于实收数量);}intconfirmedQtyreceiptRepository.sumConfirmedQty(command.purchaseLineId());if(confirmedQtycommand.receivedQty()orderLine.getOrderQty()){thrownewBizException(累计实收数量不能超过采购数量);}returnreceiptRepository.findIdByRequestNo(command.requestNo()).orElseGet(()-{AssetReceiptLinereceiptAssetReceiptLine.confirmed(orderLine.getId(),command.requestNo(),command.receivedQty(),command.acceptedQty(),command.rejectedQty(),command.attachmentId());receiptRepository.insert(receipt);auditService.record(RECEIPT_CONFIRMED,receipt.getId());returnreceipt.getId();});}这里的lockById用于串行化同一订单行的收货确认requestNo用于幂等。生产系统还应在数据库上为请求号建立唯一约束即使两个请求同时通过了应用层查询也只能有一个成功写入。合格数量进入待建卡范围拒收数量进入退换货或补货流程不能把拒收数据删除后假装从未到货。图210台下单9台验收的正确关系。三、一物一码与批次关系一起保存验收通过后也不应立即把订单行复制成资产卡。系统需要先确定管理粒度电脑、车辆、仪器等会独立领用、维修和报废的实物通常一物一码同质且不需要逐件追踪的低值物品可以按受控批次管理。无论选择哪种粒度资产卡都必须保留来源验收行而不是只保存供应商和采购日期。单件建卡时可以用receipt_line_id item_sequence作为来源唯一键。例如验收行1001合格9台生成序号1至9的九张候选卡。网络超时后再次点击“生成资产卡”数据库唯一约束会阻止第十张重复卡出现。CREATETABLEasset_card_demo(idBIGINTPRIMARYKEYAUTO_INCREMENT,asset_codeVARCHAR(64)NOTNULL,receipt_line_idBIGINTNOTNULL,item_sequenceINTNOTNULL,serial_numberVARCHAR(128),card_statusVARCHAR(24)NOTNULLDEFAULTPENDING,UNIQUEKEYuk_asset_code(asset_code),UNIQUEKEYuk_receipt_item(receipt_line_id,item_sequence));资产编码和二维码应在资产卡写入成功后生成或绑定。先打印9张标签、后建卡失败会留下无法追踪的“孤儿标签”先建卡并记录PENDING_LABEL打印成功后再变为ACTIVE则可以重试打印而不重复生成资产。若供应商提供设备序列号还可以对serial_number做组织范围内的重复检查但不要用可能为空或会改变的序列号代替内部资产主键。图3验收批次怎样拆成单件资产卡。四、价值确认不能覆盖验收事实暂估、发票确认、税额拆分和资本化属于财务阶段它们引用已经确认的资产卡而不是反向修改验收单。发票晚到时实物可以先处于待入账状态财务确认后新增资本化记录写入确认数量、原值、税额、入账日期和凭证号。若发票金额与暂估金额不同应生成差异调整记录并保留暂估版本。直接把资产卡的原值从90,000改成92,000虽然页面最终数字正确却无法回答差异由哪张发票、谁在何时确认。数量事实与价值事实分开保存也能避免“财务调整金额时把验收日期一并改掉”。图4数量对账要看整条链。CREATETABLEasset_receipt_line_demo(idBIGINTPRIMARYKEYAUTO_INCREMENT,purchase_line_idBIGINTNOTNULL,request_noVARCHAR(64)NOTNULL,received_qtyINTNOTNULL,accepted_qtyINTNOTNULL,rejected_qtyINTNOTNULL,receipt_statusVARCHAR(24)NOTNULL,attachment_idBIGINT,UNIQUEKEYuk_receipt_request(request_no),CHECK(received_qty0),CHECK(accepted_qty0ANDrejected_qty0),CHECK(accepted_qtyrejected_qtyreceived_qty));SELECTp.id,p.order_qty,COALESCE(SUM(r.received_qty),0)ASreceived_qty,COALESCE(SUM(r.accepted_qty),0)ASaccepted_qty,COALESCE(SUM(r.rejected_qty),0)ASrejected_qtyFROMpurchase_line pLEFTJOINasset_receipt_line_demo rONr.purchase_line_idp.idANDr.receipt_statusCONFIRMEDGROUPBYp.id,p.order_qtyHAVINGreceived_qtyp.order_qty;五、状态推进要由合法动作触发建议将订单、验收、资产卡和资本化分别维护状态不建立一个横跨全流程的万能状态。订单可以是PARTIALLY_RECEIVED验收行是ACCEPTED已生成的卡片是PENDING_CAPITALIZATION四者同时存在并不矛盾。每个动作都要校验当前状态例如只有已确认验收行可以建卡只有待入账资产卡可以资本化已资本化资产只能通过冲销或调整处理。状态变化同时写入审计表保存业务单号、操作者、前后状态和请求ID禁止通过通用“更新状态”接口任意跳转。图5流程验收清单。六、采购数量和资产数量必须可对账对账至少计算四个数量订单数量、累计实收数量、累计验收合格数量和已建卡数量。本例订单10台、实收10台、合格9台、建卡9张、拒收1台是可解释的闭环订单10台、合格9台却建卡10张则必须阻断。金额也要单独核对资产卡待确认原值之和、资本化金额和发票确认金额可以暂时不同但差异必须落在明确状态中。把数量差异和金额差异混成一个“未完成”标志会让采购、资产管理员和财务互相看不懂问题到底在哪里。七、上线前用分批到货做验收至少准备五组可复现数据分两批到货、部分拒收、同一请求重复提交、两名验收员并发确认、发票晚于资产启用。每组测试都要同时核对页面结果、数据库数量、资产卡来源和审计记录。特别要验证失败后的边界附件上传成功但事务回滚时是否留下无主附件九张卡生成到第五张失败时是否整体回滚重复请求返回原结果还是再次建卡。只有正常路径和异常路径都能给出明确结果采购到入账才算真正形成闭环。八、服务层实现不能只相信页面参数接口收到的公司、部门、状态和金额只能视为请求数据不能直接当成已经校验的业务事实。服务层至少要重新加载当前记录、计算操作者范围、校验当前状态并将业务结果写成可识别的返回对象。下面代码只展示关键边界仓储方法、异常类型和审计方式需按项目实现。Transactional(rollbackForException.class)publicListLongcreateCardsFromReceipt(longreceiptId){ReceiptreceiptreceiptRepository.lockById(receiptId);requireStatus(receipt,ACCEPTED);intcreatedcardRepository.countByReceiptId(receiptId);intremainingreceipt.getAcceptedQty()-created;if(remaining0)returncardRepository.idsByReceiptId(receiptId);ListAssetCardcardscardFactory.create(receipt,remaining);cardRepository.batchInsert(cards);receiptRepository.markCardCreated(receiptId,createdcards.size());auditService.record(CREATE_FROM_RECEIPT,receiptId,cards.size());returncards.stream().map(AssetCard::getId).toList();}示例刻意没有让Controller拼接SQL也没有让前端决定最终状态。这样做的价值是批量任务、后台管理和普通页面调用同一服务时仍遵循同一套规则。若方法会抛出受检异常需要显式配置回滚规则Spring默认回滚语义不应靠猜测。九、事务、并发和外部调用的边界验收数量、卡片生成数量和验收单状态需要在同一事务边界校验。调用采购平台或财务系统不应放进长数据库事务可先提交本地事实再通过有状态的集成任务重试远端失败不能反向抹掉已经发生的到货验收。事务解决的是一个数据库边界内的一致性不会自动撤销已发送的短信、已上传的对象存储文件或外部财务系统请求。遇到跨系统动作应保存可重试任务、业务幂等键和最后错误并让操作人员看见“业务已完成、同步待处理”这类真实状态。长事务还会扩大锁持有时间因此批量操作要按可恢复的数据块处理。十、失败结果要能指导下一步处理异常不应全部压成“操作失败”。至少区分输入错误、业务冲突、权限拒绝、并发冲突和外部依赖失败前四类通常需要用户修改或确认最后一类才适合自动重试。本文案例建议使用以下结果场景结果码处理方式订单10台只到9台PARTIAL_RECEIPT保留1台待到货不提前建卡验收不合格REJECTED_ITEM记录拒收不进入待建卡重复点击建卡CARD_ALREADY_CREATED按验收行幂等返回已有卡财务接口暂时失败FINANCE_SYNC_PENDING保留本地事实并重试同步错误回执或接口响应可以显示业务编号和友好说明详细堆栈只进入受控日志。返回结果还应带request_id便于把用户看到的失败与服务端日志、批次明细及审计记录关联起来。十一、上线前用SQL核对业务结果页面数量只能用来快速观察最终验收还要在明确组织、期间和业务状态的前提下执行只读查询。下面查询用于发现不一致记录生产环境应先补充分区或公司条件并确认执行计划避免在大表上做无范围扫描。SELECTr.id,r.accepted_qty,COUNT(c.id)card_qty,r.accepted_qty-COUNT(c.id)pending_qtyFROMasset_receipt_line_demo rLEFTJOINasset_card_demo cONc.receipt_line_idr.idGROUPBYr.id,r.accepted_qtyHAVINGcard_qtyr.accepted_qty;若查询返回异常先保留样本和执行时间再判断是历史脏数据、迁移遗漏还是程序缺陷。不要为了让验收SQL返回零行而直接改库修复必须经过与正常业务相同的授权、留痕和复核。十二、可直接使用的技术验收表正式发布前固定一组小样本记录输入、预期、实际结果和证据位置。修复后仍用同一组样本复测才能知道变化来自代码而不是换了一批更容易通过的数据。验收维度预期结果证据正常路径业务结果、状态和关联记录符合预期业务页面 数据库查询重复操作第二次执行不产生重复主记录唯一键 行结果/业务结果越权或非法状态服务端拒绝原数据不变化低权限账号 更新前后对照执行中断可识别已完成与未完成范围批次状态 明细状态金额或数量汇总与来源口径完全一致固定样本 SQL核对追溯能回到操作者、单据、时间和请求审计时间轴 request_id验收完成后保存程序版本、数据库版本、样本编号和结论。只写“测试通过”无法回答测试了哪些边界也无法在下次升级后进行回归比较。小结固定资产从采购到入账怎么管理核心不是把页面操作做出来而是让每一步都能说明输入、边界、结果和验证证据。先用小样本走通再按实际数据量和业务制度扩大范围。参考资料MySQL 8.4SHOW CREATE TABLESpring Framework声明式事务管理MySQL 8.4CHECK约束Spring FrameworkBean Validation
采购订单写了10台笔记本到货后实际收了9台另1台下周补发发票又可能晚到。若采购、验收、资产卡和财务凭证各自独立录入系统很容易出现“已经折旧却没验收”或“实物在用但台账没有”的断层。以一张采购订单为例申请10台验收9台暂估金额90,000元。系统要允许分次收货但不允许把“申请数量”直接变成“可折旧资产数量”。本文以 Spring Boot MySQL 8.x 的小型管理系统为教学边界。表名、字段和数值均为示例上线前仍应依据资产制度、财务口径、数据量和现有程序进行评审。实现时建议把一次业务动作拆成四层Controller只接收请求和返回结果Service加载当前状态、执行权限与业务校验Repository使用参数化SQL读写数据库用主键、唯一键、非空和金额精度守住最后边界。前端校验可以减少误操作但不能替代服务端规则。本文的SQL用于展示约束和核对思路不是可直接在生产库执行的完整脚本。执行DDL前应确认MySQL版本、存储引擎、表规模、磁盘余量、主从延迟和锁等待执行查询前应补充公司、期间等范围并查看执行计划。代码示例省略了DTO、Mapper和统一异常处理但不会省略幂等、权限、事务和审计这些决定数据是否可信的部分。如果系统已经存在历史数据任何“新增唯一键”“改变状态含义”或“补齐关联ID”的操作都要先做数据剖析。先统计空值、重复值和非法状态再选择清洗、映射或人工确认不能因为新程序要求字段非空就用0或空字符串批量填满旧记录。正式改造前还应保存三份基线当前表结构的SHOW CREATE TABLE结果、目标范围的数量与金额汇总、能够代表正常和异常路径的固定样本。发布后使用同一口径复查并记录程序版本、数据库迁移版本和执行批次。如果需要回退先判断新版本是否已经写入旧程序无法识别的数据代码回退并不等于业务数据自动回退。对于大表新增索引或约束还要先在相近数据量的环境评估执行时间与锁影响不能只根据空测试库的耗时安排生产窗口。文中的状态名和错误码用于说明设计方法。真正落地时应集中定义状态枚举、合法迁移和错误码说明并为关键状态变化编写自动化测试避免不同接口各自解释同一个状态。批量接口还应限制单批数量、记录处理进度并提供明确的重复提交策略统计和导出任务不能绕开同样的数据权限与状态规则。监控指标至少区分请求失败、业务拒绝和异步待处理避免把合理拦截误报成系统故障。对于可重试任务应记录下一次执行时间、重试次数和最后错误超过上限转人工处理不能无限循环也不能把待处理悄悄显示成完成。所有后台修复动作同样要经过授权、幂等和审计并保留修复前后的核对证据方便后续回归测试和责任追溯。接口返回、数据库记录和审计事件中的业务编号应保持一致便于跨层定位、复核和比较结果。目录一、先区分申请、订单、到货和可资本化二、验收通过才产生候选资产卡三、一物一码与批次关系一起保存四、价值确认不能覆盖验收事实五、状态推进要由合法动作触发六、采购数量和资产数量必须可对账七、上线前用分批到货做验收八、服务层实现不能只相信页面参数九、事务、并发和外部调用的边界十、失败结果要能指导下一步处理十一、上线前用SQL核对业务结果十二、可直接使用的技术验收表一、先区分申请、订单、到货和可资本化采购到入账不是一张单据不断修改状态而是四类业务事实逐步衔接。申请单回答“为什么买、谁使用、预算从哪里来”采购订单回答“向谁买、买多少、约定多少钱”验收单回答“这一次实际到了什么、合格多少”资产卡和资本化记录才回答“哪些实物进入长期管理、按什么价值入账”。建议至少拆成purchase_request、purchase_order_line、asset_receipt_line、asset_card和asset_capitalization五类数据。核心关系不是简单的一对一而是一条申请明细可以形成一条或多条订单行一条订单行可以分多次到货一条验收明细又可以拆成多张单件资产卡。对象保存的事实数量口径后续是否允许覆盖采购申请需求、预算、预计使用部门申请数量审批完成后保留版本采购订单行供应商、型号、成交价订购数量变更应留订单版本验收明细到货批次、合格与拒收结论实收/合格/拒收数量已确认验收不得直接改写资产卡资产编码、序列号、使用状态单件或受控批次通过业务动作变更资本化记录入账日期、原值、凭证号财务确认数量与金额冲销或调整不覆盖原记录把这些对象拆开以后“订单10台、第一批到货6台、第二批到货4台且1台拒收、最终建卡9张”才能被准确表达。若只在订单上保存一个status和一个received_qty第二次到货很容易覆盖第一次验收的人员、附件和结论。图1采购到入账是四类事实的衔接。二、验收通过才产生候选资产卡验收接口不能只接收一个“通过”按钮。它至少要接收订单行、到货批次、实收数量、合格数量、拒收数量、供应商批次或序列号附件并在事务内完成三类校验本次合格数与拒收数之和必须等于实收数累计实收数不能超过订单数同一个验收请求不能重复确认。下面的服务层示例把这些规则放在后端。前端禁用按钮只能减少误操作不能阻止重复请求和并发提交。Transactional(rollbackForException.class)publicLongconfirmReceipt(ReceiptCommandcommand){PurchaseOrderLineorderLineorderLineRepository.lockById(command.purchaseLineId()).orElseThrow(()-newBizException(采购订单行不存在));if(command.acceptedQty()command.rejectedQty()!command.receivedQty()){thrownewBizException(合格数量与拒收数量之和必须等于实收数量);}intconfirmedQtyreceiptRepository.sumConfirmedQty(command.purchaseLineId());if(confirmedQtycommand.receivedQty()orderLine.getOrderQty()){thrownewBizException(累计实收数量不能超过采购数量);}returnreceiptRepository.findIdByRequestNo(command.requestNo()).orElseGet(()-{AssetReceiptLinereceiptAssetReceiptLine.confirmed(orderLine.getId(),command.requestNo(),command.receivedQty(),command.acceptedQty(),command.rejectedQty(),command.attachmentId());receiptRepository.insert(receipt);auditService.record(RECEIPT_CONFIRMED,receipt.getId());returnreceipt.getId();});}这里的lockById用于串行化同一订单行的收货确认requestNo用于幂等。生产系统还应在数据库上为请求号建立唯一约束即使两个请求同时通过了应用层查询也只能有一个成功写入。合格数量进入待建卡范围拒收数量进入退换货或补货流程不能把拒收数据删除后假装从未到货。图210台下单9台验收的正确关系。三、一物一码与批次关系一起保存验收通过后也不应立即把订单行复制成资产卡。系统需要先确定管理粒度电脑、车辆、仪器等会独立领用、维修和报废的实物通常一物一码同质且不需要逐件追踪的低值物品可以按受控批次管理。无论选择哪种粒度资产卡都必须保留来源验收行而不是只保存供应商和采购日期。单件建卡时可以用receipt_line_id item_sequence作为来源唯一键。例如验收行1001合格9台生成序号1至9的九张候选卡。网络超时后再次点击“生成资产卡”数据库唯一约束会阻止第十张重复卡出现。CREATETABLEasset_card_demo(idBIGINTPRIMARYKEYAUTO_INCREMENT,asset_codeVARCHAR(64)NOTNULL,receipt_line_idBIGINTNOTNULL,item_sequenceINTNOTNULL,serial_numberVARCHAR(128),card_statusVARCHAR(24)NOTNULLDEFAULTPENDING,UNIQUEKEYuk_asset_code(asset_code),UNIQUEKEYuk_receipt_item(receipt_line_id,item_sequence));资产编码和二维码应在资产卡写入成功后生成或绑定。先打印9张标签、后建卡失败会留下无法追踪的“孤儿标签”先建卡并记录PENDING_LABEL打印成功后再变为ACTIVE则可以重试打印而不重复生成资产。若供应商提供设备序列号还可以对serial_number做组织范围内的重复检查但不要用可能为空或会改变的序列号代替内部资产主键。图3验收批次怎样拆成单件资产卡。四、价值确认不能覆盖验收事实暂估、发票确认、税额拆分和资本化属于财务阶段它们引用已经确认的资产卡而不是反向修改验收单。发票晚到时实物可以先处于待入账状态财务确认后新增资本化记录写入确认数量、原值、税额、入账日期和凭证号。若发票金额与暂估金额不同应生成差异调整记录并保留暂估版本。直接把资产卡的原值从90,000改成92,000虽然页面最终数字正确却无法回答差异由哪张发票、谁在何时确认。数量事实与价值事实分开保存也能避免“财务调整金额时把验收日期一并改掉”。图4数量对账要看整条链。CREATETABLEasset_receipt_line_demo(idBIGINTPRIMARYKEYAUTO_INCREMENT,purchase_line_idBIGINTNOTNULL,request_noVARCHAR(64)NOTNULL,received_qtyINTNOTNULL,accepted_qtyINTNOTNULL,rejected_qtyINTNOTNULL,receipt_statusVARCHAR(24)NOTNULL,attachment_idBIGINT,UNIQUEKEYuk_receipt_request(request_no),CHECK(received_qty0),CHECK(accepted_qty0ANDrejected_qty0),CHECK(accepted_qtyrejected_qtyreceived_qty));SELECTp.id,p.order_qty,COALESCE(SUM(r.received_qty),0)ASreceived_qty,COALESCE(SUM(r.accepted_qty),0)ASaccepted_qty,COALESCE(SUM(r.rejected_qty),0)ASrejected_qtyFROMpurchase_line pLEFTJOINasset_receipt_line_demo rONr.purchase_line_idp.idANDr.receipt_statusCONFIRMEDGROUPBYp.id,p.order_qtyHAVINGreceived_qtyp.order_qty;五、状态推进要由合法动作触发建议将订单、验收、资产卡和资本化分别维护状态不建立一个横跨全流程的万能状态。订单可以是PARTIALLY_RECEIVED验收行是ACCEPTED已生成的卡片是PENDING_CAPITALIZATION四者同时存在并不矛盾。每个动作都要校验当前状态例如只有已确认验收行可以建卡只有待入账资产卡可以资本化已资本化资产只能通过冲销或调整处理。状态变化同时写入审计表保存业务单号、操作者、前后状态和请求ID禁止通过通用“更新状态”接口任意跳转。图5流程验收清单。六、采购数量和资产数量必须可对账对账至少计算四个数量订单数量、累计实收数量、累计验收合格数量和已建卡数量。本例订单10台、实收10台、合格9台、建卡9张、拒收1台是可解释的闭环订单10台、合格9台却建卡10张则必须阻断。金额也要单独核对资产卡待确认原值之和、资本化金额和发票确认金额可以暂时不同但差异必须落在明确状态中。把数量差异和金额差异混成一个“未完成”标志会让采购、资产管理员和财务互相看不懂问题到底在哪里。七、上线前用分批到货做验收至少准备五组可复现数据分两批到货、部分拒收、同一请求重复提交、两名验收员并发确认、发票晚于资产启用。每组测试都要同时核对页面结果、数据库数量、资产卡来源和审计记录。特别要验证失败后的边界附件上传成功但事务回滚时是否留下无主附件九张卡生成到第五张失败时是否整体回滚重复请求返回原结果还是再次建卡。只有正常路径和异常路径都能给出明确结果采购到入账才算真正形成闭环。八、服务层实现不能只相信页面参数接口收到的公司、部门、状态和金额只能视为请求数据不能直接当成已经校验的业务事实。服务层至少要重新加载当前记录、计算操作者范围、校验当前状态并将业务结果写成可识别的返回对象。下面代码只展示关键边界仓储方法、异常类型和审计方式需按项目实现。Transactional(rollbackForException.class)publicListLongcreateCardsFromReceipt(longreceiptId){ReceiptreceiptreceiptRepository.lockById(receiptId);requireStatus(receipt,ACCEPTED);intcreatedcardRepository.countByReceiptId(receiptId);intremainingreceipt.getAcceptedQty()-created;if(remaining0)returncardRepository.idsByReceiptId(receiptId);ListAssetCardcardscardFactory.create(receipt,remaining);cardRepository.batchInsert(cards);receiptRepository.markCardCreated(receiptId,createdcards.size());auditService.record(CREATE_FROM_RECEIPT,receiptId,cards.size());returncards.stream().map(AssetCard::getId).toList();}示例刻意没有让Controller拼接SQL也没有让前端决定最终状态。这样做的价值是批量任务、后台管理和普通页面调用同一服务时仍遵循同一套规则。若方法会抛出受检异常需要显式配置回滚规则Spring默认回滚语义不应靠猜测。九、事务、并发和外部调用的边界验收数量、卡片生成数量和验收单状态需要在同一事务边界校验。调用采购平台或财务系统不应放进长数据库事务可先提交本地事实再通过有状态的集成任务重试远端失败不能反向抹掉已经发生的到货验收。事务解决的是一个数据库边界内的一致性不会自动撤销已发送的短信、已上传的对象存储文件或外部财务系统请求。遇到跨系统动作应保存可重试任务、业务幂等键和最后错误并让操作人员看见“业务已完成、同步待处理”这类真实状态。长事务还会扩大锁持有时间因此批量操作要按可恢复的数据块处理。十、失败结果要能指导下一步处理异常不应全部压成“操作失败”。至少区分输入错误、业务冲突、权限拒绝、并发冲突和外部依赖失败前四类通常需要用户修改或确认最后一类才适合自动重试。本文案例建议使用以下结果场景结果码处理方式订单10台只到9台PARTIAL_RECEIPT保留1台待到货不提前建卡验收不合格REJECTED_ITEM记录拒收不进入待建卡重复点击建卡CARD_ALREADY_CREATED按验收行幂等返回已有卡财务接口暂时失败FINANCE_SYNC_PENDING保留本地事实并重试同步错误回执或接口响应可以显示业务编号和友好说明详细堆栈只进入受控日志。返回结果还应带request_id便于把用户看到的失败与服务端日志、批次明细及审计记录关联起来。十一、上线前用SQL核对业务结果页面数量只能用来快速观察最终验收还要在明确组织、期间和业务状态的前提下执行只读查询。下面查询用于发现不一致记录生产环境应先补充分区或公司条件并确认执行计划避免在大表上做无范围扫描。SELECTr.id,r.accepted_qty,COUNT(c.id)card_qty,r.accepted_qty-COUNT(c.id)pending_qtyFROMasset_receipt_line_demo rLEFTJOINasset_card_demo cONc.receipt_line_idr.idGROUPBYr.id,r.accepted_qtyHAVINGcard_qtyr.accepted_qty;若查询返回异常先保留样本和执行时间再判断是历史脏数据、迁移遗漏还是程序缺陷。不要为了让验收SQL返回零行而直接改库修复必须经过与正常业务相同的授权、留痕和复核。十二、可直接使用的技术验收表正式发布前固定一组小样本记录输入、预期、实际结果和证据位置。修复后仍用同一组样本复测才能知道变化来自代码而不是换了一批更容易通过的数据。验收维度预期结果证据正常路径业务结果、状态和关联记录符合预期业务页面 数据库查询重复操作第二次执行不产生重复主记录唯一键 行结果/业务结果越权或非法状态服务端拒绝原数据不变化低权限账号 更新前后对照执行中断可识别已完成与未完成范围批次状态 明细状态金额或数量汇总与来源口径完全一致固定样本 SQL核对追溯能回到操作者、单据、时间和请求审计时间轴 request_id验收完成后保存程序版本、数据库版本、样本编号和结论。只写“测试通过”无法回答测试了哪些边界也无法在下次升级后进行回归比较。小结固定资产从采购到入账怎么管理核心不是把页面操作做出来而是让每一步都能说明输入、边界、结果和验证证据。先用小样本走通再按实际数据量和业务制度扩大范围。参考资料MySQL 8.4SHOW CREATE TABLESpring Framework声明式事务管理MySQL 8.4CHECK约束Spring FrameworkBean Validation
