企业官网建设流程全解析

1. 这篇文章真正要解决的问题

当你的业务从简单的自营库存，扩展到需要将商品提前铺货到经销商、代理商或大客户的仓库时，传统的进销存管理瞬间就失灵了。你会发现，货发出去了，但所有权还是你的，销售数据却不在你的系统里；客户卖了多少、还剩多少、该结算多少，全凭对方一张Excel表格，对账周期长、数据不透明、资金占用大。这不仅仅是“库存管理”的延伸，而是整个供应链协同和财务风险管控模式的根本性变革。

这就是“寄售管理”要解决的核心痛点。很多技术团队在初次接触ERP的寄售模块时，容易陷入一个误区：认为它只是一个高级的“仓库管理”或“客户管理”功能。实际上，寄售管理的本质是在物权转移与结算分离的复杂业务场景下，实现库存、销售、财务三流合一的精细化管控体系。它考验的不是简单的CRUD能力，而是对业务流程、会计准则和系统边界的深刻理解。

本文将从一个开发或实施者的视角，深入拆解一体化ERP中寄售管理的设计与实现。你不会看到泛泛而谈的“重要性”论述，而是会得到一套从核心概念辨析、数据模型设计、关键业务流程（发货、消耗、结算）实现，到与WMS、财务系统集成的完整技术方案。无论你是正在选型、准备自研，还是负责现有ERP系统的运维与优化，这篇文章都将帮你理清思路，避开那些在项目后期才会暴露的“巨坑”。

2. 寄售 vs. 传统销售：核心概念与业务边界

在动手设计表结构或写代码之前，必须彻底理解寄售业务与传统销售的本质区别。混淆这两者，是后续所有设计错误的根源。

传统销售（买断式）：

1. 物权转移：货物出库（或提单）时，商品的所有权从卖方转移至买方。
2. 风险转移：同时，货物的损毁、灭失风险也转移给买方。
3. 债权确认：出库即产生应收账款，无论买方是否已将货物售出。
4. 核算时点：出库即确认收入、结转成本。

寄售销售：

1. 物权未转移：货物从你的仓库发到寄售商（Consignee）的指定地点（可能是其仓库，也可能是第三方物流仓），但所有权仍属于你（寄售方，Consignor）。
2. 风险可能未完全转移：通常，在寄售商实际售出或领用前，货物的主要风险仍由你承担。
3. 债权未确认：发货不产生应收款。只有寄售商根据实际销售或消耗向你报告后，才形成有效的结算依据，此时才产生债权。
4. 核算时点：在寄售商报告消耗（或你盘点确认消耗）时，才确认收入和成本。发货时，库存只是从“自有仓”转移到了“寄售仓”（在账面上仍属于你的资产）。

用一个简单的类比：传统销售像是“批发”，一手交钱一手交货（或赊销协议）；而寄售更像是“代销”或“铺货”，你把货放到别人的店里卖，卖了再分钱，没卖完的可以退回来。

在ERP系统中，这种区别会体现在几乎所有核心模块：

• 库存管理：需要区分“自有库存”、“寄售库存”（物权属我，地点在他处）和“客户库存”（物权属他）。
• 销售模块：销售订单类型不同，发货单的后续处理逻辑完全不同。
• 财务管理：收入确认的会计凭证分录、时点完全不同，直接影响财务报表。
• 报表分析：需要单独分析寄售库存的周转率、呆滞情况，以及寄售商的销售效能。

3. 环境准备与核心数据模型设计

理解了业务概念，我们进入实战环节。假设我们基于一个常见的Java + Spring Boot + MySQL技术栈来构建核心模块。首先，明确环境与依赖。

3.1 环境与依赖

• JDK: 8 或 11
• Spring Boot: 2.7.x
• 持久层: MyBatis-Plus 3.5.x (简化CRUD)
• 数据库: MySQL 5.7+ 或 8.0
• 核心依赖 (pom.xml):

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jdbc</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- 其他工具依赖如lombok, hutool等 --> </dependencies>

3.2 核心数据模型设计这是整个系统的基石。设计不当，后期业务扩展和报表生成将举步维艰。以下是几个最核心的表结构。

• 寄售主协议表 (consignment_contract)定义与某个客户（寄售商）的总体合作框架。

CREATE TABLE `consignment_contract` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `contract_code` varchar(64) NOT NULL COMMENT '协议编号', `customer_id` bigint(20) NOT NULL COMMENT '客户(寄售商)ID', `customer_name` varchar(255) NOT NULL COMMENT '客户名称', `start_date` date NOT NULL COMMENT '生效日期', `end_date` date DEFAULT NULL COMMENT '失效日期', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态:1生效,0终止', `settlement_period` varchar(20) DEFAULT 'MONTHLY' COMMENT '结算周期: WEEKLY, MONTHLY, QUARTERLY', `price_type` varchar(20) DEFAULT 'CONTRACT_PRICE' COMMENT '计价方式: CONTRACT_PRICE(协议价), LIST_PRICE(列表价)', `warehouse_id` bigint(20) DEFAULT NULL COMMENT '寄售仓库ID(对方仓库或第三方仓)', `warehouse_name` varchar(255) DEFAULT NULL COMMENT '寄售仓库名称', `remark` text COMMENT '备注', `created_by` varchar(64) DEFAULT NULL, `created_time` datetime DEFAULT CURRENT_TIMESTAMP, `updated_by` varchar(64) DEFAULT NULL, `updated_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_contract_code` (`contract_code`), KEY `idx_customer` (`customer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='寄售主协议表';

• 寄售库存表 (consignment_stock)这是整个寄售管理的核心状态表，实时记录每一批货物在寄售地的状态。

CREATE TABLE `consignment_stock` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `contract_id` bigint(20) NOT NULL COMMENT '寄售协议ID', `customer_id` bigint(20) NOT NULL COMMENT '客户ID', `material_id` bigint(20) NOT NULL COMMENT '物料ID', `material_code` varchar(64) NOT NULL COMMENT '物料编码', `material_name` varchar(255) NOT NULL COMMENT '物料名称', `batch_no` varchar(64) DEFAULT NULL COMMENT '批次号', `stock_location` varchar(255) DEFAULT NULL COMMENT '寄售地具体库位', `total_quantity` decimal(20,6) NOT NULL DEFAULT '0.000000' COMMENT '发货总数量', `consumed_quantity` decimal(20,6) NOT NULL DEFAULT '0.000000' COMMENT '已消耗/销售数量', `returned_quantity` decimal(20,6) NOT NULL DEFAULT '0.000000' COMMENT '已退回数量', `on_hand_quantity` decimal(20,6) GENERATED ALWAYS AS (`total_quantity` - `consumed_quantity` - `returned_quantity`) STORED COMMENT '结存数量(虚拟字段，计算得出)', `unit` varchar(20) NOT NULL COMMENT '单位', `unit_price` decimal(20,6) NOT NULL COMMENT '单价(协议价)', `currency` varchar(10) DEFAULT 'CNY' COMMENT '币种', `consignment_date` date NOT NULL COMMENT '发货日期', `expiry_date` date DEFAULT NULL COMMENT '有效期至', `status` varchar(20) DEFAULT 'IN_STOCK' COMMENT '状态: IN_STOCK(在库), PART_CONSUMED(部分消耗), FULL_CONSUMED(全部消耗), RETURNED(已退回)', `original_delivery_id` bigint(20) NOT NULL COMMENT '来源发货单ID', `original_delivery_code` varchar(64) NOT NULL COMMENT '来源发货单号', PRIMARY KEY (`id`), UNIQUE KEY `uk_stock_batch` (`contract_id`,`material_id`,`batch_no`,`original_delivery_code`(32)) COMMENT '同一协议、物料、批次、发货单唯一', KEY `idx_customer_material` (`customer_id`,`material_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='寄售库存明细表';

关键设计点：

1. on_hand_quantity使用了生成列，确保结存数量永远等于总发 - 消耗 - 退回，数据一致性由数据库保证。
2. 唯一索引uk_stock_batch防止同一批货物被重复记录，这是保证库存准确性的生命线。
3. status字段用于快速筛选不同状态的寄售品，便于业务查询和预警。

• 寄售消耗记录表 (consumption_record)记录寄售商每一次的销售或领用，是结算的唯一依据。

CREATE TABLE `consumption_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `consumption_code` varchar(64) NOT NULL COMMENT '消耗单号', `contract_id` bigint(20) NOT NULL COMMENT '协议ID', `customer_id` bigint(20) NOT NULL COMMENT '客户ID', `consumption_date` date NOT NULL COMMENT '消耗日期', `report_date` date NOT NULL COMMENT '上报日期', `report_type` varchar(20) DEFAULT 'MANUAL' COMMENT '上报方式: MANUAL(手工), EDI(接口), SCAN(扫描)', `total_amount` decimal(20,2) DEFAULT '0.00' COMMENT '消耗总金额', `status` varchar(20) DEFAULT 'DRAFT' COMMENT '状态: DRAFT(草稿), CONFIRMED(已确认), SETTLED(已结算)', `attachment_url` varchar(500) DEFAULT NULL COMMENT '凭证附件', `created_by` varchar(64) DEFAULT NULL, `created_time` datetime DEFAULT CURRENT_TIMESTAMP, `confirmed_by` varchar(64) DEFAULT NULL, `confirmed_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_consumption_code` (`consumption_code`), KEY `idx_contract_status` (`contract_id`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='寄售消耗记录主表';

消耗明细表 (consumption_record_detail)与主表关联，记录消耗了哪些寄售库存。

CREATE TABLE `consumption_record_detail` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `consumption_id` bigint(20) NOT NULL COMMENT '消耗主表ID', `consignment_stock_id` bigint(20) NOT NULL COMMENT '消耗的寄售库存ID', `consumed_quantity` decimal(20,6) NOT NULL COMMENT '本次消耗数量', `unit_price` decimal(20,6) NOT NULL COMMENT '消耗单价', `amount` decimal(20,2) GENERATED ALWAYS AS (`consumed_quantity` * `unit_price`) STORED COMMENT '金额', PRIMARY KEY (`id`), KEY `fk_detail_consumption` (`consumption_id`), KEY `fk_detail_stock` (`consignment_stock_id`), CONSTRAINT `fk_detail_consumption` FOREIGN KEY (`consumption_id`) REFERENCES `consumption_record` (`id`) ON DELETE CASCADE, CONSTRAINT `fk_detail_stock` FOREIGN KEY (`consignment_stock_id`) REFERENCES `consignment_stock` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='寄售消耗记录明细表';

4. 核心业务流程拆解与实现

有了数据模型，我们来看三大核心业务流程：发货、消耗确认、结算。每一个流程都涉及多张表的联动和状态更新，事务控制至关重要。

4.1 流程一：寄售发货此流程将自有库存转为寄售库存。

1. 创建寄售销售订单：订单类型为“寄售”，关联consignment_contract。
2. 创建发货单：基于订单生成发货单。关键点：此时库存检查扣减的是“自有可用库存”，但生成的是“寄售发货单”，不产生应收账。
3. 发货过账：这是最核心的一步。系统需要执行以下原子操作：
   • 减少自有仓库的实物库存。
   • 在consignment_stock表中插入一条新的记录，total_quantity等于发货数量，consumed_quantity和returned_quantity为0，状态为IN_STOCK。
   • 更新库存状态，可能需要在material_stock表中增加一个“寄售锁定”或直接减少“可用数量”的字段。
   • 生成会计凭证：借：发出商品（资产类科目） 贷：库存商品。这一步是区分寄售和普通销售在财务上的关键。

代码示例：发货过账服务层核心逻辑

// 文件路径：src/main/java/com/example/erp/consignment/service/impl/ConsignmentDeliveryServiceImpl.java @Service @Transactional(rollbackFor = Exception.class) // 声明式事务，确保原子性 @Slf4j public class ConsignmentDeliveryServiceImpl implements ConsignmentDeliveryService { @Autowired private ConsignmentStockMapper stockMapper; @Autowired private InventoryService inventoryService; // 库存服务 @Autowired private FinanceService financeService; // 财务服务 @Override public boolean postDelivery(ConsignmentDeliveryPostDTO postDTO) { // 1. 参数校验 if (postDTO.getDeliveryId() == null) { throw new BusinessException("发货单ID不能为空"); } // ... 其他校验 // 2. 查询发货单明细（假设已通过其他服务获取） List<DeliveryDetailVO> detailList = getDeliveryDetails(postDTO.getDeliveryId()); if (CollectionUtils.isEmpty(detailList)) { throw new BusinessException("发货单明细为空"); } // 3. 遍历明细，处理每一行物料 for (DeliveryDetailVO detail : detailList) { // 3.1 扣减自有仓库库存（需检查可用量） inventoryService.reduceOwnStock( detail.getMaterialId(), detail.getBatchNo(), detail.getQuantity(), detail.getWarehouseId(), "CONSIGNMENT_DELIVERY", postDTO.getDeliveryCode() ); // 3.2 创建寄售库存记录 ConsignmentStock newStock = new ConsignmentStock(); newStock.setContractId(postDTO.getContractId()); newStock.setCustomerId(postDTO.getCustomerId()); newStock.setMaterialId(detail.getMaterialId()); newStock.setMaterialCode(detail.getMaterialCode()); newStock.setMaterialName(detail.getMaterialName()); newStock.setBatchNo(detail.getBatchNo()); newStock.setStockLocation(postDTO.getConsignmentLocation()); newStock.setTotalQuantity(detail.getQuantity()); newStock.setConsumedQuantity(BigDecimal.ZERO); newStock.setReturnedQuantity(BigDecimal.ZERO); // on_hand_quantity 是生成列，自动计算 newStock.setUnit(detail.getUnit()); newStock.setUnitPrice(detail.getContractPrice()); // 取自协议价 newStock.setConsignmentDate(new Date()); newStock.setExpiryDate(detail.getExpiryDate()); newStock.setStatus(ConsignmentStockStatus.IN_STOCK.getCode()); newStock.setOriginalDeliveryId(postDTO.getDeliveryId()); newStock.setOriginalDeliveryCode(postDTO.getDeliveryCode()); int insertResult = stockMapper.insert(newStock); if (insertResult <= 0) { // 插入失败，事务会回滚上面的库存扣减 throw new BusinessException("创建寄售库存记录失败"); } } // 4. 调用财务接口，生成“发出商品”凭证（异步或同步） financeService.createConsignmentDeliveryVoucher(postDTO); // 5. 更新发货单状态为“已过账” updateDeliveryStatus(postDTO.getDeliveryId(), DeliveryStatus.POSTED); log.info("寄售发货单[{}]过账成功，共处理{}条明细。", postDTO.getDeliveryCode(), detailList.size()); return true; } }

4.2 流程二：消耗确认寄售商定期（或实时）上报销售/领用数据。

1. 接收消耗数据：可通过手工录入、Excel导入、EDI接口、扫描枪回传等多种方式。
2. 创建消耗单：在consumption_record和consumption_record_detail中保存原始数据，状态为DRAFT。
3. 匹配寄售库存：这是技术难点。需要根据物料、批次、发货单号，找到对应的consignment_stock记录，并检查结存数量是否足够。
4. 确认消耗：业务人员审核无误后，执行确认操作。系统需要：
   • 更新consumption_record.status = CONFIRMED。
   • 更新对应的consignment_stock记录，consumed_quantity增加，status根据结存数量自动更新（如PART_CONSUMED,FULL_CONSUMED）。
   • 注意：此时仍不产生应收款，但为结算准备好了数据。

4.3 流程三：寄售结算根据结算周期（如每月），将已确认的消耗汇总生成结算单和应收款。

1. 生成结算单：按客户、协议、结算周期，汇总所有status = CONFIRMED且未结算的consumption_record。
2. 创建应收单据：基于结算单，在财务模块创建正式的应收账款（或销售发票）。
3. 更新状态：将涉及的所有consumption_record状态更新为SETTLED。同时，财务系统生成凭证：借：应收账款 贷：主营业务收入 应交税费；同时，借：主营业务成本 贷：发出商品。至此，整个寄售业务的收入和成本才正式确认。

5. 关键问题与系统集成考量

5.1 库存同步与WMS集成寄售库存的物理位置在客户或第三方仓库。如何保证系统账面库存与实际一致？

• 方案一：被动接收：依赖客户提供的消耗报告。数据有滞后，易产生差异。
• 方案二：主动查询：如果寄售仓库使用你的WMS或支持标准接口，可以定期同步库存快照。这需要设计一个consignment_stock_snapshot表，记录每次同步的时点库存，并与系统账面库存进行比对，生成差异报告。
• 方案三：条码/RFID全程跟踪：每个实物单元都有唯一标识，出入库均需扫描，数据实时回传。这是最准确但成本最高的方案。

与WMS集成的接口示例（查询寄售仓库存）：

// 文件路径：src/main/java/com/example/erp/integration/wms/WmsServiceClient.java @Component public class WmsServiceClient { @Value("${wms.service.url}") private String wmsServiceUrl; public List<WmsInventoryVO> getConsignmentInventory(Long customerId, String warehouseCode) { // 构建请求参数 Map<String, Object> params = new HashMap<>(); params.put("customerCode", getCustomerCodeById(customerId)); params.put("warehouseCode", warehouseCode); params.put("inventoryType", "CONSIGNMENT"); // 调用WMS系统提供的REST API ResponseEntity<WmsResponse<List<WmsInventoryVO>>> response = restTemplate.postForEntity( wmsServiceUrl + "/api/inventory/query", params, new ParameterizedTypeReference<WmsResponse<List<WmsInventoryVO>>>() {} ); if (response.getStatusCode().is2xxSuccessful() && response.getBody() != null && response.getBody().isSuccess()) { return response.getBody().getData(); } else { log.error("调用WMS查询寄售库存失败: {}", response.getBody()); throw new IntegrationException("WMS服务调用异常"); } } }

5.2 消耗匹配算法当寄售商上报的消耗数据没有批次或发货单号时，如何匹配到具体的consignment_stock记录？这是一个经典的库存计价问题（如先进先出FIFO、后进先出LIFO）。

• 必须明确规则：在consignment_contract中增加consumption_matching_rule字段（如FIFO,LIFO,SPECIFIC_BATCH）。
• 实现FIFO匹配的SQL示例：

-- 为某个客户和物料，查找最早发货且还有结存的寄售库存记录 SELECT * FROM consignment_stock WHERE customer_id = #{customerId} AND material_id = #{materialId} AND on_hand_quantity > 0 AND status IN ('IN_STOCK', 'PART_CONSUMED') ORDER BY consignment_date ASC, id ASC LIMIT 1 FOR UPDATE; -- 使用FOR UPDATE锁定记录，防止并发消耗

在Service层，你需要在一个数据库事务中，先锁定这条记录，然后判断结存是否足够本次消耗，再进行更新。

5.3 状态机与业务校验寄售库存和消耗单的状态流转必须严谨，防止业务倒流或重复操作。

• 寄售库存状态机：IN_STOCK->PART_CONSUMED->FULL_CONSUMED或RETURNED。消耗和退货操作必须校验当前状态。
• 消耗单状态机：DRAFT->CONFIRMED->SETTLED。确认后不可修改，结算后不可重复结算。

6. 报表、监控与最佳实践

6.1 核心报表

• 寄售库存余额表：分客户、物料、仓库显示结存数量与金额。
• 寄售库存账龄分析表：分析在寄售地存放了多久，识别呆滞风险。
• 寄售消耗明细与汇总表：用于与客户对账。
• 寄售结算跟踪表：跟踪已消耗未结算、已结算未开票等状态。

6.2 监控预警

• 库存差异预警：系统账面结存与WMS同步的实物结存差异超过阈值时告警。
• 长期未消耗预警：寄售库存超过一定期限（如90天）仍未消耗，提醒业务人员跟进。
• 结算逾期预警：消耗确认后，超过协议约定的结算天数仍未生成结算单。

6.3 工程实践建议

1. 事务边界清晰：发货、消耗确认、结算等核心操作必须放在事务中，且事务粒度要合理，不宜过大。
2. 幂等性设计：对于接口上报的消耗数据，要支持幂等操作，防止因网络重试导致数据重复。
3. 审计日志完备：所有库存变动、状态变更都必须记录操作人、时间、前后值，这是后续对账和排查问题的唯一依据。
4. 配置化与扩展性：将结算周期、计价方式、匹配规则等做成配置项，便于应对不同客户的差异化需求。
5. 性能考虑：consignment_stock表会随时间增长，需建立合理的索引（如(customer_id, material_id, status)），并对历史已完全结算且结存为0的数据进行归档。

7. 总结：从技术实现到业务价值

寄售管理不是ERP中一个孤立的“功能点”，而是一个贯穿销售、库存、财务的核心业务流程。技术实现的重点在于通过严谨的数据模型和状态机，精准地刻画“物权”与“结算权”分离这一业务实质。

对于开发者而言，理解“发出商品”这个会计科目在系统中的流转轨迹，是设计好寄售模块的关键。对于项目管理者，确保业务、财务、IT三方对“消耗确认时点”、“结算流程”、“差异处理规则”达成共识，比编码本身更重要。

自研或实施这类系统时，切忌一开始就追求大而全。可以从最核心的“发货-消耗-结算”主干流程做起，确保数据准确、账实相符。然后再逐步扩展WMS集成、多种计价规则、复杂结算条款（如返利）等高级功能。

最终，一个优秀的寄售管理系统，不仅能降低企业资金占用和库存风险，更能成为提升供应链协同效率、增强客户粘性的战略工具。而这一切，都始于你对那几条核心表结构和状态流转的精心设计。