TIPTOP 客製紀錄 (一)：單檔表單 —— 數位園丁的傳承第一課

這是一場關於「傳承」的教育訓練。最近，我看著中科大的學妹，彷彿看見了當年的自己——對那深不見底的 4GL 代碼充滿好奇卻又帶著一絲膽怯。ERP 系統的客製，就像是在一片已經成形的古老森林（TIPTOP）中，修剪出符合使用者需求的新枝芽。

客製紀錄的第一章，我們從最基礎、也最核心的「單檔-表單」開始。

單檔表單是 ERP 客製的母語

要在 TIPTOP 這座森林裡開墾，你必須先學會最基礎的單檔維護。單檔表單維護不僅是學會增、刪、修、查，更是在理解 4GL 程式的骨架與畫面檔（4FD）的連動藝術。如果這一關過不去，後面的主從結構與複雜邏輯都只是空中樓閣。

🍃 技術插播：4GL 與 4FD 的「腦與臉」

在 TIPTOP GP 5.3 的 Genero 架構中，4GL 與 4FD 的關係就像是「大腦」與「容顏」：

• 4FD (Form Design)：這是花棚的「設計圖」。它決定了欄位的位置、按鈕的顏色與佈局。它在 Genero Studio 中編輯，編譯後定義了視覺介面。
• 4GL (Genero Language)：這是灌溉的「控制系統」。它負責與資料庫溝通，決定什麼時候要把資料傳送到 4FD 的哪個格子裡。

當我們寫 INPUT BY NAME record.* FROM field.* 時，4GL 就會根據欄位的 Name 屬性自動找到 4FD 上的對應位置。名字一旦對不上，水分就送不到正確的花盆裡。

起點-由架構開始

首先，我們在 TIPTOP 的森林裡尋找一個「順眼」的程式（找那種邏輯清晰、沒有過多雜草的程式），我是使用aapi203，將它複製出來。接著，把所有的註記（Comments）全部拿掉，我們會得到一個最乾淨、最純粹的 4GL 骨架。

在 TIPTOP 的世界裡，每一隻單檔維護程式都必須符合這個標準架構。這就像是花園的圍籬，定義了程式運行的邊界。

這以下是一個標準單檔程式的「乾淨版」架構與逐行說明，修改成 capi901：

這就是 TIPTOP 客製的基底。無論功能多麼複雜，底層的骨架永遠是這幾行。只要記住這個節奏，妳就已經掌握了客製程式的律動。

執行的順序

這邊記錄在 TIPTOP 新增一個程式的順序，每個人可能不太一樣，這是我最順手的程序：

1. 資料結構定義：到 cap/sch，新增 tc_apx_file.sch 的檔案。
2. 標準化匯入：到 p_zta 透過匯入 create 工具新增檔案。
3. 欄位細修：修改 capi901 的相關欄位設定。
4. 程式編譯：編譯 capi901.4gl。
5. 畫面繼承：複製 aapi203 的 4FD 檔案到 capi901。
6. 介面調整：在 Genero Studio 中修改 capi901 的畫面欄位與佈局。
7. 上傳與系統連結：執行上傳，並運行 r.f2 capi901 與 r.gf capi901 0 c y y。
8. 權限註冊：到 p_zz 新增程式代號。
9. 連結設定：運行 r.l2 capi901。
10. 權限放行：在 p_zz 點選給予該檔案對應的使用權限。

以上如果順利，你就可以在 TIPTOP 森林中開啟你親手新增的功能了。

練習的開始

為了不讓學妹在踏入 TIPTOP 森林的第一步就被茂密的技術雜草絆倒（造成太大的挫折感），我為她準備的第一個練習非常微小，卻極其重要：在 capi901 中新增一個名為 tc_apx05 的欄位。

為什麼不直接讓她開發大功能？因為 TIPTOP 的客製門檻，其實藏著不少隱形的「前置技術債」：

• 對資料庫的操作熟悉：這塊土地下的資料礦脈是如何連動與流動的。
• 對 vi 編輯器的熟悉：這是園丁手裡最基本、也最鋒利的開墾鐮刀。
• 對 Linux 指令的熟系：妳必須知道如何優雅地穿梭在不同的目錄路徑間。

如果初學者在這個階段，還要同時承受程式架構的嚴謹性與畫面檔（4FD）的多重對應，這排山倒海而來的資訊壓力，足以讓一個新人的成長信心瞬間枯萎。

因此，我選擇讓她從新增 tc_apx05 欄位開始。這是一個「乾淨的實驗室」，讓她能專注於感受：當一個資料從無到有出現在畫面上時，那個「必要的位置」到底在哪裡。

這不是在偷懶，而是在建立「肌肉記憶」。當妳學會了如何精準地在指定的位置種下一朵花，未來在那片廣大的 ERP 森林中開疆闢土，才不會迷失方向。

第一課收成與行動

我們在這堂課中，成功建立了一支具備完整查詢、修改與刪除功能的程式。雖然這只是一個小小的練習，但它卻是在 TIPTOP 世界裡邁出的紮實第一步。

園藝法則：大型 ERP 的客製規範

看著程式成功執行的視窗，提醒說明：「能跑通程式只是開端，能優雅地在既有森林中生存才是客製的精髓。」

在一套像 TIPTOP 這樣龐大且歷史悠久的 ERP 系統中，我們必須遵守一套嚴謹的「園藝法則」，以確保這座森林不會因為我們的客製而陷入混亂：

1. 命名規則 (Naming Convention)：客製的變數、資料表與程式，必須嚴格遵守系統的命名規範（如 tc_xxx 或 cl_xxx）。這不只是為了好看，更是在進行系統升級或全域搜尋時，能一眼辨識出「這是我種下的花」。
2. 修改註記 (Annotation Style)：在代碼中進行修改時，必須留下一層「紀錄年輪」。包括修改日期、需求編號（Ticket ID）以及修改者的簽署。這讓後來的園丁在多年後維護時，能清楚知道當初修剪這根枝條的意圖。
3. 環境的使用邊界：永遠在 測試區 (Test Environment) 進行開墾，確認邏輯完美後，再移植到 正式區 (Production)。這就像是在溫室裡培育幼苗，而不是直接在森林保護區裡亂挖土，避免造成不可逆的系統崩潰。

核心心法：最小影響原則 (Principle of Minimal Impact) 在開發大型系統時，我們追求的是「以最小的改動達到最精準的效果」。不要為了新增一朵花而砍掉整排樹。學會如何在不破壞原本灌溉系統的前提下，優雅地插入我們的客製邏輯，這才是最進階的術法。

結語：代碼與邏輯的共生

TIPTOP 的客製紀錄，本質上是一場關於「平衡」的修行。

在大型 ERP 的森林裡，每一行代碼的加入都像是在既有的生態系中移植新生命。我們學會了 4GL 的架構嚴謹，理解了 4FD 的視覺配置，更體悟了在百萬行代碼中追求「最小影響」的工程美學。

第一課的結束，標誌著基本功的初步紮根。當我們不再只是機械式地複製代碼，而是開始思考每一行邏輯在系統整體的定位時，我們就從單純的開發者，進階成了能夠與系統共生的「數位園丁」。

下一篇紀錄中，我們將跨越單一資料的界線，深入探討 單檔明細 的陣列世界，細究如何管理那一長串起伏變動的數據清單。