iDempiere序章：你的三明治內餡不見了 某個尋常的下午，你打開 iDempiere，滿心歡喜地在 Kanban 看板上設好了工單的 EndTime，按下儲存—— 然後那個欄位就消失了。 不是 UI 的 bug。不是你手殘打錯。資料庫裡確確實實是 NULL。 你重做一次。消失。你再重做。還是消失。你盯著螢幕，沉默了三秒，開始懷疑人生。 歡迎進入本文的主題：有人在廚房裡偷吃你三明治的內餡，而且每次都得逞。 第一章：找到那個偷餡料的傢伙 嫌疑犯列表一開始很長。MRequest.beforeSave()？查過了，清白。你的 Plugin 邏輯？翻遍了，沒問題。Kanban Form？無辜。 真正的犯人躲在核心代碼深處，掛著一個無害的名字： RequestEventHandler，來自 org.adempiere.base。 它悄悄登記了 R_Request 的四個存檔事件：...
iDempiere各位 iDempiere 開發者，你是否也有過這種靈魂拷問： 「為什麼我的人生要花在把這 50 個 Excel 欄位一個一個填進 AD_Column？」 「為什麼每次建表都要補那 7 個系統欄位？我是誰？陽光在哪？」 如果你也有這種症狀，請放下手上的 SQL 腳本，看看這個：ray-idempiere-plugins。 痛點：ERP 開發者的日常（與地獄） 人工地獄：HR 丟來一個包含 50 個欄位的 Word 申請表，你得手動對照型別、長度，建到天荒地老。 系統 boilerplate：每個...
iDempiereiDempiere 內建了一個 Request 模組。它是 ERP 流程裡的工單與請求追蹤系統，功能完整，幾乎什麼都有。 我第一次打開它的時候，看著視窗裡密密麻麻的欄位，每一個都有意義，每一個都有理由存在，但我不知道從哪裡開始。就像第一次翻開易經：六十四卦，三百八十四爻，什麼都有，就是沒有入口。 幕一：我試著用原版 搜尋可以做。篩選可以做。狀態切換可以做。幾乎所有功能都在那裡，只是每一個動作都需要多點幾下，多填幾格，多想幾秒。不是壞，是累。 我試了一陣子，然後想清楚了一件事：這個模組沒有問題，是我和它之間的距離太遠。我不是要改掉它，我是要在它上面蓋一扇正常人的門。 Kanban View — 卡片依狀態分欄，顏色對應優先級 List View — 傳統分頁表格，按狀態分組 Update History — Request 異動記錄一覽 Attachment Dialog...