1. 委外采购订单到底特殊在哪先搞清楚底层逻辑做SAP接口开发的同事十有八九会遇到这样一个需求上游OA或MES系统推过来一条委外加工指令需要在SAP里自动生成一张委外采购订单。手工在ME21N里创建不难难的是用BAPI把它拼出来——因为委外采购订单和普通采购订单在数据结构上有一道明显的分水岭项目类别L 特殊库存O 组件行这三个东西不配齐你的BAPI跑出来就只能靠报错认得你。先说清楚业务场景。委外加工简单说就是企业把原材料发给供应商供应商加工成半成品或成品再送回来企业付的是加工费而不是材料费。在SAP里这张采购订单的成品行是主行原材料不是独立挂在单独的行项目里而是作为主行下面的“组件”排列在采购订单的组件页签里。采购订单保存后系统会要求物料凭证先做一步“发料给供应商”供应商完工后再做采购订单收货这时候系统一边收成品入库一边自动做组件的消耗过账。搞清楚了业务流转再看SAP里的三个关键标识就一点都不难理解了。1.1 委外PO在SAP里的三个关键标识第一个标识是项目类别PSTYP设置为“L”。普通采购订单项目类别是“标准”NB或“寄售”K而委外加工是“L”在ME21N里当你在项目类别下拉框里选了L系统会立刻把很多字段的输入状态改掉不需要填“工厂”错工厂还是要填需要额外指定特殊库存类型组件页签从灰置变成可编辑。这个字段在BAPI_PO_CREATE1的参数里叫做PO_ITEM-ITEM_CAT。第二个是特殊库存类型SOBKZ设置为“O”。O代表“供应商提供的库存”inventory at vendor在物料凭证里也叫“Vendor Subcontracting Stock”。很多人第一次写BAPI时只记得ITEM_CATL忘记SPEC_STOCK_TYPEO运行完系统抛出一条消息“请输入特殊库存类型”。这个字段在BAPI里对应PO_ITEM-SPEC_STOCK_TYPE必须显式传O。第三个是组件行。这一步在BAPI里藏得最深——标准参数里没有直接的组件传入结构必须借助扩展传入机制EXTENSIONIN把组件物料、组件数量、单位等数据塞进一张名为BAPI_TE_MEPOITEMCOMPONENT的扩展结构里。组件行在表结构层面也不是放在子表里而是直接放在EKPO表的新增行里行项目号按顺序排下来比如主行00010、组件行00011、00012组件行上会有“委外组件”的标识字段保存后你在ME23N里打开组件页签就能看到它们。1.2 创建委外PO的前置条件检查在动手写代码之前有几个前置条件最好先确认一遍否则接口上线后天天被用户投诉供应商主数据已经维护采购组织视图和公司代码视图完整。委外加工价格一般是加工费供应商的采购组织视图必须有不然报错方向五花八门。成品物料和组件物料都有工厂视图。委外PO里成品行要填工厂组件行也是跟着这个工厂走的物料主数据缺了工厂视图连ME21N都保存不了。采购信息记录如果存在最好是“委外加工”类别的信息记录。价格字段可以手工传值绕开但税分类、交期等默认值往往需要信息记录支撑。组件物料是否启用“批次管理”“序列号管理”等特殊属性这会直接影响组件行是否要额外传批次字段。这些检查做完才能进入BAPI的参数拼装环节。2. BAPI_PO_CREATE1的参数骨架从上到下逐个说清楚BAPI_PO_CREATE1是SAP对外提供的标准采购订单创建BAPI老一点的同事喜欢用BAPI_PO_CREATE但那个版本没有扩展字段也不支持一些后来增加的采购字段新开发我强烈建议直接上BAPI_PO_CREATE1。它支持抬头、项目、计划行、账户分配、扩展传入、测试运行功能足以覆盖委外采购订单99%的场景。2.1 抬头数据必填项和容易忽略的字段先看抬头部分。至少这些字段要传满字段参数名值说明凭证类型PO_HEADER-DOC_TYPENB标准采购订单供应商PO_HEADER-VENDOR供应商编码必须存在且有效采购组织PO_HEADER-PURCH_ORG采购组织需要供应商视图采购组PO_HEADER-PUR_GROUP采购组必填公司代码PO_HEADER-COMP_CODE公司代码必填语言PO_HEADER-LANGUAGEsy-langu建议传当前登录语言抬头对应的更新标记结构是PO_HEADERX里面DOC_TYPE、VENDOR、PURCH_ORG、PUR_GROUP、COMP_CODE、LANGUAGE全部置X。更新标记的作用是告诉BAPI“这些字段我要更新”不置X的字段即使有值也可能被忽略。委外订单不涉及供应商子工厂这些库存转储字段抬头部分到这里就够。但有一个容易被忽略的字段PO_HEADER-PURCH_DATE订单日期。如果没传系统会取当前日期问题不大如果上游要求按某个业务日期记账这个字段要显式传。另一个是付款条件PAYMENT_TERMS一般从供应商主数据带出来不传也说得通。2.2 项目数据委外字段和容易漏的细节项目部分是整张委外采购订单的核心字段多且不能少PO_ITEM-PO_ITEM行项目号建议从10开始递增因为组件行会自动排在后面留出余量。主行10、组件11、12这样逻辑清楚。PO_ITEM-MATERIAL成品物料号。这里注意委外PO的物料可以是成品也可以是半成品看你的业务定义。PO_ITEM-PLANT工厂必填。PO_ITEM-ITEM_CAT必填L。PO_ITEM-SPEC_STOCK_TYPE必填O。PO_ITEM-QUANTITY采购数量也就是委外成品的数量。单位是PO单位。PO_ITEM-PO_UNIT采购单位。如果和物料基本单位不一致系统会自动做转换但建议传一致。PO_ITEM-NET_PRICE加工费净价。如果传了采购信息记录并置INFO_UPX价格可以自动带出否则手工传最稳。PO_ITEM-PRICE_UNIT价格单位。默认是1意思是每1个单位的加工费是多少钱。PO_ITEM-CURRENCY货币码。这里有个很容易漏的地方PO_ITEMX更新标记里除了MATERIAL、PLANT、QUANTITY、NET_PRICE这些常规字段ITEM_CAT和SPEC_STOCK_TYPE必须明确置X否则系统可能不认为是新增“委外项目”后面组件行创建也会因为没有参照的项目类别而报错。你们可以想象一下ITEM_CAT没被更新时系统实际拿到的项目还是“标准普通采购项目”但SPEC_STOCK_TYPE又被设置成了O这种组合本身就自相矛盾报错根本不奇怪。项目里还有一个字段值得一提OVER_DLV_TOL过量交货容差和UNDER_DLV_TOL不足交货容差根据物料主数据或采购信息记录默认可带出接口场景建议按业务规则明确传值否则后续收货时容差校验可能飘。2.3 计划行和账户分配的处理计划行在BAPI里对应PO_SCHEDULE和PO_SCHEDULEX。委外采购订单至少要有一行计划行否则系统找不到交货日期严肃一点的系统直接报错不让保存。字段参数名值行项目PO_SCHEDULE-PO_ITEM00010交货日期PO_SCHEDULE-DELIV_DATE日期 YYYYMMDD数量PO_SCHEDULE-QUANTITY采购数量注意计划行的数量总和要和项目行的QUANTITY一致。如果项目100件计划行拆成两行5050也可以系统允许。PO_SCHEDULEX对应更新标记DELIV_DATE和QUANTITY置X。账户分配这块委外PO绝大多数走普通库存管理收货后是“无科目分配”的自由库存PO_ACCOUNT可以完全不传。只有当项目行设置了科目分配类别比如ACCTASSCTK成本中心才需要额外传PO_ACCOUNT。为减少麻烦正常委外业务建议不设科目分配类别把账走清楚。2.4 更新标记X结构的使用逻辑BAPI_PO_CREATE1的X结构是个非常容易栽跟头的地方。每个主表结构都配一个X结构例如PO_HEADERX对应PO_HEADERPO_ITEMX对应PO_ITEMPO_SCHEDULEX对应PO_SCHEDULE。X结构字段里传X表示“这个字段的值我要保留”不传X表示“这个字段不用关注”。实际操作时最容易犯的错是把X结构整个漏掉或者只建了表没填充内容。系统会按照“未被标记的字段不更新”的逻辑处理直接后果就是你的ITEM_CAT、SPEC_STOCK_TYPE、QUANTITY等关键字段全部变成了空值。如果代码里没有对RETURN消息做严格检查这批脏数据就会直接落库。所以我的习惯是主表里我填了哪个业务字段X结构里就务必要有一个对应的X。3. 组件数据怎么塞进采购订单扩展结构实战现在到了最关键的部分。BAPI_PO_CREATE1的标准参数定义里明明没有组件相关的TABLE参数那组件数据怎么传这是很多刚接触委外PO开发的同事卡住最多的地方。3.1 为什么标准参数里没有组件SAP在设计BAPI_PO_CREATE1的时候组件数据并不是每个场景都要用所以没有放进标准参数而是留了一个名为EXTENSIONIN的通用扩展入口。这个入口专门用于传递标准的“扩展结构”也就是SAP定义好的、但不挂在BAPI标准签名下的业务数据。BAPI_TE_MEPOITEMCOMPONENT就是这样一个结构专门用于向采购订单项目传递组件数据。EXTENSIONIN里的每一行由两个字段组成STRUCTURE结构名称和VALUEPART结构内容。你看这个设计本质上就是“把一块结构体的值放到一个长字符串里SAP函数内部再按对应的结构名称去解析”所以传值时结构名称必须和内容严格对应不能张冠李戴。3.2 用EXTENSIONIN BAPI_TE_MEPOITEMCOMPONENT传组件的写法BAPI_TE_MEPOITEMCOMPONENT这个扩展结构常见的可用字段有PO_ITEM组件所属的主行项目号对应采购订单主行项目。COMPONENT组件物料号。COMP_QTY组件数量。COMP_UOM组件单位。ITEM_CAT组件行的项目类别委外场景一般系统自动填充非必传。MOVE_TYPE移动类型委外场景通常不传由后台自动确定。关键点在于如果你传了多个组件比如一个成品需要两种原材料那就构造两行EXTENSIONIN每行的STRUCTURE都是BAPI_TE_MEPOITEMCOMPONENTVALUEPART分别填不同组件的结构值。这里补充一点有的项目会看到有人用BAPI_TE_MEPOCOMPONENT少一个ITEM这个结构也能传组件但它更偏向组件行和计划行绑定关系的场景我实测下来用BAPI_TE_MEPOITEMCOMPONENT在主行创建场景下更稳。如果各位在S4版本里发现某个字段传不进去可以两个结构都试一下以系统实际解析结果为准。3.3 完整ABAP代码示例创建委外PO并携带组件下面给一段可以直接抄走的ABAP代码框架。代码的结构是先拼抬头和项目再拼计划行然后用循环把组件集合处理成EXTENSIONIN表最后调用BAPI_PO_CREATE1并做提交或回滚。DATA: ls_poheader TYPE bapi_mepo_header, ls_poheaderx TYPE bapi_mepo_headerx, lt_poitem TYPE TABLE OF bapi_mepo_item, ls_poitem TYPE bapi_mepo_item, lt_poitemx TYPE TABLE OF bapi_mepo_itemx, ls_poitemx TYPE bapi_mepo_itemx, lt_poschedule TYPE TABLE OF bapi_mepo_schedule, ls_poschedule TYPE bapi_mepo_schedule, lt_poschedulex TYPE TABLE OF bapi_mepo_schedulex, ls_poschedulex TYPE bapi_mepo_schedulex, lt_extensionin TYPE TABLE OF bapiparex, ls_extensionin TYPE bapiparex, ls_itemcomp TYPE bapi_te_mepoitemcomponent, lt_return TYPE TABLE OF bapiret2, ls_return TYPE bapiret2, lv_ebeln TYPE bapimepoheader-po_number, lv_subrc TYPE sysubrc. * 1. 抬头数据 ls_poheader-doc_type NB. ls_poheader-vendor lv_vendor. ls_poheader-purch_org lv_purch_org. ls_poheader-pur_group lv_pur_group. ls_poheader-comp_code lv_comp_code. ls_poheader-language sy-langu. ls_poheaderx-doc_type X. ls_poheaderx-vendor X. ls_poheaderx-purch_org X. ls_poheaderx-pur_group X. ls_poheaderx-comp_code X. * 2. 项目数据 - 委外主行 ls_poitem-po_item 00010. ls_poitem-material lv_fg_material. 成品物料 ls_poitem-plant lv_plant. ls_poitem-item_cat L. 委外加工 ls_poitem-spec_stock_type O. 供应商特殊库存 ls_poitem-quantity lv_total_qty. ls_poitem-po_unit lv_uom. ls_poitem-net_price lv_processing_fee. 加工费 ls_poitem-price_unit 1. ls_poitem-currency lv_currency. APPEND ls_poitem TO lt_poitem. ls_poitemx-po_item 00010. ls_poitemx-material X. ls_poitemx-plant X. ls_poitemx-item_cat X. ls_poitemx-spec_stock_type X. ls_poitemx-quantity X. ls_poitemx-po_unit X. ls_poitemx-net_price X. ls_poitemx-price_unit X. ls_poitemx-currency X. APPEND ls_poitemx TO lt_poitemx. * 3. 计划行 ls_poschedule-po_item 00010. ls_poschedule-deliv_date lv_delivery_date. ls_poschedule-quantity lv_total_qty. APPEND ls_poschedule TO lt_poschedule. ls_poschedulex-po_item 00010. ls_poschedulex-deliv_date X. ls_poschedulex-quantity X. APPEND ls_poschedulex TO lt_poschedulex. * 4. 组件数据 - 通过扩展结构传入 LOOP AT lt_components INTO DATA(ls_comp). CLEAR: ls_itemcomp, ls_extensionin. ls_itemcomp-po_item 00010. ls_itemcomp-component ls_comp-material. ls_itemcomp-comp_qty ls_comp-quantity. ls_itemcomp-comp_uom ls_comp-uom. ls_extensionin-structure BAPI_TE_MEPOITEMCOMPONENT. ls_extensionin-valuepart ls_itemcomp. APPEND ls_extensionin TO lt_extensionin. ENDLOOP. * 5. 调用BAPI CALL FUNCTION BAPI_PO_CREATE1 EXPORTING poheader ls_poheader poheaderx ls_poheaderx testrun lv_testrun IMPORTING exppurchaseorder lv_ebeln TABLES return lt_return poitem lt_poitem poitemx lt_poitemx poschedule lt_poschedule poschedulex lt_poschedulex extensionin lt_extensionin. * 6. 结果处理 READ TABLE lt_return WITH KEY type E TRANSPORTING NO FIELDS. IF sy-subrc 0. LOOP AT lt_return INTO ls_return WHERE type CA EA. WRITE: / ls_return-message. ENDLOOP. CALL FUNCTION BAPI_TRANSACTION_ROLLBACK. EXIT. ENDIF. CALL FUNCTION BAPI_TRANSACTION_COMMIT. WRITE: / 委外采购订单创建成功:, lv_ebeln.注意TESTRUN参数。调试时建议传lv_testrunX这样BAPI只检查不保存所有报错都能原样返回方便循环修改。等全部消息干净了再把TESTRUN置空走真实保存。3.4 组件创建成功怎么验证BAPI返回成功的同时组件行可能并没有如愿写入。如果你只检查RETURN表没有E然后就直接提交很可能会白山一梦——订单建出来了组件页签却是空的。稳妥做法是保存后立刻用BAPI_PO_GETDETAIL或者直接读表来验证组件行。验证逻辑很简单按采购订单号读取EKPO筛出KZTLF等于1的行委外组件标识或者按组件属性检查该PO下是否存在多于一个的项目行。组件行的项目号比主行大数量按BOM逻辑可能不等于成品数量。确认组件行存在后再走业务提交。这一步不要省。我接手过一个别人写的接口上线跑了一个月才发现组件根本没写进采购订单导致仓库发货环节全面异常排查成本非常高。4. 实测中踩过的坑和排查思路写代码时一切顺利上了测试环境就各种报错这是做BAPI开发的家常便饭。下面把委外采购订单创建过程中最容易踩的坑按出现频次整理出来每一步都附带排查思路。4.1 项目类别L和特殊库存O不匹配的各种报错场景一只传了ITEM_CATL没传SPEC_STOCK_TYPEO。系统报错“请输入特殊库存类型”有些版本报ME164。这个错很直白就是字段缺失。排查时先检查PO_ITEMX里SPEC_STOCK_TYPE是否也置了X有时候你明明填了SPEC_STOCK_TYPE但X结构没置位系统等于没收到。场景二SPEC_STOCK_TYPE传成了K寄售或Q项目这属于业务概念混淆。委外加工的供应商库存在SAP里就是O寄售是供应商把货放在你的仓库、卖出去才结账和委外是两码事。排查这类问题最好的办法就是打开ME21N手工创建一个同样物料、同样供应商的委外PO然后对比系统里自动生成的数据字段差异一目了然。场景三项目类别L时系统要求“工厂必须启用批次管理”或“物料必须启用批次确定性”之类这类和物料主数据强相关。对策是先检查物料主数据MRP视图/工厂数据确认没有特殊限制必要时让业务顾问在后台做相应配置。4.2 组件数量校验和BOM展开的坑委外PO的组件数量不是随便填的系统有一套数量校验逻辑。最直接的报错是组件数量合计与主行数量按BOM用量换算后不匹配。比如BOM要求一个成品耗用2个原材料你主行10件、组件数量却传了10系统不会拦你因为组件行本身不强制校验。但后续收货时系统按完工数量10件去自动扣20个组件消耗供应商库里却只有10个那时候报错才叫酸爽。也就是说组件数量尽量按BOM用量传不要心存侥幸。如果上游ERP确实只能提供成品数那么建议在接口里做一个“组件数量 成品数量 × 组件用量”的换算逻辑这个换算比例从BOM里读取或者由业务配置好了传进来。另一个常见的坑是物料主数据里配置了“相关需求”或系统启用了BOM自动展开创建委外PO时SAP会尝试自动从BOM展开组件行。如果你同时在EXTENSIONIN里传了组件可能造成组件行重复——系统展开一份你又传了一份。实际项目里我建议二选一要么完全依赖BOM展开前提是BOM准确、接口不覆盖数量要么完全手工传组件扩展结构传值不要在同一个行上两个机制混用。判断标准很简单你的上游能不能拿到准确到“每个组件数量”的数据能就传扩展结构不能就配置好BOM依赖系统展开但接口里要预留读取组件行是否成功的检查逻辑。4.3 更新标记和字段缺失导致的静默失败比报错更可怕的是“不报错但数据不对”。有一类问题在委外PO创建中特别隐蔽采购订单创建成功但组件行全是空的或者关键字段丢失BAPI却一个E类消息都没有。排查的第一优先对象永远是X结构。先检查PO_ITEMX的ITEM_CAT和SPEC_STOCK_TYPE是不是真的传了X。再检查EXTENSIONIN里的BAPI_TE_MEPOITEMCOMPONENT是不是被正确拼装尤其注意VALUEPART直接赋值时可能出现的长度截断如果结构里的COMP_QTY位置偏移了系统解析出来就是零或垃圾值。排查手段用BAPI_PO_GETDETAIL回读采购订单项目数据把回读的内容逐字段和你传入的输入做对比或者直接在DEBUG模式里单步跟踪BAPI内部看看扩展结构解析成了什么。时间久了你会发现BAPI的“静默失败”往往不是BAPI本身的问题而是调用者没把更新标记当回事。4.4 调试技巧TESTRUN和三段式检查法我调试委外PO创建逻辑时习惯用一个三段式检查法几乎能定位九成问题第一段接口前参数自检。在调用BAPI之前把所有要传的表和结构的数据打印出来或写进日志看抬头、项目、计划行、扩展结构是否完整。这一步能拦截掉大多数“我明明传了”的错觉。第二段BAPI调用加TESTRUNX把所有RETURN消息按类型分组展示。注意S类型消息也可能隐藏业务提示比如“物料没有价格”“信息记录不存在”这种只是不阻止保存但会影响后续结算。养成习惯把W类型消息也捞出来看能间接发现很多潜在问题。第三段提交前检查。在BAPI_TRANSACTION_COMMIT之前再用BAPI_PO_GETDETAIL回读一次确认组件行已经真实存在于EKPO里。这一步做完才算真正创建成功。5. 这些扩展场景和替代方案也值得了解5.1 有BOM要不要展开后台配置和实际取舍有些项目确实可以依赖系统自动BOM展开。在ME21N创建委外PO时如果物料有BOM系统会在保存前问你是否要把BOM组件带入采购订单这就是所谓的“BOM展开”。BAPI_PO_CREATE1里能否自动展开BOM取决于配置和物料主数据。如果你决定用BOM展开需要重点确认两点一是物料主数据MRP视图的“BOM展开”字段比如展开编号BOMEXPL要配置成合适的值二是后台自定义的委外加工BOM展开规则。这里的坑在于BOM展开的时机在项目创建时未必触发有的系统版本要到保存时才展开BAPI返回成功但组件行是空的很容易误判。所以我的实际建议是对于接口集成场景优先选择在接口里显式传递组件数据而不是依赖BOM展开。原因很简单接口要的是确定性BOM展开依赖后台配置和版本行为不可控因素太多。BOM可以使用BAPI或者函数读取上游计算出准确的组件用量再传进来至少省掉排查“为什么组件没展开”的时间。5.2 替代方案对比BDC录屏 vs BAPI vs S/4新API除了BAPI_PO_CREATE1市场上还有几种创建委外PO的做法方案优点缺点BDC录屏ME21N能模拟一切手工操作字段无死角屏幕版本变了就挂维护成本高大量测试开销BAPI_PO_CREATE1标准、稳健、扩展机制完善学习成本高组件要扩展结构字段过多时容易漏S/4HANA OData API (API_PURCHASEORDER_PROCESS_SRV)云端和API优先方向JSON接口友好传统ECC用不了且字段覆盖度和BAPI仍有差距BDC录屏看起来“万能”但本质上绑定的是当前系统的屏幕布局系统升级或者界面版本调整后录屏脚本可能直接失效。线上接口为了这个背锅不值得。BAPI_PO_CREATE1是SAP对外声明稳定的接口ECC和S/4HANA都兼容是目前最稳妥的选择。如果项目已经在S/4HANA Cloud或者新ABAP环境上可以评估OData API但对委外组件这块的字段支持程度要提前做验证。5.3 字段增强怎么处理扩展传递和BADI实际业务里总会遇到BAPI标准字段覆盖不到的增强字段。比如你在PAI采购订单抬头自定义了一个“委托加工单号”字段或者组件行上维护了“供应商物料编码”之类的自定义字段。组件行增强字段的写入并没有想象中那么难。思路是继续用EXTENSIONIN但结构名要用你自己的增强结构同时在该增强结构里包含组件行的主键信息比如PO_ITEM这样增强字段才能准确挂到组件行下面。如果增强字段定义在表里并且配置了字段绑定示例代码里只要把自定义结构填好按同样方式追加到EXTENSIONIN表就行。如果是挂在标准字段上的业务校验比如创建时检查供应商是否允许委外加工那么建议走BADI如ME_PROCESS_PO_CUST在BAPI调用后逻辑上做补充校验和字段填充。这里不过度展开大家知道方向即可。6. 关于代码规范和上线前检查再说几句委外PO创建这个功能代码本身不算复杂真正决定项目上线后省心的往往是几个容易被忽视的习惯。第一RETURN消息一定要完整落日志。不要只处理EW和A类型也都要留下来因为A类型消息往往意味着“中止”E意味着错误W有时候是价格覆盖或者日期格式调整。日志落下来后续任何一笔单据出问题都能直接从日志里按采购订单号或者接口请求号倒推当时发生了什么。这条建议做任何BAPI开发都适用。第二TESTRUN的开关建议留成参数可配。测试环境用TESTRUNX跑上几个月养成了检查习惯再到生产环境切换关闭。很多项目上线后乱象根源就是紧张兮兮地第一次跑生产真实数据连个回退空间都没有。第三提交成功后的二次确认是一个低成本高收益的过程。BAPI_TRANSACTION_COMMIT后不回读、不校验、不记录等于把责任完全交给了BAPI。哪怕不做完整回读至少用一条COUNT查询确认EKPO里已经存在对应采购订单行花不了10毫秒却能挡住大雷。7. 再补充一个后续流程的提醒采购订单创建只是委外业务的第一公里。创建成功后还有两步流程和这个接口强相关建议在方案设计时一并考虑。第一步是发料。委外供应商拿到你的原材料之前需要在MIGO里做移动类型541的发料把原材料从自有库存发到供应商特殊库存O里。如果是接口集成场景这个发料动作可能也要自动化注意发料数量不能超过组件行数量否则系统会拦截。第二步是收货。供应商送货回来后做MIGO 101收货系统会按收货数量自动消耗供应商库存里的组件。如果组件库存不足收货会卡住。这个环节最需要关注的数据就是组件行数量和后续库存的联动关系前面提到的“组件数量按BOM用量传”的细节最终都会在收货环节体现出来。我个人的经验是做这个接口时不要只埋头写BAPI把发料、收货、发票校验三条链路的数据流都画一遍把每张供应商库存表的关系理清楚开发出来的代码才能真正扛得住业务高峰期的考验。
