企业官网建设流程全解析

简介：本资源为Oracle ERP供应链解决方案的专题演示文稿，面向企业信息化顾问、供应链计划与实施人员，以及希望了解Oracle EBS供应链体系的技术学习者。内容围绕“从需求到交付”的端到端流程展开，覆盖销售、物流、计划、制造与采购各环节，重点讲解需求计划、S&OP、供应计划、物料计划、生产排程与订单承诺等模块，并延伸到贝叶斯混合模型预测、促销效果分析、集中式供应链计划平台、约束与成本优化计划、双向供需追溯等具体知识点，适合作为方案选型与知识梳理的参考。资源为单个pptx文件，压缩包约2.3MB，篇幅集中、结构清晰，便于按计划层、运营层、战略层三条主线快速检索。目前已有120人浏览学习。读者可借此理解Oracle供应链计划的分层逻辑与业务场景映射，掌握预测协同、供应网络配置、替代场景模拟等实施要点，为方案汇报或系统落地提供素材支撑。

1. Oracle ERP 供应链解决方案 pptx：被追问最狠的三页，往往一页代码都没有

做过 Oracle ERP 供应链解决方案 pptx 的人，多半都经历过同一个场面：前面的架构图讲得顺风顺水，客户冷不丁问一句「你这个可用量，是按子库存算还是按组织算，在途算不算」。真正决定这份 pptx 能不能过会的，从来不是配色和渐变色块，而是业务蓝图、数据口径、并发与性能这三页背后有没有真东西撑着。它要解决的是三件事——方案讲得清、数字对得上、演示跑得动；适合做 ERP 实施顾问、甲方供应链 IT，以及被临时拉来做方案的技术负责人。

2. 把供应链讲成一张业务地图：Oracle ERP 里到底有哪几块

一份供应链方案 pptx 最常见的失败方式，是把 Oracle 的模块名当积木摆一页：采购、库存、订单、制造、计划，五个色块排开，看着很全，但客户看不出货是怎么从供应商走到客户手上的。真正的蓝图页应该是一条链，链上每个节点都能指到具体模块和具体表。这一章先把链条理顺，再谈选型那句话怎么写。

2.1 从请购到发货，ERP 系统业务流程在 Oracle 里落成哪几张表

标准离散制造的业务流程，拆开大概是这么七步：需求计划跑出净需求，触发请购；请购转采购订单；供应商发货后收货、质检、入库；生产工单领料、完工入库；销售订单确认、挑库、发运；最后应收和成本结转。每一步在 Oracle ERP 里都有对应的模块和主表，方案页上写「采购协同」四个字，底下得知道是 PO_HEADERS_ALL 和 PO_LINE_LOCATIONS_ALL 在承压。

写方案时我一般会做一件事：把每一页蓝图右上角标注一句「数据落点」。比如库存页标注「MTL_ONHAND_QUANTITIES_DETAIL + MTL_SYSTEM_ITEMS_B」，订单页标注「OE_ORDER_HEADERS_ALL + OE_ORDER_LINES_ALL」，收货页标注「RCV_SHIPMENT_HEADERS + RCV_TRANSACTIONS」。这一行小字在评审时的作用，比整页流程图都大——它说明你不是在画图，是在设计数据链路。客户的技术负责人只要看到这一行，问的问题就会从「你这方案靠不靠谱」变成「你这个表的分区策略是什么」，沟通层级直接换了一档。

2.2 蓝图页与模块对照：一张表把方案和数据库表接上

下面这张表是我做方案时的底稿，pptx 里不必全放，但自己必须心里有数。左边是客户能听懂的话，中间是模块，右边是评审时可能被追问的表。做 pptx 的时候我会把它压缩成三列展示，每列只留关键词，讲的时候再展开。

表格里最容易出问题的是「计划与补货」这一行。计划的输出在很多项目里是一张 Excel，pptx 上写「智能补货」四个字很轻松，但落到系统里，补货建议到底写在计划工作表还是自建表，直接决定了后面报表怎么做。我一般会在方案里明确一句：计划结果落在自建中间表，由调度作业每日刷新，与 MRP 输出做比对。这样既保留了 Oracle 的标准能力，又给客户留了可验证的口子。

2.3 EBS 还是 Fusion Cloud：选型页写一句结论加三个前提

选型页最忌讳写「两种方案各有优劣」。客户要的是判断。我的写法是：给一句明确结论，再补三个前提假设，让结论可被推翻——这样既显得专业，又把责任边界讲清楚了。比如「建议在现有 EBS 12.2 上升级并做供应链模块深化，前提是：一，未来三年不引入集团级多会计准则的强制统一；二，仓储自动化设备接口不超过三类；三，二次开发总量控制在三百人天以内」。三个前提只要有一个不成立，结论就要重估，客户听着舒服，你也不会被绑死。

判断维度上，我一般看四件事：行业特殊流程有多少（流程制造的联副产品、离散的配置 BOM，SaaS 标准功能覆盖度差别很大）；二次开发量（历史项目里这部分常常占一半以上工作量）；合规与留痕要求；以及总拥有成本的口径——是把 DBA 人力算进去，还是只算订阅费。这四个维度想清楚，选型页就写得住，不会变成套话。

3. 用 Oracle 数据库把方案里的数字坐实：库存、未交订单与快照

方案评审到后半程，一定会有人问「你这个数字是怎么算出来的」。这时候如果只能说「系统里导出来的」，基本就交代了。这一章给三条能直接跑的 SQL，分别对应现有量、翻页取数和日报快照，跑通之后你就可以在 pptx 的每个数字下面标脚本编号。

3.1 现有量与可用量：一条 SQL 跑出组织加子库存维度

库存口径是所有供应链方案里最容易吵架的地方：现有量、可用量、预留量、在途量，四个词在不同部门嘴里含义不同。最稳的做法是先把现有量和预留量摆出来，可用量用减法算，公式写在方案页上，谁有异议就改公式，而不是改 SQL。

WITH onhand AS ( -- 现有量：明细表按批次/货位存多行，必须聚合 SELECT mohd.organization_id, mohd.inventory_item_id, mohd.subinventory_code, SUM(mohd.transaction_quantity) AS onhand_qty FROM mtl_onhand_quantities_detail mohd WHERE mohd.organization_id = :org_id -- 组织隔离，绝不省略 GROUP BY mohd.organization_id, mohd.inventory_item_id, mohd.subinventory_code ), resv AS ( -- 预留量：已被销售订单或工单占用的部分 SELECT mr.organization_id, mr.inventory_item_id, mr.subinventory_code, SUM(NVL(mr.reservation_quantity, 0)) AS reserved_qty FROM mtl_reservations mr WHERE mr.organization_id = :org_id GROUP BY mr.organization_id, mr.inventory_item_id, mr.subinventory_code ) SELECT msi.segment1 AS item_code, msi.description AS item_desc, o.subinventory_code AS sub_inv, o.onhand_qty, NVL(r.reserved_qty, 0) AS reserved_qty, o.onhand_qty - NVL(r.reserved_qty, 0) AS available_qty FROM onhand o JOIN mtl_system_items_b msi ON msi.inventory_item_id = o.inventory_item_id AND msi.organization_id = o.organization_id LEFT JOIN resv r ON r.inventory_item_id = o.inventory_item_id AND r.organization_id = o.organization_id AND r.subinventory_code = o.subinventory_code WHERE msi.inventory_item_status_code <> 'Inactive' -- 停用物料不进报表 ORDER BY msi.segment1;

几个参数和写法上的点值得说清楚。第一，:org_id用绑定变量，不要拼接字符串，既避免硬解析，也防止跨组织串数据——多组织环境里忘加组织条件，是口径事故的头号原因。第二，MTL_ONHAND_QUANTITIES_DETAIL 是明细粒度，同一个物料在多个货位、多个批次下会有多行，SUM 之前想清楚要不要按批次拆行，如果要拆，把 lot_number 也放进 GROUP BY。第三，MTL_SYSTEM_ITEMS_B 必须用 item_id 加 organization_id 双键关联，只按 item_id 关联会把其他组织的物料描述串过来。第四，如果客户问的「总金额」，就把现有量乘上物料成本，用 NVL 兜住空值再 SUM，别在应用层做，容易因为分页丢行。

3.2 oracle 分页的两套写法：ROWNUM 与 OFFSET FETCH 什么时候用哪个

报表页和大屏页一旦数据量大，必然要做分页。Oracle 分页有两套写法，用错的那套会产生重复行和丢行，而且这种问题在演示现场不容易复现，属于典型的玄学问题。

-- 写法一：12c 及以上，OFFSET / FETCH，语义直观 SELECT order_number, ordered_date, flow_status_code FROM oe_order_headers_all WHERE org_id = :org_id ORDER BY ordered_date DESC, order_number DESC -- 补一个唯一列做 tie-breaker OFFSET :offset ROWS FETCH NEXT :page_size ROWS ONLY; -- 写法二：11g 及以下，必须两层嵌套 -- 内层排序，中层用 ROWNUM 截断，外层再按行号过滤 SELECT * FROM (SELECT t.*, ROWNUM AS rn FROM (SELECT order_number, ordered_date, flow_status_code FROM oe_order_headers_all WHERE org_id = :org_id ORDER BY ordered_date DESC, order_number DESC) t WHERE ROWNUM <= :offset + :page_size) -- 中层截断 WHERE rn > :offset;

关键逻辑在于 ROWNUM 是在排序之前生成的，所以单层WHERE ROWNUM <= 20 ORDER BY xxx取到的是「先随便拿 20 行再排序」，而不是「排序后取前 20 行」。写法二必须两层嵌套，中层截断、外层过滤，顺序不能调换。参数上，:offset从 0 开始，:page_size建议控制在 50 到 200 之间；翻页越深，写法二越慢，因为中层要扫描并丢弃前 offset 行。生产环境里如果要做深翻页，更稳的是记住上一页最后一行的排序键（keyset 分页），在 WHERE 里带上ordered_date < :last_date，这种方式在千万级订单表上差距非常明显。

顺带一个容易踩的坑：如果排序字段有重复值又没有补唯一列，翻页时同一行可能出现在两页，也可能一页都不出现。补上order_number这类唯一列做二级排序，是成本最低的后悔药。另外，如果订单号字段里混着非数字脏数据，做范围过滤前先用正则或者类型校验函数筛一遍，别直接拿字符串比大小，否则报出来的是「无效数字」，运维半夜被叫起来。

3.3 把日报固化成 oracle 存储过程加调度作业

方案里凡是出现「每日库存周转」「日趋势」这类字眼，就不该让前端每次实时聚合。正确做法是建一张快照表，用 oracle 存储过程每天算一次，PPT 上的趋势图直接读快照。这样演示时秒开，生产时也不会因为一个报表把库压垮。

CREATE OR REPLACE PROCEDURE p_refresh_sc_snapshot(p_org_id IN NUMBER) IS -- 供应链日报快照：覆盖当日数据，可重复执行 BEGIN -- 先删当日，保证幂等；生产建议按分区 TRUNCATE DELETE FROM sc_snapshot_daily WHERE org_id = p_org_id AND snap_date = TRUNC(SYSDATE); INSERT INTO sc_snapshot_daily (org_id, snap_date, item_code, onhand_qty) SELECT mohd.organization_id, TRUNC(SYSDATE), -- 统一到日粒度 msi.segment1, SUM(mohd.transaction_quantity) FROM mtl_onhand_quantities_detail mohd JOIN mtl_system_items_b msi ON msi.inventory_item_id = mohd.inventory_item_id AND msi.organization_id = mohd.organization_id WHERE mohd.organization_id = p_org_id GROUP BY mohd.organization_id, msi.segment1; COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; -- 失败不留半截数据 RAISE; END p_refresh_sc_snapshot; /

这里用 TRUNC(SYSDATE) 把时间统一到日粒度，做同比环比时不用再关心时分秒。注意一个真实存在的坑：如果查询条件写成TRUNC(transaction_date) = TRUNC(SYSDATE)，字段上套了函数，索引就用不上了，几千万行的交易表会直接扫全表。正确写法是范围条件transaction_date >= TRUNC(SYSDATE) AND transaction_date < TRUNC(SYSDATE) + 1，既保住了日粒度，又走得动索引。

建好过程之后挂调度作业，定时跑：

BEGIN DBMS_SCHEDULER.create_job( job_name => 'JOB_SC_SNAPSHOT', job_type => 'STORED_PROCEDURE', job_action => 'P_REFRESH_SC_SNAPSHOT', number_of_arguments => 1, start_date => TRUNC(SYSDATE) + 1/24, -- 凌晨一点首次 repeat_interval => 'FREQ=DAILY;BYHOUR=1;BYMINUTE=0', -- 每天一次 enabled => FALSE); DBMS_SCHEDULER.set_job_argument_value('JOB_SC_SNAPSHOT', 1, '85'); -- 组织 ID DBMS_SCHEDULER.enable('JOB_SC_SNAPSHOT'); END; /

参数说明：number_of_arguments必须和过程入参个数严格一致，少一个作业会在运行时才报错，属于典型的「配好了不报错、跑起来才发现」；start_date用TRUNC(SYSDATE) + 1/24表示次日凌晨一点，repeat_interval里的 BYHOUR 决定实际执行点。跑完记得查user_scheduler_job_run_details确认状态，别只看作业是否 enabled。

3.4 erp 库存场景高并发的解决方案：从行锁竞争到分区与绑定变量

供应链方案里最难写的一页，是并发。库存扣减在高峰期会有几十个会话同时更新同一行现有量，直接表现就是enq: TX - row lock contention等待，前端表现为偶尔卡一两秒，用户以为是网络问题。这一页我在方案里一般写三层：结构层、语句层、参数层。

结构层最有效的一招是把「更新现有量」改成「写流水 + 异步汇总」。所有出入库先往流水表 INSERT，现有量由定时任务或准实时汇总更新，INSERT 之间几乎不冲突，热点行自然消失。如果业务不接受异步，那就用任务抢占的方式缓解：

-- 并发拣货：任务表里抢占待处理行，SKIP LOCKED 让会话不互相等锁 SELECT task_id, item_code, qty FROM wms_pick_task WHERE status = 'NEW' AND org_id = :org_id AND ROWNUM <= 20 FOR UPDATE SKIP LOCKED; -- 抢不到就跳过，不排队

FOR UPDATE SKIP LOCKED的语义是：能锁就锁，锁不到直接跳过这一行，不给会话排队的可能。这在任务分派场景里几乎是唯一正确的选择，代价是任务分派顺序不再是严格 FIFO，如果业务要求先到先得，就不能用它。

语句层要盯绑定变量。库存类 SQL 每天执行几十万次，字面量拼 SQL 会让共享池里堆满只差一个数字的硬解析版本，CPU 一度飙上去很难查。用绑定变量是最省事的做法。有些极端场景会考虑把cursor_sharing设成 FORCE 强行共享，但这会造成执行计划漂移，属于不得已才动的手段，动之前必须用 AWR 做前后对比。

参数层主要看三处：UNDO 表空间和undo_retention够不够，长事务回滚段不足会直接报 ORA-01555；redo 日志组数和单组大小是否匹配批量作业，高峰时频繁切换日志会造成 log file switch 等待；以及processes/sessions是否留有余量。表结构上，交易类大表按日期做范围分区、按组织做列表分区，索引建成本地索引，历史数据归档后分区直接 drop，比 DELETE 快得多也干净得多。真要定位瓶颈时，查v$active_session_history按等待事件分组排一下，比凭感觉猜准得多。

4. 从 pptx 到能当场跑数的演示环境：Oracle 19c 单实例搭起来

客户评审会上最有说服力的动作，不是翻页，是打开客户端当场跑一条 SQL，然后指着屏幕说「这就是刚才那页的数字」。要做到这一点，你需要一台可控的演示库。用 Oracle 19c 单实例加一个 PDB 就够了，不需要 RAC，也不需要复杂的高可用配置。

4.1 建库与账号：dbca 静默建库加 PDB 里的业务用户

建库这块用静默方式最省事，也最容易复现。参数按演示机内存调整，别照抄生产配置，8G 内存的机器给了 4G SGA，系统会开始换页，演示时莫名其妙卡顿。

# 静默建库：CDB=ORCL，同时创建一个 PDB=SCMDB dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName ORCL -sid ORCL \ -createAsContainerDatabase true \ -numberOfPDBs 1 -pdbName SCMDB \ -pdbAdminPassword 'Demo#2024' \ -sysPassword 'Demo#2024' -systemPassword 'Demo#2024' \ -characterSet AL32UTF8 \ -totalMemory 3072 \ # 演示机给 3G 够用，别贪大 -emConfiguration NONE \ # 关掉 EM，省内存 -datafileDestination /u01/app/oracle/oradata \ -redoLogFileSize 256 # 批量导入时不容易卡日志切换

建完之后要在 PDB 里建业务用户，注意别在 CDB 根容器里建，否则连接串和权限都会别扭：

-- 切到 PDB 再建用户 ALTER SESSION SET CONTAINER = SCMDB; CREATE USER scdemo IDENTIFIED BY "Demo#2024" DEFAULT TABLESPACE users QUOTA UNLIMITED ON users; GRANT CREATE SESSION, CREATE TABLE, CREATE PROCEDURE, CREATE VIEW, CREATE SEQUENCE TO scdemo; -- 按最小权限给

口令里带特殊字符时，SQL*Plus 里要用双引号包起来，这是新手最常卡住的地方。CREATE SESSION之外，如果你打算在演示里跑存储过程，CREATE PROCEDURE必须显式给，否则编译期就失败。权限只给需要的，演示库也别图省事直接给 DBA。

4.2 plsql 连接 oracle 配置：服务名、SID 和两个容易漏的文件

客户端连不上，九成问题出在服务名和 SID 混用。19c 多租户环境下，客户端要连的是 PDB 的服务名，不是 CDB 的 SID。tnsnames.ora 里写清楚：

SCMDB_DEMO = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.0.0.21)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = scmdb) # 19c 连 PDB 用服务名，不是 SID ) )

两个容易漏的文件：一是服务器端listener.ora里要注册 PDB 的服务，lsnrctl status能看到scmdb这个服务才算注册成功；二是客户端sqlnet.ora里的NAMES.DIRECTORY_PATH，如果目录路径里没有TNSNAMES，客户端会绕过 tnsnames.ora 直接失败。改完文件不用重启数据库，lsnrctl reload就够了。演示前一定在演示机上用 PL/SQL Developer 或同类客户端实连一次，不要只在自己电脑上试过就算完。

4.3 造一批像样的供应链演示数据

演示数据最怕两件事：物料太少看不出趋势，数据太真泄露客户信息。我一般用层级查询造一批编码规整的假数据，物料编码用DEMO-0001这种格式，供应商统一V001到V020。

-- 造 200 个物料主数据，编码规整，便于演示时口头引用 INSERT INTO mtl_system_items_b (inventory_item_id, organization_id, segment1, description, primary_uom_code, inventory_item_status_code) SELECT 900000 + LEVEL, 85, 'DEMO-' || LPAD(LEVEL, 4, '0'), '演示物料 ' || LEVEL, CASE WHEN MOD(LEVEL, 3) = 0 THEN 'KG' ELSE 'EA' END, 'Active' FROM dual CONNECT BY LEVEL <= 200; COMMIT;

CONNECT BY LEVEL <= n是 Oracle 造数最顺手的写法，比写循环快得多，也不需要 PL/SQL 块。插入前把inventory_item_id起在一个高位区间（这里用 90 万起），避免和真实数据的主键区间重叠，演示环境导入生产数据时不会撞键。UOM 用 CASE 做出两种单位，演示单位换算时才有东西可讲。

4.4 演示编排：18 分钟怎么切页，哪里必须现场跑 SQL

时间分配上我会这么切：前三分钟讲现状痛点，用两张截图说明问题在哪，不讲模块；三到六分钟给目标蓝图一页，只讲一条业务链；六到十一分钟切到关键流程跑数，这是全场重心，库存可用量、未交订单、日报快照各跑一条；十一到十五分钟讲并发与性能，展示等待事件截图或者慢 SQL 的执行计划；最后三分钟讲实施节奏和风险。全程不超过十八分钟，留十分钟给提问。

必须现场跑的只有三条 SQL，其他的都用截图。原因很简单：现场跑得越多，出错的概率越大，一条 SQL 卡三秒，气氛就散了。挑出来的这三条要提前在演示机上跑过至少十遍，并且准备好一个「数据看起来不太对劲」的备用脚本。我的习惯是在桌面上放两个 SQL 文件，一个正常，一个备用，现场切文件比现场改 SQL 靠谱得多。

5. 避坑与排查：这套方案演示最容易翻车的 5 个现场

以下五条都是从现场捡回来的，每条按现象、原因、解决写，能提前处理的都提前处理。

5.1 oracle 监听服务无法启动，客户端全体连不上

现象：演示机重启后客户端全部报连接失败，服务器上执行lsnrctl start报 TNS 类错误，或者看起来启动了但状态里没有实例信息。原因通常是三类：主机名或 IP 变过，而 listener.ora 里写的是旧地址；服务器 hosts 文件的解析顺序被改过，主机名解析到了错误地址；或者 1521 端口被别的进程占用。解决顺序是先lsnrctl status看服务注册情况，再确认端口占用，然后检查 listener.ora 里 HOST 字段是不是写成了主机名而不是写死 IP。写主机名加 hosts 固定解析，比写 IP 更稳，换网络环境时不用改配置。

5.2 演示前一夜 oracle dbf 文件坏了

现象：第二天早上打开库报 ORA-01157 或查询某张表报块损坏，事务日志里能看到坏块提示。原因多半是演示机非正常关机、虚拟机磁盘掉过，或者复制库文件时没停库导致文件不一致。这类问题没有速成解法，唯一的后悔药是备份。我的做法是演示库建好、数据灌完之后立刻做一次全库备份，并在演示前两小时做一次恢复演练——不是真恢复，是把命令走一遍确认能跑通。如果已经坏了且没有备份，就别硬救，直接用模板重建库重灌数据，二十分钟的事，比修数据快。

5.3 口径不一致：pptx 里的数和系统里对不上

现象：方案页上写库存周转 45 天，客户在自己的系统里一查是 62 天，现场气氛瞬间微妙。原因基本是四件事：组织范围不同（一个含在途组织，一个不含）；时间截点不同（一个是月末一个是实时）；单位换算不同（KG 和吨）；在途是否计入可用量。解决办法是给每个数字配一份口径字典：组织范围、时间截点、单位、公式、取数脚本编号、取数日期，一共六项。数字下面用小字标注脚本编号，客户追问就当场打开脚本。这件事做在前面是专业，做在后面是救火。

5.4 报表一查就全表扫描，页面转圈

现象：单表查询很快，一把条件加上去就慢，或者换个月份查就慢十倍。原因通常是字段上套了函数导致索引失效，比如TRUNC(transaction_date)或者TO_CHAR(transaction_date)这种写法；也可能是统计信息过期，优化器选错了执行计划；大表没分区，数据量一上来全表扫描无法避免。解决是先看执行计划确认是不是全表扫，再把条件改写成范围形式，然后检查索引和统计信息。历史数据量大的交易表，尽早规划分区，本地索引配合分区裁剪，效果比加任何提示都实在。

5.5 截图上带着真实供应商与价格

现象：演示到一半，有人发现截图里的供应商名字和采购价格是真实的，会后被追问数据来源。原因很简单，直接从生产库截的图。这类问题不涉及技术，但影响很坏。解决方式是演示环境统一使用脱敏数据，供应商编码化、价格加扰动系数，截图统一从演示环境重新截一遍。每次方案版本更新，都要重新过一遍所有截图，别复用上一版的图——上一版合规，不代表这一版引用的数据合规。

6. 让这份方案真落地的两个习惯：口径字典与可复现取数清单

我做了这些年方案，最有用的一页 pptx 其实不是架构图，是一张附录页，叫「口径字典」。它长这样：数字名称、组织范围、时间截点、单位、计算口径、对应脚本、取数日期，七列。放在附件里不占篇幅，但整套方案的可信度全靠它撑着。

另一件事是「可复现取数清单」。每做完一版方案，我会把所有用到的 SQL 存成一个目录，文件名按 pptx 页码编号，脚本头部写清楚用途、口径、参数和预期行数量级。好处有两个：客户质疑时能当场跑；方案改版时只需要重跑脚本，而不是重新想一遍逻辑。这个习惯看着笨，但它把「方案」和「数据」绑在一起了，方案不再是漂亮的空壳。

最后一个血泪经验：演示库和生产库要严格分开，演示脚本里所有的组织 ID、物料 ID 都写成变量，别写死。我见过有人把演示脚本带到客户环境直接执行，因为没有绑定变量，把另一个组织的库存刷成了负数，收尾花了整整两天。演示用的东西，永远只当演示用。希望帮到你。

本文还有配套的精品资源，点击获取