企业官网建设流程全解析

上个月在客户现场，物料主管提了一个需求：收货过账时，要在MIGO的行项目上登记两个字段——“质检结论”和“供应商批次备注”。这两个信息标准界面上没有，之前的做法是让仓管员在收货完成后去MB03里补个长文本，既不规范，也容易漏。我当时的判断是，与其继续用长文本凑合，不如直接在MIGO上开一个自定义页签，把该填的字段铺到界面上，做必填校验，再落一张自定义表。整个过程走下来，涉及BADI增强、子屏幕绘制、数据落地和回显，链路不算短，但每一步都有明确的套路。这篇文章把完整实现过程和我踩过的坑一次性写清楚，给后面接同类需求的朋友做个参照。

1. MIGO增强之前：先回答三个问题

很多ABAPer接到MIGO增强需求，第一反应是去找隐式增强点，或者直接往SAPLMIGO里塞代码。这种做法不是不能用，但维护性很差。我在动手之前会先逼自己回答三个问题，任何一个答不清楚，后面一定会返工。

1.1 这个需求到底适合页签还是行字段

MIGO上做自定义字段，经常被混淆成“在MIGO里加一个列”。但实际上MIGO的ALV列表头和行项目页签是两套东西。

如果你的需求只是“想在看板或者报表上多看一个字段”，那本质上要做的是MSEG表加附加结构，再考虑MIGO列表展现。但如果你要在收货过程中让用户录入一些业务信息，并且这些信息和凭证绑定，那绝大多数情况都适合用页签方案。原因很简单：页签的字段在抬头和行项目两层都挂得上去，还可以做输入必填、按行切换数据、随凭证保存和读取，行为最接近标准功能。而直接在ALV Grid上塞可编辑列，需要处理单元格事件、数据校验、ALV字段目录维护，复杂度翻好几倍，而且MIGO的ALV Grid本身是SAP封装的，改起来相当痛苦。

我这边的场景是每行项目都要录质检结论，收货类型可能涉及采购订单收货和生产订单入库，最终选了行项目页签方案。

1.2 MB_MIGO_BADI：为什么它是最稳定的入口

SAP为MIGO专门预留了一个BADI：MB_MIGO_BADI，这是事务代码MIGO官方支持的增强点。这个BADI里有大量方法：

• PBO：界面输出时触发，适合挂页签、填充数据。
• PAI：用户输入后触发，适合校验。
• LINE_MODIFY：行项目数据变化时触发。
• POST_DOCUMENT：过账时每行触发，适合把自定义字段写到自建表。
• GET_UPDATE_TASK：异步更新阶段触发。
• LOAD：打开已有物料凭证时触发，适合回显数据。

选择这个BADI而不是隐式增强，有一个非常实际的理由：**它不随着MIGO的版本升级失效，而且方法语义和MIGO的过账生命周期一一对应。**你可以在正好的时机做恰好该做的事。隐式增强虽然也能干，但一旦你找错了include程序或者SAP改了内部逻辑，维护成本立刻飙升。所以只要项目许可，我首选BADI，隐式增强只用来做辅助的小改动。

1.3 增强对象的激活准备

开始编码前，先在SPRO或SE19里创建BADI实现。路径是SPRO -> 物料管理 -> 库存管理和实际库存 -> 收货 -> 增强 -> BADI定义中的实现，也可以用SE19直接输入增强点名称MB_MIGO_BADI创建实现。

创建实现类之后，系统会生成一个Z开头的类，比如ZCL_MIGO_CUSTOM_FIELDS。后续代码基本都写在这个类里。这个类还需要分配一个过滤器值吗？MB_MIGO_BADI大多是无过滤器的多实例BADI，意味着它每次MIGO打开时会实例化，所以不需要在SE19里配置过滤器。SAP里很多BADI默认是多实例，你不太需要关心，但如果你为了性能想限制某些移动类型才触发，那可能需要用过滤器，这里先不展开。

2. 自定义页签的挂载过程：ID编号、屏幕绘制和MIGO_DIALOG

页签在MIGO界面上长得像一排Tab，比如抬头页签有General、Goods receipt header等，行项目页签有Material、Quantities、Where等。这排页签是SAP在MIGO的PBO里通过函数MIGO_DIALOG动态生成的。我们要挂自定义页签，也是调用同一个函数，把自己的屏幕作为一个子屏幕塞进去。

2.1 页签ID的分段规则与选择

MIGO的页签ID是有规律的：1xxx开头的是抬头页签，2xxx开头的是行项目页签。每个页签在SAP内部注册时需要一个唯一的4位数字ID。标准页签占用的ID范围大概如下：

实际项目中我习惯用一个配置表或常量来定义自己页签ID，例如2201。不要用2001这种，因为容易和标准页签撞车。MIGO_DIALOG函数在注册重名ID时不会报错，但界面上会出现两个长得几乎一样的页签，排查起来很崩溃。

2.2 用SE51画一个能用的子屏幕

页签本身不是独立程序，它的内容是一个子屏幕（subscreen）。我用SE51创建了一个程序ZMM_MIGO_CUST，里面画了一个屏幕0100，屏幕类型选子屏幕。这个屏幕的布局很简单，就是几个标签和输入框：

• 质检结论（下拉框，值列表：合格、不合格、待检）
• 供应商批次备注（文本输入框，长度100）
• 自定义行标识（文本输入框，长度10）

SE51里画完屏幕后，要在屏幕的属性里把“子屏幕”勾上，否则MIGO_DIALOG挂载时会报错。同时建议在屏幕的布局里把输入字段对应的表字段名统一，比如V_ZSDR04-ZBZ的形式，这样后面代码里引用起来比较简单。

屏幕的流逻辑（PBO/PAI）必须写，最少也要有空的MODULE。我的屏幕流逻辑大概长这样：

PROCESS BEFORE OUTPUT. MODULE status_0100. PROCESS AFTER INPUT. MODULE user_command_0100.

这两个MODULE在ABAP程序里实现，主要负责把内存中的值搬到屏幕字段、或者把屏幕字段搬到内存。

2.3 通过MIGO_DIALOG把页签挂到MIGO上

页签的挂载动作放在BADI的PBO方法里，因为PBO每次进入MIGO界面都会执行，正好负责“把页签画出来”。

示例代码如下：

METHOD if_ex_mb_migo_badi~pbo. DATA: ls_return TYPE bapiret2. CALL FUNCTION 'MIGO_DIALOG' EXPORTING i_title = '自定义字段' " 页签标题 i_prog = 'ZMM_MIGO_CUST' " 子屏幕所在程序 i_dynnr = '0100' " 子屏幕号 i_page = '2201' " 页签ID，行项目层 i_page_subscreen = '0100' " 实际子屏幕号 i_check = 'X' " 参与CHECK_PAGE校验 i_icon = icon_okay i_language = sy-langu IMPORTING e_return = ls_return. IF ls_return-type EQ 'E'. MESSAGE ls_return-message TYPE 'E'. ENDIF. ENDMETHOD.

这段代码执行后，MIGO的行项目页签区会多出一个“自定义字段”页签。点进去就是我们的子屏幕0100。

关键参数我解释一下：

• i_title：页签显示的名称，必填。
• i_prog和i_dynnr：决定了页签内容从哪个程序、哪个屏幕调取。
• i_page：页签ID，前面说了，行项目层用2xxx。
• i_page_subscreen：实际要嵌入的子屏幕号，通常和i_dynnr一致。
• i_check：置X后，过账时系统会触发CHECK_PAGE校验事件。如果你在PAI里做了必填校验，这个标记必须打开，否则用户直接点过账时不一定触发你的检查逻辑。

这里有一个非常容易踩的细节：**i_page_subscreen如果不传，或者是空的，挂载就会成功但页面显示不出来。**查了好久才发现是漏了这个参数。

3. 字段数据的保存链路：从内存到自建表

页签挂上去，用户在子屏幕上录入字段，这只是第一步。真正麻烦的是把这些字段随MIGO过账一起保存下来，并且在以后打开凭证时再读出来。

3.1 自建表字段怎么设计才算不返工

自建表是自定义字段的归宿。表结构的设计直接影响后续处理的复杂度。我的实践是：以物料凭证号+年度+行号为关联键，再加备用字段。

一个参考表结构：

Table: ZMM_MIGO_CUST MANDT TYPE MANDT " 客户端 MBLNR TYPE MBLNR " 物料凭证号 MJAHR TYPE MJAHR " 物料凭证年度 ZEILE TYPE MBLPO " 行项目号 ZJYLX TYPE CHAR1 " 质检结论：1合格 2不合格 3待检 ZBZ TYPE CHAR100 " 供应商批次备注 ZBSCHR TYPE CHAR10 " 自定义行标识

为什么不用MSEG里已有的字段直接加附加结构？因为自定义字段不仅仅是给MIGO用，后面可能还要在报表里做统计分析，单独建表更干净，也不影响标准结构。但是你如果想要在MSEG相关的后台表中也保留这些字段，也可以同时做一个附加结构，只是维护成本又上去了。我的建议是：先用自建表把数据落地，如果业务确实要在标准报表中展示，再考虑附加结构。

3.2 PAI把屏幕值搬到哪儿

在MIGO这个框架里，自定义子屏幕程序里的全局变量和BADI实现类并不天然共享。解决这个问题的常规做法是借助ABAP内存（EXPORT/IMPORT TO MEMORY），或者把数据封装成类属性，再通过接口传递。

比较稳妥的做法是在子屏幕的PAI里，把输入的字段值打入内存ID：

MODULE user_command_0100 INPUT. DATA: gs_cust TYPE zmm_migo_cust. MOVE-CORRESPONDING v_zsdr04 TO gs_cust. gs_cust-zjylx = v_zjylx. gs_cust-zbz = v_zbz. gs_cust-zbschr = v_zbschr. EXPORT gs_cust TO MEMORY ID 'ZMM_MIGO_CUST_DATA'. ENDMODULE.

然后在BADI实现的POST_DOCUMENT方法里，把这个内存数据重新取出来：

METHOD if_ex_mb_migo_badi~post_document. DATA: gs_cust TYPE zmm_migo_cust. IMPORT gs_cust FROM MEMORY ID 'ZMM_MIGO_CUST_DATA'. ... ENDMETHOD.

用内存传递虽然简单，但要注意：MIGO界面上同时可能有多个行项目，用户切换行时，页签里显示的应该是对应当前行的那条记录。如果把gs_cust当做一个全局变量来用，切换行之后数据就是错的。所以内存里存的数据必须和当前行绑定，要么存一个能标识行号的内表，要么在PAI里就把行号一起存进去。

3.3 POST_DOCUMENT按行落地

BAID的POST_DOCUMENT方法是在MIGO保存过账时触发的，并且是按行处理的。我在实际使用中发现，这个方法的IM_MSEG参数携带着当前行项目的数据，IM_MKPF带有凭证抬头数据，PB_MKPF-MBLNR已经赋值了物料凭证号，可以直接用来关联。

示例代码：

METHOD if_ex_mb_migo_badi~post_document. DATA: ls_cust TYPE zmm_migo_cust. CHECK im_mkpf-mblnr IS NOT INITIAL. IMPORT ls_cust FROM MEMORY ID 'ZMM_MIGO_CUST_DATA'. MOVE-CORRESPONDING im_mkpf TO ls_cust. ls_cust-mblnr = im_mkpf-mblnr. ls_cust-mjahr = im_mkpf-mjahr. ls_cust-zeile = im_mseg-zeile. MODIFY zmm_migo_cust FROM ls_cust. IF sy-subrc EQ 0. CLEAR ls_cust. ENDIF. ENDMETHOD.

这只是一行数据的落地方式。如果有多行，内存里的gs_cust内表应该按行号索引，POST_DOCUMENT里再用im_mseg-zeile去取对应行。这是一个很重要的边界情况：不按行取数的话，多行过账时，自建表里每行存的都是最后一行页签的数据。

4. 回来继续显示：打开凭证时回填页签

用户今天收货录入了质检结论，明天要拿这张物料凭证做后续操作，打开MIGO显示的物料凭证，点自定义页签时最好能看到上次录入的值。这个需求不做，数据保存了也会被抱怨“存了跟没存一样”。

4.1 PBO中按当前行读库

回填逻辑放在BADI的PBO方法里。MIGO打开已有凭证时，PBO会被触发，而且我们能拿到IM_MKPF等参数。如果IM_MKPF-MBLNR有值，说明当前不是在“新建”状态，而是打开了一张历史凭证。

此时从自建表按凭证号和年度读取：

METHOD if_ex_mb_migo_badi~pbo. DATA: ls_cust TYPE zmm_migo_cust. IF im_mkpf-mblnr IS NOT INITIAL. SELECT SINGLE * FROM zmm_migo_cust INTO ls_cust WHERE mblnr = im_mkpf-mblnr AND mjahr = im_mkpf-mjahr AND zeile = im_mseg-zeile. IF sy-subrc EQ 0. EXPORT ls_cust TO MEMORY ID 'ZMM_MIGO_CUST_DATA'. ENDIF. ENDIF. ENDMETHOD.

然后子屏幕的PBO里，再把内存里的ls_cust取出来填充屏幕字段：

MODULE status_0100 OUTPUT. IMPORT ls_cust FROM MEMORY ID 'ZMM_MIGO_CUST_DATA'. v_zjylx = ls_cust-zjylx. v_zbz = ls_cust-zbz. v_zbschr = ls_cust-zbschr. ENDMODULE.

4.2 行切换时数据不同步的根因

MIGO的行项目页签有一个特点：当你点了列表里的另一行，页签内容会跟着变。这个切换动作触发的是MIGO自己的PBO/PAI循环，BADI的PBO方法也会重新执行。所以按当前行号去读库的逻辑基本能覆盖行切换场景。

但问题是：**如果用户只开了MIGO还没有点任何行，IM_MSEG传来的可能是空行。**这时按空行去读库，必然读不到数据。处理办法是直接用IM_GOITEM中携带的当前选中行索引来取行号，而不是依赖IM_MSEG- ZEILE。实际项目中我通常是先看IM_GOITEM有没有值，有值才执行读库和填充。另一个更稳妥的方案是在自建表里缓存整张凭证的所有行，然后在PBO时按当前行号从内表里取，这样能减少对自建表的频繁读库。

4.3 MB03显示界面要不要一起做

MIGO保存之后，很多用户习惯用MB03看物料凭证。MB03是标准的物料凭证显示事务，它不会执行MIGO的BADI，也不会显示我们自定义页签里的字段。所以如果你的业务人员需要在MB03里看到“质检结论”和“供应商批次备注”，那就要考虑另做一套增强，或者做一个Z报表。

我的经验是，**先想清楚MB03这块的需求边界再动手。**如果只是录入过账时必须要填，那只要MIGO里能录、能查，本次增强验收就过了。如果业务要求MB03也展示，那要考虑在MSEG结构上追加附加字段，或者做一个自定义报表。这个点属于需求分析层面的坑，代码层面不复杂，但容易被忽略。

5. 上线前必须跑的几类验证场景

自定义页签加完之后，如何验证它真的“稳”？这里说的稳不只是能保存，而是各种业务场景下都不能出乱子。以下几个场景建议你在测试环境完整过一遍。

5.1 收货、退货、转储分别过一遍

MIGO支持几十种移动类型，最基本的有三种：采购订单收货（101）、生产订单收货（101）、发货（201/261）、转储（311）。这些场景触发POST_DOCUMENT的时机是一样的，但IM_MSEG里填充的字段内容差异很大。

比如采购订单收货时，IM_MSEG- ZEILE是对应采购订单行；转储场景中IM_MSEG- UMMAT、UMWRK等字段有值；退货场景中移动类型是161或者针对特定流程的。自定义字段在所有这些场景下都会跟着过账，但业务上可能只要求“收货才必填、转储不要求”。所以你要在PAI校验里对移动类型做条件判断，不能让转储场景的用户卡在一个多余的必填字段上。

我在实现时是把移动类型赋值成实例属性，然后在PAI校验里按属性分支：

CASE mv_bwart. WHEN '101' OR '161'. " 收货/退货必填质检结论 IF v_zjylx IS INITIAL. MESSAGE e013(zmm) WITH '质检结论不能为空'. ENDIF. WHEN OTHERS. " 其他场景不校验 ENDCASE.

5.2 冲销与反记账的坑

MIGO做冲销时，比如对已收货的101凭证做102冲销，系统会生成一张反方向凭证。此时BADI的POST_DOCUMENT照常触发，IM_MSEG的主键仍然是原凭证号？不一定。冲销生成的新凭证会有新的凭证号，而且移动类型变成102。由于自建表是以物料凭证号+行号为关联键，新凭证会插入一条新的自定义字段记录，但这条记录的数据是从屏幕页签来的——如果用户冲销时没有去填写页签，那么页签字段就是空的。

这在业务上是合理的：冲销不强制填写自定义字段。但如果你不处理，用户会奇怪为什么MB51报表里冲销凭证的自定义字段是空的。是一个可接受的行为，但最好在实现说明里写清楚，免得后续有人拿着这问题来找你。

5.3 权限和消息抛出

自定义页签里的字段没有专门的权限对象，意味着只要用户能打开MIGO，就能看到并编辑这些字段。如果有些字段只允许特定角色填写，那就需要自己做权限控制。最简单的办法是在PAI里调用权限对象检查，或者在PBO里把字段设为不可输入。

消息抛出方面，建议把自定义校验消息定义在SE91里，用Z开头的一类消息，方便后续修改文本。别直接在代码里拼中文写到MESSAGE后面，标准规范不允许，后期维护也麻烦。

6. 项目中实际踩过的三个坑

最后分享一下我这次实施中实际踩过的坑，按时间顺序排，也都值得记一笔。

6.1 页签重复注册

第一次做的时候，我在PBO里直接调用了MIGO_DIALOG注册页签。后来MIGO的界面每次刷新PBO都会触发，页签越积越多，最后一屏全是重复的自定义页签。

SAP的MIGO_DIALOG有一个机制：你必须在PBO里先移除已有的同名页签，再重新注册，否则就会重复。常用的做法是先调用MIGO_DIALOG把这个页签的注册信息移除掉：

CALL FUNCTION 'MIGO_DIALOG' EXPORTING i_page = '2201' i_delete = 'X'.

然后在后面重新注册。也就是说PBO方法里的固定套路是：先删再挂。顺序搞反或者漏删，界面就会失控。

6.2 保存时取不到物料凭证号

第一次写POST_DOCUMENT时，我用IM_MSEG-MBLNR作为主键写库，结果发现保存后自建表里的MBLNR是空的。原因是IM_MSEG里的MBLNR在过账前可能还没有被赋值，或者是在BADI的这个时间点还没回填到行项目上。

后来改成用IM_MKPF-MBLNR作为凭证号来源，问题就解决了。这个细节值得记一下：MIGO保存时，抬头和行项目里数据的填充时机并不完全同步，以抬头的MBLNR为准更稳妥。

6.3 同一订单多次过账的数据残留

有一种特殊场景：用户对同一个采购订单先做101收货，然后再做101收货（分批收货），每次过账都会生成不同的物料凭证。因为自建表用物料凭证号+行号做唯一键，每次都会插入新记录，这本身没问题。

问题出在内存ID上。第一次过账后，内存ID里还残留着上一张凭证的页签数据。第二次新开MIGO做收货时，如果用户没有点开自定义页签、没有触发PAI，内存里的老数据就还在。这时候POST_DOCUMENT会把上一张凭证的值带进来。这是使用ABAP内存传递数据时最常见的坑。

解决办法：每次MIGO打开新凭证/刷新界面时，在PBO里主动清空内存ID，或者在POST_DOCUMENT落库前判断当前屏幕字段是否真的被用户操作过。这个判断很难做百分百准确，所以我在实际项目里采用了一个折中方案：**进入MIGO时把内存ID里的值清空，页签PBO第一次触发时如果发现全为空，就自动从自建表读取；如果用户真的手动清空了字段，那就按空值覆盖。**这样至少不会出现“上一张单子的数据悄悄跑到下一张单子里”的情况。

整个过程总结下来，MIGO自定义页签增强并不只是画个屏幕那么简单。页签ID选择、子屏幕绘制、内存传递、过账落库、行切换回显，每一步都有对应的生命周期和时序。尤其最后那三个坑，如果不在测试阶段模拟真实业务反复过几轮，上线后爆出来的基本都是业务人员根本无法自己解释的问题。我自己的体会是，做这类增强时要时刻把“MIGO的生命周期”刻在脑子里——它在PBO做什么、PAI做什么、POST_DOCUMENT做什么、什么时候创建新凭证、什么时候打开老凭证，一切代码的时机都跟着这个节奏走。搞懂了这个节奏，再复杂的MIGO需求也只是一个拼装过程。