徐万新之路EBS里的Concurrent Manager 实际上也是一个request 的程序，而且如果request define的类型是immediately的类型的话，一定要运行在mamnger中，这个是因为immediately类型的程序需要调用特定的库来执行的。interface manager里的程序就是其中的典型，因为他们都需要调用一个INVLIBR的库。
在interface manager里面有四个request：
１．Cost Manager这个是导入WIP_COST_TXN_INTERFACE中的数据的，如果这个manager的状态为inactive的话：可以手工提交：Cost Manager这个concurrent。
２．Lot Move Transaction对应的接口不是很清楚，估计是MTL_TRANSACTION_LOTS_INTERFACE，对应的concurrent是：Manager: Lot Move Transactions
３．Material transaction这个就相当的重要了，对应的接口是MTL_TRANSACTIONS_INTERFACE对应的concurrent是：Manager: Process transaction interface
４．Move transaction对应的接口是：WIP_MOVE_TXN_INTERFACE对应的concurrent是：WIP Move Transaction Manager
这四个程序都是处理transactions用的，可以把manager激活，定时的运行，也可以手工的提交。
这个interface manager对应的manager的name是：Inventory Manager.可以在system administrator下的manager的define中详细查看里面的定义的程序的情况。
一、先纠正一个概念精度：Concurrent Manager 本身是 request
对。包括 Internal Concurrent Manager（ICM，执行文件 FNDLIBR） 在内，所有并发管理器本身也都是运行在 ICM 之下的特殊并发程序。ICM 负责监控、启停其他 manager，并把请求分发给对应管理器。
二、”Immediately 类型必须跑在 manager 里”—— 方向对，但因果要修正
并发程序定义里，Execution Method 有 Concurrent 和 Immediate 两种：
表格
| 执行方式 | 机制 |
|---|---|
| Concurrent | 请求进标准队列，由匹配的并发管理器按 workload 轮询拾取 |
| Immediate | 提交后由 Internal Concurrent Manager 同步立即执行，不排队 |
INV 这四个接口程序被定义为 Immediate，本质是因为它们是 Inventory Interface Manager 主循环的组成部分，必须跟着接口管理器一起调度，而不是 “因为要调 INVLIBR 库所以必须如此”。反过来理解才对：它们天生处理库存事务、编译链接了库存事务处理引擎（INVLIBR 等底层库），所以被定位成 Immediate、走接口管理器方式执行 ——Immediate 是定位的结果，不是原因。
三、四个程序精确对照（名称 + 短码 + 接口表）
表格
| 并发程序 | 执行文件（短码） | 接口表 | 处理内容 |
|---|---|---|---|
| Cost Manager | COST | WIP_COST_TXN_INTERFACE | WIP 成本事务（装配完工、外协、组件反冲等） |
| Manager: Lot Move Transactions | LOTMOVE | MTL_TRANSACTION_LOTS_INTERFACE | 批次（Lot）移动、批次号明细 |
| Manager: Process Transaction Interface | INVCMGR | MTL_TRANSACTIONS_INTERFACE | 最核心：普通库存收发移转事务总入口 |
| WIP Move Transaction Manager | WINCMGR | WIP_MOVE_TXN_INTERFACE | 车间工序移动、完工事务 |
你那四条对应关系完全正确，尤其是你拿不准的 Lot Move—— 确实是 MTL_TRANSACTION_LOTS_INTERFACE，对应程序 Manager: Lot Move Transactions。
四、Inventory Interface Manager
- Manager 名：Inventory Manager（内部短名 INVCMGR）
- 查看路径：System Administrator → Concurrent → Manager → Define，展开定义即可看到它下面关联的这四个程序
- 运行机制：manager active 时按你配置的 work shift / 频次定时轮询接口表，把接口行批量取出 → 校验 → 调用库存事务处理逻辑 → 写入正式事务表；inactive 时接口数据就堆积不处理
五、运维要点（结合生产场景）
- 判断是否堆积：直接看接口表行数
SELECT COUNT(*) FROM MTL_TRANSACTIONS_INTERFACE;若堆积且ERROR_EXPLANATION有值，先查校验失败原因，别急着手工重跑。 - manager inactive 想手工消化：Navigator → Requests → Run，选对应程序（如 Process Transaction Interface / Cost Manager）提交即可，处理逻辑与 manager 定时跑一致。
- 易踩的坑：这几个程序处理的是同一批接口表。如果存在未清理的错误接口行，手工重跑会重复报同样错误—— 所以先清错误行或确认失败原因，再手工提交。
让这四个程序 “自动启动”，关键要先纠正一个认知：它们不是靠 “提交 request” 来自动跑的，而是靠 Inventory Manager 这个并发管理器持续轮询接口表来触发的。所以你要做的不是配置这四条 request，而是把它们的宿主 Manager 激活并配置好。下面讲清楚机制和操作。
一、底层机制：为什么是激活 Manager 而不是配 request
这四个程序（COST / LOTMOVE / INVCMGR / WINCMGR）是 Inventory Interface Manager（Inventory Manager, 内部名 INVCMGR）主循环的组成部分。它们属于 “特殊类型” 的并发管理器，不是普通队列型并发程序。
它的工作方式：
Inventory Manager 进程激活
└─> 按 Work Shift 周期轮询
└─> 扫描四个接口表是否有未处理行
├─ MTL_TRANSACTIONS_INTERFACE (INVCMGR)
├─ WIP_MOVE_TXN_INTERFACE (WINCMGR)
├─ WIP_COST_TXN_INTERFACE (COST)
└─ MTL_TRANSACTION_LOTS_INTERFACE (LOTMOVE)
└─ 有数据 → 自动取出 → 校验 → 写入正式事务表
└─ 无数据 → 休眠，下一周期再轮询
所以 “自动启动”= Manager 处于 Active + 配置了可用的 Work Shift + 接口表有数据。数据一来它自动处理，无需逐条提交 request。
二、让四个程序自动运行的完整配置步骤
1. 激活 Inventory Manager
路径：System Administrator → Concurrent → Manager → Define
- Query 出 Inventory Manager（INVCMGR）
- 把 Status 设为 Active（Active / Inactive 二选一）
- 确认该 Manager 下方 Programs 区块已包含这四个程序：
- Cost Manager（COST）
- Manager: Lot Move Transactions（LOTMOVE）
- Manager: Process Transaction Interface（INVCMGR）
- WIP Move Transaction Manager（WINCMGR）
2. 配置 Work Shift（最容易漏的一步）
每个 Manager 必须至少关联一个激活的 Work Shift，否则进程不会跑，即使 Status 是 Active。
- 在 Manager 定义窗口的 Work Shifts 区块
- 勾选激活一个可用的 Shift（默认通常有 Standard，24 小时全天）
- 若你需要限定时间段（如只在 8:00–20:00 处理），就在这里配 Work Shift 时间窗
3. 重启 Manager 使改动生效
改 Status 或 Shift 后，必须重启 manager 进程才生效：
- 路径：
System Administrator → Concurrent → Manager → Administer - 选中 Inventory Manager
- 点 Restart（或先 Stop 再 Start）
4. 验证是否已在自动运行
- 回到
Administer页面，看 Inventory Manager 的当前进程状态应为 Running / Sleeping（而非 “No process”） - 或直接往接口表插一条测试数据（如
INSERT INTO MTL_TRANSACTIONS_INTERFACE(...)），观察请求是否被自动拾取处理
三、排错速查（自动跑不起来的常见原因）
表格
| 症状 | 原因 | 处理 |
|---|---|---|
| Manager 状态 Active 但进程没起来 | 未关联 Work Shift 或 Shift 时间窗不覆盖当前时间 | 激活 Shift 或调整时间窗后重启 |
| 改了配置不生效 | 没重启 manager 进程 | Administer → Restart |
| Manager 起来了但接口不处理 | 接口表无数据 / 数据校验失败卡住 | 查接口表行数及 ERROR_EXPLANATION |
| 四个程序不全 | Manager 的 Programs 区块漏关联 | 在 Define 里补勾选后重启 |
四、一个补充提醒
- 接口表有错误行会阻塞后续处理：比如
MTL_TRANSACTIONS_INTERFACE里某行校验失败（有ERROR_EXPLANATION），Manager 会反复尝试或跳过，造成堆积。自动运行前建议先清理错误行。 - Manager inactive 时的兜底：如果暂时不想开 Manager，也可以手工提交这四个 request（Requests → Run 选对应程序）消化接口数据 —— 但你问的 “自动” 场景，本质就是保持 Inventory Manager 常驻轮询。
