MIR7预制发票时要输入多个发票号，非常多非常多，甚至多达100多个发票代码+发票号码。咋存？
我的第一反应是抓狂的，实现肯定是可以的，但做起来肯定很麻烦，一天肯定搞不定了。但需求已经改变不了了，就做吧。
怎么做呢？下面只讲思路。
代码结构比较复杂，不好粘贴上来。且授人以鱼不如授人以渔。
1：确定需求，用户希望在保存预制发票的时候，将“凭证、年度、发票代码、发票号码”存到一个Z表里。
2：既然需要存Z表，我们一般就要在增强屏幕里，提供数据维护的界面。数据维护的界面应该包括什么功能呢？
2.1：数据读取，从Z表里读取数据
2.2：数据维护，提供TableControl或者ALV维护表格数据
2.3：数据保存，将表格数据保存到Z表中。
对于2.1，存在的问题是，如果我们把它写到增强屏幕(假设为9001)的PBO中，则会每次都从DB中读取数据，这显然是不合适的。
对于2.3，存在的问题是：
1) 如果把它写到9001的PAI中，通过对SY-UCOMM的检查，实现表格数据保存到Z表的逻辑，也是不合适的。因为保存的时候除了手工保存外，还可能包含退出屏幕时“提示是否保存，然后选择是”的保存。
2) 凭证编号还没有生成，想保存到数据库也保存不了。
这时候需要我们提高对屏幕编程的认识。一般对于标准事务代码的增强屏幕，要保持一个原则：即在PBO和PAI里，只对程序内表进行操作，尽量不做数据库交互。
那么2.1的问题如何解决呢？这里提供几个思路：
思路1：看有没有增强点，SMOD的也好，BADI的也好
思路2：通过SAT/SE30执行MIR7，看一下这个过程中用到过的函数名，看有没有适合隐式增强的函数并进行隐式增强，将数据从DB中取出。
2.3的问题如何解决呢？2.3存在两个子问题，一是增强代码的位置，二是凭证编号生成较晚。
对于第一个子问题，还是上面两个思路，即：找增强，找函数。
对于第二个子问题，这个需要加深对标准事务保存数据逻辑的理解。
1）标准事务保存数据时，一般都是将数据提交到更新进程中，在更新进程中对数据统一进行保存的
2）MEMORY ID是无法将数据从当前进程传递到更新进程的。所以需要其他方式将数据提交到更新进程中
3）SHARED BUFFER是跨会话进程和更新进程的，但是对于同一个事务代码不同的会话进程和更新进程，SHARED BUFFER的ID如何区分和对应呢？这个方案好像也不行
4）CALL FUNCTION 'XX' IN UPDATE TASK是可以将数据提交到更新进程的。
结合上面的思路，我整理了一个思维导图。
接下来就是设计程序结构了，在此不在赘述了。
整个需求从开始编写到完整实现（包括严谨的自测完成），只用了半天时间，比我预想的快了很多。
最后结果如下图：
想学吗？快来我们项目上啊。
