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是可以將資料提交到更新程序的
。
結合上面的思路，我整理了一個思維導圖。
接下來就是設計程式結構了，在此不在贅述了。
整個需求從開始編寫到完整實現（包括嚴謹的自測完成），只用了半天時間，比我預想的快了很多。
最後結果如下圖：
想學嗎？快來我們專案上啊。
