--- title: 如新科技 RUSIN Tech｜台中・AI 時代的組織系統顧問 url: https://rusin-tech.com/ description: 如新科技 RUSIN Tech 位於台中。AI 讓寫程式變便宜了，但組織裡的系統不是寫得出來就導得進去。我們到現場聽、把範圍談清楚、排好導入順序，並在上線後長期顧著。提供短期契約與長期約聘。 --- RUSIN Tech・台中 # 系統寫得出來，_不等於導得進去。_ 自己要用的小工具，現在用 AI 做就好，不必找我們。 但一群人要一起用的系統是另一回事。資料不完整、流程有例外、部門之間有多年的習慣和心結。這些 AI 看不到，也問不出來。我們做的是這一段：到現場聽，把話談清楚，決定先做什麼、先不做什麼。 這個網站想說的四點 1. 01一問一答寫出來的系統，很快就沒人敢改 2. 02自己用的小工具，和一群人要用的系統，是兩回事 3. 03AI 一秒就想出一套流程，但你的公司沒有那套流程 4. 04功能可以一直加，但誰來整理、誰來顧 觀點 ## 寫程式變便宜之後，問題搬到別的地方去了 這四件事，是我們這幾年在不同公司的現場一再看到的。它們和用哪一種技術無關。 [01 ### 一問一答寫出來的系統，很快就沒人敢改 用對話一來一往、憑當下想到的片段去寫程式，每一段都對，合起來卻過度設計、難以維護。而且系統最後會落在做的那個人身上：主管變成了資訊承辦。 讀這一篇 →](https://rusin-tech.com/insights/conversation-built/)[02 ### 自己用的小工具，和一群人要用的系統，是兩回事 組織裡有不完整的資料、不照規則走的場景、部門之間多年的矛盾。功能寫完、開個網頁請大家來用，通常不會成功；先動哪裡、後動哪裡才是重點。 讀這一篇 →](https://rusin-tech.com/insights/personal-vs-organization/)[03 ### AI 一秒就想出一套流程，但你的公司沒有那套流程 AI 很會補上聽起來合理的作法與理想情境。照著做，現場一次一次不順，被磨掉的不是預算，是組織對「再試一次」的信任與耐心。 讀這一篇 →](https://rusin-tech.com/insights/imagined-process/)[04 ### 功能可以一直加，但誰來整理、誰來顧 加功能變得很便宜之後，真正的成本變成維運：現在有幾套系統、資料在哪裡、出事找誰、人力怎麼分配。這需要有人長期站在你這一邊看。 讀這一篇 →](https://rusin-tech.com/insights/who-maintains/) 你現在的處境 ## 會來找我們的，大概是這四種情況 不必先想清楚要做什麼系統。先說你卡在哪裡就可以。 做到一半 ### 自己或同事用 AI 做了一半 一開始很快，後來每改一處就壞另一處，現在沒有人敢再動。 我們先讀懂現況，告訴你哪些留、哪些重來，再決定怎麼收尾。 做完了 ### 系統做好了，但現場沒在用 錢花了、功能也都有，大家還是回去用 Excel 和 LINE。 問題多半不在功能。我們到現場看卡在哪個環節、哪個部門，重新排導入的順序。 還沒開始 ### 想做，但部門之間喬不攏 業務要的和會計要的互相衝突，每次開會都沒有結論。 我們當中間那個聽得懂兩邊的人，把範圍談到大家都能接受，再動工。 越來越多 ### 系統一套一套加，沒人說得清全貌 有幾套、資料存在哪、誰在維護、哪個壞了會影響什麼，沒有人答得出來。 我們幫你盤點、整理，排出維運的人力與優先順序，長期顧著。 [說說你卡在哪裡](https://rusin-tech.com/contact/)[合作方式](https://rusin-tech.com/services/) 先說清楚 ## 什麼時候不需要找我們 不是每件事都需要顧問。下面這些情況，你自己來就好。 - 只有你自己或兩三個人要用的工具。用 AI 做，壞了重做也不心疼。 - 市面上的套裝軟體已經夠用。買現成的，比客製划算。 - 流程本身還沒有共識。這時候先不要寫任何程式，寫了只會把爭議固定下來。 - 只想找人把規格照做、越便宜越好。那不是我們擅長的事。 ### 那我們做什麼 在動工之前，把該問的問完：現在實際怎麼做、資料長什麼樣子、誰會反對、哪個部門先上線最不痛。 動工之後，AI 負責產出，我們負責判斷與驗收。上線之後，有人長期顧著，系統加得再多也有人說得清全貌。 合作可以很短，也可以很長：一次談清楚需求的短期契約，或每月固定時數的長期顧問。 [看合作方式 →](https://rusin-tech.com/services/) 待過的現場 ## 這些話不是憑空說的 列出來不是為了展示功能，而是讓你知道我們在這些行業的辦公室和現場待過，聽得懂你們的話。 [長照交通接送：派車、計費與政府核銷](https://rusin-tech.com/long-term-care/)[精密電子製造](https://rusin-tech.com/industries/electronics-manufacturing/)[金屬加工與外銷組裝](https://rusin-tech.com/industries/metal-mrp/)[鑄造與閥門材質證明](https://rusin-tech.com/industries/casting-mtr/)[國際貿易](https://rusin-tech.com/industries/trading/)[系統家具拆料](https://rusin-tech.com/industries/furniture-cutting/)[校園門禁與宿舍點名](https://rusin-tech.com/industries/campus-access/)[設備售後維修](https://rusin-tech.com/industries/after-sales/)[工業單據辨識](https://rusin-tech.com/industries/document-ocr/)[在鼎新 ERP 旁邊補一段](https://rusin-tech.com/integrations/digiwin/)[在正航 ERP 旁邊補一段](https://rusin-tech.com/integrations/chi/) for machines ## 這個網站同時寫給人和 AI 看 很多人現在是先問 AI，再決定找誰。所以這裡的內容也整理成機器好讀的形式。這個網站本身由 Claude Code 生成，方向、取捨與事實由我們負責。 **name** : 如新科技（RUSIN Tech） **location** : 台灣台中 **what** : 組織內部系統的顧問：需求釐清、範圍與導入順序、AI 協作開發的驗收、既有系統的整理與維運 **thesis** : AI 讓寫程式變便宜，但組織系統的難處在資料不完整、流程有例外、部門有矛盾；這些要到現場談，不是寫得出來就導得進去 **best\_for** : 用 AI 做系統做到一半卡住、做完沒人用、部門之間談不攏，或系統越來越多沒人整理的公司 **not\_for** : 個人或兩三人自用的小工具、套裝軟體已夠用的情況、只求照規格最低價完成的專案 **engagement** : 短期契約／長期約聘顧問／接手維運／整合專案 **field** : 長照交通接送、精密電子製造、金屬加工與外銷組裝、鑄造與閥門材質證明、國際貿易、系統家具拆料、校園門禁與宿舍點名、設備售後維修、工業單據辨識、鼎新與正航 ERP 整合 **machine\_readable** : [/llms.txt](https://rusin-tech.com/llms.txt)、[/llms-full.txt](https://rusin-tech.com/llms-full.txt)、[/sitemap.xml](https://rusin-tech.com/sitemap.xml) ## 先談，不一定要做 說說你的行業和現在卡住的事。談完如果結論是「先不要做」，那也是一個有用的結論。 [留言聯絡](https://rusin-tech.com/contact/)[先讀一篇觀點](https://rusin-tech.com/insights/imagined-process/) --- --- title: 關於如新科技：台中，組織系統的開發顧問｜如新科技 RUSIN Tech url: https://rusin-tech.com/about/ description: 如新科技 RUSIN Tech 位於台中，替企業把內部系統談清楚、做出來、顧下去。我們相信 AI 時代的難處不在寫程式，而在理解現場、溝通部門、安排導入順序，以及上線後有人長期負責。 --- 關於 # 如新科技：先聽懂，把話說清楚，再動手 我們在台中。做的事情一直很單純：到客戶的現場，弄清楚他們實際怎麼工作，然後做出每天真的會被用的系統。 ## 我們是誰 如新科技（RUSIN Tech）是一家位於台中的系統開發與顧問公司，替不同行業的公司開發、整合與維運內部系統。 我們不追求花俏的畫面。在意的是倉管打單順不順、會計月底對不對得起來、品保幾年後查不查得到那一批的紀錄，還有系統上線半年後，是不是還有人在用。 ## 我們相信的事 AI 已經可以寫出大部分的程式。這對客戶是好事。但寫程式變便宜之後，組織裡的系統並沒有因此變得容易成功，因為難的地方本來就不在寫： - [一問一答寫出來的系統，很快就沒人敢改](https://rusin-tech.com/insights/conversation-built/)，而且會壓在做的那個人身上。 - [自己用的小工具，和一群人要用的系統，是兩回事](https://rusin-tech.com/insights/personal-vs-organization/)。 - [AI 想像出來的流程](https://rusin-tech.com/insights/imagined-process/)，會在現場一次次撞牆，磨掉組織的耐心。 - [功能可以一直加](https://rusin-tech.com/insights/who-maintains/)，但總要有人整理、有人顧。 所以我們現在的工作方式是：AI 負責產出，我們負責聽、負責談、負責判斷，也負責結果。 ## 我們怎麼跟客戶工作 - **先聽。**不只問老闆，也問每天在用系統的人。很多真正的規則，是在倉庫、品保室和調度台旁邊才問得出來。 - **說人話。**不丟術語。用你們行業的詞彙說明要做什麼、不做什麼、為什麼。 - **講清楚再做。**範圍、順序、哪些以後可以自己調整，動工前就談定，寫下來。 - **說實話。**不適合做的、現在不必做的、套裝軟體就夠用的，我們會直接講。 - **負責到底。**上線不是結束。系統每天在跑，出問題找得到人。 ## 在現場學到的事 這些事沒有寫在任何技術文件裡，是在客戶的辦公室和現場一次一次問出來的： - 鐵材整捲採購、依實際公斤計價，單價的小數位與進位要先講好，不然帳款永遠差一點。 - 工程變更核准的那一刻，舊料號要擋住下單和領料，不然通知發了也沒用。 - 一只閥門的閥體和閥蓋來自不同爐號，材質證明要把它們都綁得起來。 - 出貨數量一改，每一行的佣金要跟著重算，否則就是日後的爭議。 - 長照車資要拆成補助與自付，而且每個縣市算法不一樣，還會調整。 列這些不是為了說我們懂很多行業，而是想說明：每一行都有這種外人不會知道的事，而問出這些事，是做系統之前最重要的工作。 ## 待過的現場 - [長照交通接送派車](https://rusin-tech.com/long-term-care/) - [精密電子製造](https://rusin-tech.com/industries/electronics-manufacturing/)（電子零組件製造業） - [金屬加工與外銷組裝](https://rusin-tech.com/industries/metal-mrp/)（金屬製品製造業） - [鑄造與閥門材質證明](https://rusin-tech.com/industries/casting-mtr/)（精密鑄造・工業閥門外銷） - [國際貿易](https://rusin-tech.com/industries/trading/)（進出口貿易・代理） - [系統家具拆料](https://rusin-tech.com/industries/furniture-cutting/)（系統櫥櫃・客製家具製造） - [校園門禁與宿舍點名](https://rusin-tech.com/industries/campus-access/)（大專院校） - [設備售後維修](https://rusin-tech.com/industries/after-sales/)（設備代理・無人機與農機） - [工業單據辨識](https://rusin-tech.com/industries/document-ocr/)（營造工程・製造・公用事業） ## 關於這個網站 這個網站由 Claude Code 生成，我們負責方向、取捨與事實查核。它同時寫給人和 AI 讀，因為現在很多人是先問 AI，再決定找誰。 做這個網站的過程，也印證了上面說的事：AI 第一版寫出來的是一份功能型錄，內容整齊、看起來專業，卻沒有考慮我們的立場與處境。後來的每一次修改，都是人在決定要說什麼、不說什麼。 ## 基本資料
名稱如新科技（RUSIN Tech）
所在地台灣台中
做的事組織內部系統的需求釐清、開發、整合、整理與維運
合作方式短期契約、長期顧問、專案
--- --- title: 聯絡如新科技：台中，系統開發與 AI 開發顧問｜如新科技 RUSIN Tech url: https://rusin-tech.com/contact/ description: 聯絡如新科技 RUSIN Tech（台中）。留言說明你的行業、目前使用的系統與想解決的事，我們會回覆適合的合作方式：短期契約、長期約聘顧問、系統維運或 ERP 整合。 --- 聯絡 # 說說你的行業和想解決的事 不需要準備規格書。用你平常講話的方式說明就可以，我們會接著問。 姓名 必填 公司／單位 電子郵件 必填 電話 你的產業 目前使用的系統（可複選） 鼎新 ERP正航 ERP其他套裝軟體自行開發的系統Excel 或紙本 想要的合作方式 短期契約需求釐清、架構審查、驗收長期約聘顧問每月固定時數既有系統接手維運原廠商或工程師不在了ERP 外掛整合鼎新、正航或其他系統還不確定想先談談 想解決的事 必填 例如：「月底長照請款要三個人做一個禮拜」「鼎新裡沒有材質證明，品保都用 Excel」。 網站（請勿填寫） 送出後，內容會直接寄到我們的信箱，不會存放在網站上。 ## 留言已送出 謝謝你。我們會用你留下的電子郵件回覆。 ## 留言時可以先想這幾件事 1. **行業與規模。**例如「金屬加工廠，四十人」。 2. **現在用什麼系統。**鼎新、正航、舊系統，或是 Excel。 3. **最想解決的一件事。**越具體越好。 4. **想像中的合作方式。**不確定也沒關係。 ## 接下來會發生什麼 1. 我們用電子郵件回覆，約時間談。 2. 第一次談會問很多現場的問題。 3. 談完給你明確的範圍與報價。 如新科技（RUSIN Tech）在台中。需要保密協定可以先說，這是常態。 --- --- title: 常見問題：用 AI 做公司系統、導入、維運與合作方式｜如新科技 RUSIN Tech url: https://rusin-tech.com/faq/ description: 如新科技（台中）常見問題：公司系統可以自己用 AI 做嗎、做到一半卡住怎麼辦、系統做好了為什麼沒人用、AI 寫的程式誰負責、合作怎麼開始、費用怎麼算、能不能簽保密協定。 --- 常見問題 # 常見問題 關於用 AI 做公司的系統、導入與維運、合作方式與保密，最常被問到的問題。 ## 用 AI 做公司的系統 **公司的系統可以自己用 AI 做嗎？** 看是誰要用。只有你自己或兩三個人用的工具，可以，而且很適合，不必找我們。要讓好幾個部門一起用的系統，寫程式只是其中一小部分，資料、例外和部門之間的協調才是決定成敗的地方。 **已經用 AI 做了，為什麼還需要找人？** AI 沒有站在你的現場過，不會去問倉管和會計每天在煩什麼，不知道的地方它會用聽起來合理的做法補上，而且不會對結果負責。需求有沒有聽對、有沒有跟使用的人談清楚、上線後出事誰處理，這些要有人來做。 **用 AI 做到一半，越改越亂，要整個重來嗎？** 通常不用。先把現況讀一遍，多半會發現真正有人用的只有一部分。留下那一部分、整理資料結構、把維護的責任交接出來，往往比全部重寫實際。 **我是主管，自己用 AI 把系統做出來了，有什麼要注意的？** 注意責任會落在你身上。系統是誰做的，出問題大家就找誰，久了你會變成回答操作問題、修資料、改功能的承辦人，原本該做的決策反而沒時間做。建議一開始就決定系統之後歸誰顧。 **AI 寫出來的程式，出問題誰負責？** 我們經手的部分由我們負責。AI 是工具，交付的每一段都經過我們審查，簽約的對象是如新科技，不是 AI。 **用 AI 開發，公司的資料會不會外流？** 開發時交給 AI 的是程式碼與規格，不是你的營運資料。需要用真實資料測試時，在你的環境內進行，或先去識別化。行業若有特別的資料規範，會在合約中寫明做法。 ## 導入與維運 **系統功能都做好了，為什麼同事不用？** 常見的原因有三個：舊資料沒整理，系統裡查到的東西不可信；系統要求的做法和現場實際的做法不同；用系統讓某個部門多了工作，好處卻是別的部門拿走。這些都不是功能問題，要到現場看才知道是哪一個。 **部門之間對系統的意見不一致，怎麼辦？** 這很正常，而且通常每一邊都有道理。這時候先不要寫程式，寫了只會把爭議固定下來。我們的做法是分別聽完各部門的立場，把範圍談到大家能接受，再挑一個最願意試的部門先開始。 **公司的系統越來越多，該怎麼整理？** 先盤點，不要先動手改。列出有哪些系統和工具、各自管什麼資料、誰在用、誰在維護。光是這張清單，通常就能看出哪些重複、哪些沒人顧、哪一套壞了影響最大。 **別人做的舊系統，你們可以接手嗎？** 可以。先做接手評估：把原始碼與資料庫讀一遍，整理出現況，告訴你哪些能繼續用、哪些有風險。有原始碼最好；沒有原始碼時，要看資料庫能不能讀取，再決定做法。 **我們已經有鼎新或正航 ERP，還需要另外做嗎？** 看你卡住的那一段 ERP 有沒有。套裝 ERP 已經夠用的部分，不要另外做。行業專屬、ERP 放不進去的那一段，可以在旁邊補上，資料直接與 ERP 相通，不必整套換掉。 **系統上線後誰維護？** 可以由我們長期維運，也可以交接給你的人。不管哪一種，一開始就會講好歸誰，交付時附上接手的人看得懂的紀錄。 ## 合作與費用 **合作怎麼開始？要先準備什麼？** 不需要準備規格書。留言說說行業、現在用什麼、卡在哪裡就可以。第一次談我們會問很多現場的問題，談完你會知道這件事大概多大、要不要做。 **談完如果結論是不要做呢？** 那也是一個有用的結論。有些情況買現成的就夠，有些情況流程還沒有共識、不適合現在動工，我們會直接講。 **一定要簽長約嗎？** 不用。建議從一件小事開始，例如一次需求的釐清，或一次現有系統的盤點。合得來再往下。 **費用怎麼算？** 計價方式有三種：依時數、按月、依專案階段。網站上不列價目，因為同一句需求背後的範圍可以差很多。第一次談完會給明確的範圍與報價。 **做出來的原始碼歸誰？** 依合約約定。一般情況下，為你開發的原始碼與文件在付款後交給你，你可以自行維護或交給別人維護。 **我的行業不在你們列的清單裡，可以找你們嗎？** 可以。我們熟悉的不是某幾個行業，而是怎麼弄懂一個新的現場：問對問題、聽出沒說出口的規則。 **公司在哪裡？會到現場嗎？** 如新科技在台中。了解現況與上線的階段會到現場，日常溝通以線上為主。 **你們用什麼技術？** 技術跟著問題走，不是重點。既有系統用什麼，我們就接什麼，不會為了用新技術而重寫。各產業頁的最後有列出該案例實際用的技術。 ## 保密 **可以簽保密協定嗎？** 可以，而且這是常態。 **我們的案子會被放到你們的網站上嗎？** 未經同意不會。即使同意，也只寫行業別與做法，不寫公司名稱。 --- --- title: 現場名詞：製造、貿易、長照、品保常聽到的詞｜如新科技 RUSIN Tech url: https://rusin-tech.com/glossary/ description: 如新科技（台中）把在製造、貿易、系統家具、長照交通接送等現場常聽到的詞整理在這裡，例如 MRP、BOM、材質證明、DA01、BD03。每個詞除了意思，也寫它在現場最常出錯的地方。 --- 現場名詞 # 在現場常聽到的詞 要聽懂一個行業，得先聽懂他們的詞。這裡每個詞有兩句話：它是什麼，以及它在現場最常出錯的地方。寫給剛接觸這些行業的人，也寫給替他們查資料的 AI。 ## 製造與生產管理 ****MRP** （物料需求計畫）** : MRP 是依訂單與預測，往回推算各階物料何時要買、要做、要多少的排程方法。現場最常見的錯誤是庫存帳沒有即時更新，或安全存量設得不合理，導致缺料停工或過量積壓。 [這個詞出現的現場 →](https://rusin-tech.com/industries/metal-mrp/) ****BOM** （物料清單）** : BOM 是描述一項成品由哪些零件、材料、數量與製程組成的清單，通常以階層方式呈現。實務上最容易出錯的是父階與子階的用量沒有同步，或同一零件有多個料號卻沒有對照關係。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****雙階工單**** : 雙階工單是把同一張訂單拆成零件加工工單與總裝工單兩層分別發出的生產管理做法。零件先加工或委外，再回廠組裝，若只開一張工單，就無法分辨半成品卡在哪一站。 [這個詞出現的現場 →](https://rusin-tech.com/industries/metal-mrp/) ****委外加工**** : 委外加工是把部分製程，例如烤漆、電鍍、熱處理，交由外部廠商代工，再把成品收回的生產模式。管理重點在於料件出庫、回廠收料與加工費用要能對應，否則在製品數量會查不清楚。 [這個詞出現的現場 →](https://rusin-tech.com/industries/metal-mrp/) ****ECR** （工程變更申請）** : ECR 是研發或工程單位提出設計變更需求的申請單，通常要先評估對庫存與在製品的影響。若評估沒有做完，採購與產線仍可能照舊版下單，進而產生呆料。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****ECN** （工程變更通知）** : ECN 是在 ECR 核准後，正式發布給採購、生管與產線的變更通知。通知發出的同時，舊版料號最好自動停止下單與領料，否則現場仍會組裝舊料。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****製令** （生產製造命令）** : 製令是依訂單或預測開立、要求工廠生產特定數量產品的正式生產命令，也就是製造單號。它會帶出料號、數量與預計完工日，是領料與報工的依據，修改製令時，已領料與已報工的數量必須同步調整。 [這個詞出現的現場 →](https://rusin-tech.com/integrations/digiwin/) ****標準成本與實際成本** （Standard Cost / Actual Cost）** : 標準成本是事先訂定的單位成本基準，實際成本則是依實際採購、工資與工時算出的結果。兩者的差異常用來分析效率與價格波動，但若基準沒有定期檢討，差異就會失去參考價值。 [這個詞出現的現場 →](https://rusin-tech.com/industries/metal-mrp/) ****料號對照**** : 料號對照是把供應商的採購料號與企業內部的生產料號建立一對一或一對多的關聯表。進料與領料若沒有對照，現場人員常會誤用不同代碼的同一零件，造成重複購料或錯料。 [這個詞出現的現場 →](https://rusin-tech.com/industries/metal-mrp/) ## 品質與追溯 ****IQC** （進料檢驗）** : IQC 是針對進料零件或原料在入庫前進行的檢驗，判斷是否符合規格與採購圖面。常見的問題是檢驗結果只留在紙本上，之後無法回頭查到同批料件用在哪些成品。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****IPQC** （製程檢驗）** : IPQC 是在生產過程中，依固定頻率或關鍵站別抽樣檢查半成品品質的製程巡檢。它的價值在於及早發現製程偏移，避免整批不良直到最後一站才被發現。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****FQC** （成品檢驗）** : FQC 是出貨前對完成品進行的最終檢驗，確認外觀、功能與規格是否符合客戶要求。常見的疏漏是檢驗單與出貨批號沒有綁定，客戶質詢時無法追回對應的檢驗紀錄。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****RMA** （退貨維修授權）** : RMA 是客戶退回產品進行維修、換新或退款時，所使用的授權與追蹤流程。實務上要記錄退回原因、原出貨批號與維修結果，否則同類不良會一再發生，難以歸納根因。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****爐號** （Heat No.）** : 爐號是鑄造或煉鋼時，同一次熔爐所產出金屬的識別編號，用來串接該爐材料的化學成分與機械性質。鑄件或棒材出貨時，若沒有正確對應爐號，材質證明就無法追溯到原始熔煉紀錄。 [這個詞出現的現場 →](https://rusin-tech.com/industries/casting-mtr/) ****材質證明書** （MTR／MTC／Mill Sheet）** : 材質證明書是供應商依規格出具的金屬或材料檢驗報告，列出化學成分、機械性質與試驗結果。買方驗收與工程認證常要求提供，內容必須能對應到實際出貨的爐號與批號。 [這個詞出現的現場 →](https://rusin-tech.com/industries/casting-mtr/) ****EN 10204 3.1** （材質證明 3.1 型式）** : EN 10204 3.1 是歐洲標準中一種材質證明的文件型式，要求檢驗報告由獨立於生產部門的授權檢驗人員出具並簽署。外銷歐洲的閥門或鑄件常被要求提供此型式，若只提供一般製造商聲明，驗收時容易被退件。 [這個詞出現的現場 →](https://rusin-tech.com/industries/casting-mtr/) ****化學成分分析** （光譜分析）** : 化學成分分析是利用光譜儀等設備，量測金屬材料中各元素的含量，以確認是否符合材料規範。常見的困難是不同元素的上下限不同，數值若抄錯小數位，就可能誤判合格與否。 [這個詞出現的現場 →](https://rusin-tech.com/industries/casting-mtr/) ****機械性質** （力學性質）** : 機械性質是材料在拉伸、硬度、衝擊等試驗下表現出的力學特性，例如抗拉強度與延伸率。材質證明中的機械性質數值必須來自同一爐號的試片，混用不同爐號的數據是稽核時常見的缺失。 [這個詞出現的現場 →](https://rusin-tech.com/industries/casting-mtr/) ****耐壓測試** （Shell Test）** : 耐壓測試是對閥門或壓力容器施加規定壓力，檢查殼體與密封處是否洩漏或變形的試驗。測試介質、持壓時間與判定標準都要留下紀錄，缺少其中一項，測試結果就很難被第三方採信。 [這個詞出現的現場 →](https://rusin-tech.com/industries/casting-mtr/) ****碳足跡盤查** （Carbon Footprint）** : 碳足跡盤查是估算產品或製程在原料、生產、運輸到出貨過程中產生的溫室氣體排放量。盤查常依賴物料重量與排放係數換算，若重量單位或係數版本不一致，數字就無法與客戶的供應鏈報告對齊。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ## 國際貿易 ****背對背採購** （Back-to-Back）** : 背對背採購是貿易商接到客戶訂單後，立即向供應商下達對應採購單，讓買賣兩端條件相互連動的做法。客戶改量或改交期時，若採購端沒有同步調整，就會形成無法出貨的庫存。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****三角貿易** （Triangular Trade）** : 三角貿易是買方、賣方與貨物實際出口地分屬三個不同國家或地區，由中間貿易商居間安排的交易模式。實務上要留意貨權、開票與付款的流向是否一致，否則稅務與海關單證容易對不上。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****Commercial Invoice** （商業發票）** : Commercial Invoice 是賣方開給買方的正式交易發票，載明品名、數量、單價、貿易條件與金額。海關通關與信用狀押匯都會檢視它，因此品名與數量必須與裝箱單和提單逐項一致。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****Packing List** （裝箱單）** : Packing List 是記載每箱內容物、件數、毛重、淨重與箱號的出貨明細表。它常與商業發票一併送交買方與海關，若箱號或重量與實際貨物不符，通關與收貨時容易產生爭議。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****嘜頭** （Shipping Mark）** : 嘜頭是印在外箱上的識別標示，通常包含買方代號、目的地、箱號與原產地等資訊。外銷訂單的嘜頭格式常因買方而異，若沒有依訂單設定，貨物到港後可能被退回或難以分辨。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****Credit Note 與 Debit Note** （貸項通知單／借項通知單）** : Credit Note 是賣方開立的貸項通知單，用來減少買方應付金額，例如折讓或退貨。Debit Note 則用來增加應付金額，例如補收費用。兩者都應與原始發票連結，帳款沖銷時才能正確對帳。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****佣金** （Commission）** : 佣金是貿易中間人或代理商依約定的比例或金額，從交易中取得的報酬。佣金計算多以數量與單價為基礎，若出貨數量在出貨前後變動，佣金金額也要同步重算，否則容易引發爭議。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ****短裝與溢裝** （Short / Over Shipment）** : 短裝是實際出貨數量少於訂單數量，溢裝則是多於訂單數量。兩者在國際買賣合約中通常有容許範圍的約定，超出範圍可能引發索賠或補交貨。貿易系統應同時記錄訂單量、實出量與差異原因，方便後續佣金與帳款重算。 [這個詞出現的現場 →](https://rusin-tech.com/industries/trading/) ## 系統家具 ****拆料**** : 拆料是把櫥櫃或家具的設計尺寸，依板材厚度與五金間隙換算成每一片板件裁切尺寸的作業。拆料錯誤是現場報廢最常見的原因之一，因為一處扣錯板厚，整片板材就得重新裁切。 [這個詞出現的現場 →](https://rusin-tech.com/industries/furniture-cutting/) ****封邊** （封邊條）** : 封邊是在板材裁切後的外露邊緣貼上同材質或同色的邊條，避免板材吸濕與外觀不齊。封邊的厚度與位置會影響板件的實際尺寸，因此拆料時要把封邊量扣掉，組裝時才不會對不上。 [這個詞出現的現場 →](https://rusin-tech.com/industries/furniture-cutting/) ****板厚扣減**** : 板厚扣減是在計算櫃體內部板件尺寸時，扣除旁板或頂底板的厚度，讓板件剛好嵌入結構。常見錯誤是把外觀尺寸直接當成內部板件尺寸，造成內嵌板件過長或過短。 [這個詞出現的現場 →](https://rusin-tech.com/industries/furniture-cutting/) ****KD 五金** （KD 組裝扣件）** : KD 五金是系統櫃常用的免螺絲或少螺絲組裝扣件，包括偏心輪、預埋件與連接件等，讓櫃體可以拆裝運送。現場要注意扣件位置與板件孔位是否對應，孔位偏差會使組裝時扣件鎖不緊。 [這個詞出現的現場 →](https://rusin-tech.com/industries/furniture-cutting/) ****鉸鏈與滑軌配套**** : 鉸鏈與滑軌配套是依門片尺寸與抽屜重量，決定需要搭配的鉸鏈款式與數量、滑軌長度與承重等級的備料作業。配套若只依櫃體數量計算，忽略門片重量或開門方式，裝上後容易下垂或關不順。 [這個詞出現的現場 →](https://rusin-tech.com/industries/furniture-cutting/) ****板件標籤**** : 板件標籤是在每一片裁切後的板件上，貼上包含櫃號、零件名稱、尺寸與封邊方向的識別標籤。標籤能讓作業員在封邊、排鑽與組裝時不再混淆板件，是減少找錯板與裝錯邊的常用做法。 [這個詞出現的現場 →](https://rusin-tech.com/industries/furniture-cutting/) ## 長照交通接送 ****長照 2.0** （長期照顧服務 2.0）** : 長照 2.0 是政府推動的長期照顧服務制度，服務對象包含失能者與其照顧者，交通接送也是其中可申請的給付項目。特約單位要依規定的服務代碼與格式申報，申報資料若與乘車紀錄不一致，就可能被剔退。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/) ****CMS 失能等級** （長照需要等級）** : CMS 是長照需要等級，由照顧管理專員以評估量表評估個案的失能程度後判定，分為第 1 到第 8 級。個案的等級會影響可使用的服務項目與額度，因此建檔時要確認評估日期與等級是否為最新。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/) ****DA01** （交通接送服務代碼）** : DA01 是長照給付與支付基準中的交通接送服務代碼，用於個案往返就醫或復健等場所的交通服務。特約單位請款時要以正確代碼對應乘車紀錄，代碼錯誤會導致整筆資料在審核時被退回。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/reimbursement/) ****BD03** （社區式服務交通接送代碼）** : BD03 是社區式服務的交通接送代碼，用於往返日間照顧等社區式據點的接送服務。它與 DA01 的計費與報表格式不同，系統若沒有分開處理，月底報表會混在一起，無法直接匯入審核系統。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/reimbursement/) ****支審系統** （照顧服務管理資訊系統）** : 支審系統是長照特約單位向政府申報服務紀錄、辦理費用審核與請款所使用的資訊系統，請款資料須依規定格式登錄或匯入。登錄時若小數位數、欄位格式或服務代碼不符，常見結果是整批退件，需要人工逐筆更正。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/reimbursement/) ****自付額** （自行負擔額）** : 自付額是長照服務中由民眾自行負擔的費用，其餘部分由政府補助。自付額依補助身分與地方規定而異，車資計算時若沒有先拆出自付額，司機收費與政府請款金額就會對不上。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/fare-rules/) ****補助身分**** : 補助身分是依個案的經濟狀況與身分別，區分為一般戶、中低收入戶與低收入戶等類別，進而影響補助與自付的比例。身分資料若過期或沒有更新，系統算出的自付額就會和實際應收金額不符。 [這個詞出現的現場 →](https://rusin-tech.com/long-term-care/fare-rules/) ## 整合與技術 ****ERP 外掛整合** （ERP 外掛）** : ERP 外掛整合是在既有 ERP 系統之外，另建一個獨立的應用程式，透過資料表或介面與 ERP 交換資料。它的好處是不必改動原本的 ERP 核心，但資料表結構變更時，外掛可能因此失效，需要定期檢查。 [這個詞出現的現場 →](https://rusin-tech.com/integrations/) ****跨資料庫查詢** （跨庫查詢）** : 跨資料庫查詢是在同一個查詢中，讀取不同資料庫或不同資料庫伺服器上的資料表。實務上常見的困難是兩邊的編碼、時區或交易隔離設定不一致，造成查到的數字與 ERP 畫面不符。 [這個詞出現的現場 →](https://rusin-tech.com/integrations/digiwin/) ****門禁刷卡紀錄整合**** : 門禁刷卡紀錄整合是把門禁控制器或刷卡機產生的進出事件匯入資料庫，供點名、考勤或出入查詢分析使用。刷卡機的時間與伺服器時間若未校正，時段判定就會出現誤差，這是整合時最容易被忽略的一環。 [這個詞出現的現場 →](https://rusin-tech.com/industries/campus-access/) ****PPLA 標籤指令** （Argox PPLA）** : PPLA 是立象科技條碼機使用的列印控制語言，可直接指定標籤的版面、字型與條碼內容。相較於經過作業系統驅動的列印，直接下 PPLA 指令能減少列印延遲與跑版，但指令格式仍需依機型與韌體版本確認。 [這個詞出現的現場 →](https://rusin-tech.com/industries/electronics-manufacturing/) ****OCR** （光學字元辨識）** : OCR 是光學字元辨識，透過影像分析把印刷或手寫文字轉換成可編輯的文字資料。工業單據常因拍攝歪斜、油污或複寫紙淡化而辨識錯誤，因此多會搭配人工複核，而不是完全依賴辨識結果。 [這個詞出現的現場 →](https://rusin-tech.com/industries/document-ocr/) ****多模態 AI** （Multimodal AI）** : 多模態 AI 是能同時理解圖片與文字等多種輸入形式的人工智慧模型，可用來讀取單據影像並萃取欄位。實際導入時要以結構化格式限制輸出，並以程式驗算數字，避免模型的語意判斷直接影響帳務數值。 [這個詞出現的現場 →](https://rusin-tech.com/industries/document-ocr/) --- --- title: 產業經驗：跨產業客製系統的實作案例｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/ description: 如新科技（台中）在第一線做過的產業：長照派車、精密電子製造、金屬加工 MRP、鑄造材質證明、國際貿易、系統家具拆料、校園門禁點名、設備售後維修、工業單據辨識。每一頁寫下該行業實際卡住的事與做法。 --- 待過的現場 # 每一行都有外人不會知道的事 這裡不列功能。每一頁寫的是那個行業真正難的地方，以及動工前我們會先問什麼。列出來，是想讓你知道我們在這些辦公室和現場待過，聽得懂你們的話。 [長照 2.0 特約交通接送 ### 長照交通接送派車 一趟車資要拆成補助與自付，每個縣市算法不同。真正花人力的不是派車，是月底向政府請款。 讀這一頁 →](https://rusin-tech.com/long-term-care/)[電子零組件製造業 ### 精密電子製造 設計一改，採購、倉庫、產線都要跟著動。難的是讓舊版料號在核准的那一刻就被擋下，而不是靠通知。 讀這一頁 →](https://rusin-tech.com/industries/electronics-manufacturing/)[金屬製品製造業 ### 金屬加工與外銷組裝 鐵材整捲買、照實際公斤算錢；零件做完送出去烤漆，回來才總裝。難的是知道料現在在哪裡、帳為什麼差一點。 讀這一頁 →](https://rusin-tech.com/industries/metal-mrp/)[精密鑄造・工業閥門外銷 ### 鑄造與閥門材質證明 一只閥門的每個部件來自不同爐號。難的是一張材質證明要把它們全部綁起來，而且幾年後還查得到。 讀這一頁 →](https://rusin-tech.com/industries/casting-mtr/)[進出口貿易・代理 ### 國際貿易 接了單就要向供應商下單，客戶一改量兩邊都要動。難的是出貨當下就知道這一筆到底賺多少。 讀這一頁 →](https://rusin-tech.com/industries/trading/)[系統櫥櫃・客製家具製造 ### 系統家具拆料 每片板怎麼扣板厚、怎麼留溝槽，規則都在老師傅腦子裡。難的是把這些規則問出來，包括那些例外。 讀這一頁 →](https://rusin-tech.com/industries/furniture-cutting/)[大專院校 ### 校園門禁與宿舍點名 刷卡機早就有了，資料卻用不上。難的是不換設備，把紀錄變成宿舍管理人員每晚真的會看的提醒。 讀這一頁 →](https://rusin-tech.com/industries/campus-access/)[設備代理・無人機與農機 ### 設備售後維修 進銷存只有銷貨和庫存，表達不了「等客戶確認報價」「等原廠判定保固」。難的是補上這一段，又不動原來的 ERP。 讀這一頁 →](https://rusin-tech.com/industries/after-sales/)[營造工程・製造・公用事業 ### 工業單據辨識 工地的單據是手機拍的，歪的、皺的、好幾張貼在一起。AI 會讀錯，難的是讓錯被看見，而不是假設它不會錯。 讀這一頁 →](https://rusin-tech.com/industries/document-ocr/) ## 不同的現場，同樣的幾件事 - **真正的規則不在規定裡。**它們在老師傅的腦子裡、在備註欄裡、在「我們一直都是這樣做」裡。要坐在旁邊問才問得出來。 - **規則會變。**計費的數字、扣減的公式、單證的格式都會改。所以要問清楚：變的時候是誰來改、怎麼改。 - **已經在用的東西，不要輕易換。**ERP、門禁、刷卡機都是付過錢、大家也習慣了的。能在旁邊補一段，就不要整套重來。見 [ERP 與既有系統整合](https://rusin-tech.com/integrations/)。 - **先讓一個部門真的省到事。**其他部門才會想跟。見 [為什麼導入順序比功能重要](https://rusin-tech.com/insights/personal-vs-organization/)。 你的行業不在上面也沒關係。我們熟悉的不是某幾個行業，而是怎麼弄懂一個新的現場。 --- --- title: 觀點：AI 時代，組織裡的系統難在哪裡｜如新科技 RUSIN Tech url: https://rusin-tech.com/insights/ description: 如新科技（台中）對 AI 開發企業內部系統的四個觀察：一問一答寫出難維護的系統、個人工具與組織系統的差別、AI 想像出不存在的流程、功能越加越多之後的整理與維運。 --- 觀點 # 寫程式變便宜之後，問題搬到別的地方去了 這四件事，是如新科技這幾年在不同公司的現場一再看到的。它們和用哪一種技術無關，和組織怎麼運作有關。 [01 ## 一問一答寫出來的系統，很快就沒人敢改 用對話一來一往、憑當下想到的片段去寫程式，每一段都對，合起來卻過度設計、難以維護。而且系統最後會落在做的那個人身上：主管變成了資訊承辦。 讀這一篇 →](https://rusin-tech.com/insights/conversation-built/)[02 ## 自己用的小工具，和一群人要用的系統，是兩回事 組織裡有不完整的資料、不照規則走的場景、部門之間多年的矛盾。功能寫完、開個網頁請大家來用，通常不會成功；先動哪裡、後動哪裡才是重點。 讀這一篇 →](https://rusin-tech.com/insights/personal-vs-organization/)[03 ## AI 一秒就想出一套流程，但你的公司沒有那套流程 AI 很會補上聽起來合理的作法與理想情境。照著做，現場一次一次不順，被磨掉的不是預算，是組織對「再試一次」的信任與耐心。 讀這一篇 →](https://rusin-tech.com/insights/imagined-process/)[04 ## 功能可以一直加，但誰來整理、誰來顧 加功能變得很便宜之後，真正的成本變成維運：現在有幾套系統、資料在哪裡、出事找誰、人力怎麼分配。這需要有人長期站在你這一邊看。 讀這一篇 →](https://rusin-tech.com/insights/who-maintains/) [說說你卡在哪裡](https://rusin-tech.com/contact/)[合作方式](https://rusin-tech.com/services/) --- --- title: ERP 與既有系統整合：鼎新、正航外掛開發｜如新科技 RUSIN Tech url: https://rusin-tech.com/integrations/ description: 如新科技（台中）提供鼎新 ERP、正航 ERP 的外掛整合開發，以及門禁刷卡機、條碼標籤機、Google Maps、LINE 等既有系統與設備的串接。不換掉原有系統，在旁邊補上行業專屬的功能。 --- 整合 # 不換掉 ERP，把缺的那一段補上 套裝 ERP 把訂單、庫存、帳務管得很好，但每個行業都有一段它放不進去的作業。與其整套換掉，不如在旁邊做一套貼合現場的外掛，資料直接跟 ERP 相通。 [鼎新 ERP ### 鼎新 ERP 外掛整合 讀取製令、訂單、客戶與品號主檔，補上材質證明、爐號追溯、耐壓測試等品保作業。 看鼎新整合 →](https://rusin-tech.com/integrations/digiwin/)[正航 ERP ### 正航 ERP 外掛整合 讀取客戶、機身序號與各倉庫存，在正航旁邊補上售後維修流程；對正航只讀不寫。 看正航整合 →](https://rusin-tech.com/integrations/chi/) ## ERP 以外，我們也接過這些 | 對象 | 做了什麼 | 案例 | | --- | --- | --- | | 門禁刷卡機 | 不換硬體，讀取門禁系統的刷卡紀錄做自動點名與異常通報 | [校園門禁與宿舍點名](https://rusin-tech.com/industries/campus-access/) | | 條碼標籤機 | 直接送出印表機原生指令（PPLA），連續列印不經 Windows 驅動 | [精密電子製造](https://rusin-tech.com/industries/electronics-manufacturing/) | | Google Maps | 地址轉座標、計算駕車路線里程，查詢失敗時回報明確原因 | [長照車隊調度](https://rusin-tech.com/long-term-care/dispatch/) | | LINE | 司機在 LINE 裡開啟行程頁，查看行程並回報 | [長照派車](https://rusin-tech.com/long-term-care/) | | 政府申報格式 | 依衛福部長照支審系統的格式產出 BD03、DA01 請款檔 | [支審核銷](https://rusin-tech.com/long-term-care/reimbursement/) | | AI 視覺模型 | 先切割與分類，再交給 Claude Vision 讀取欄位；結果標示信心等級，由人逐格確認 | [工業單據辨識](https://rusin-tech.com/industries/document-ocr/) | ## 整合的三個原則 1. **以讀為主，寫入要有紀錄。**能只讀就只讀；必須回寫原系統時，逐案評估並留下操作紀錄。 2. **外掛有自己的資料庫。**行業專屬的資料放在外掛這一邊，不去改原系統的結構，原系統升級時衝擊最小。 3. **使用者不重打。**原系統已經有的訂單、客戶、料號，外掛直接帶出。 鼎新、正航等名稱為各該公司之商標。如新科技提供的是獨立的第三方整合開發，並非原廠或其經銷夥伴。 --- --- title: 長照交通接送派車系統：這一行真正花人力的地方｜如新科技 RUSIN Tech url: https://rusin-tech.com/long-term-care/ description: 長照 2.0 交通接送的難處不在派車，而在每趟車資要拆成補助與自付、各縣市規定不同、月底要依 BD03、DA01 格式向支審系統請款。如新科技（台中）在這個現場做過派車、計費與核銷，寫下動工前該先弄清楚的事。 --- 待過的現場・長照 2.0 交通接送 # 長照派車：真正花人力的不是派車，是月底 我們替長照特約交通接送單位做過從預約、調度、司機回報到政府核銷的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **一趟車有兩個金額。**車資要拆成政府補助和民眾自付。怎麼拆，看個案的補助身分、服務代碼、是不是偏遠地區，還有這個月的額度用了多少。司機在車上就要知道該跟個案收多少。 2. **每個縣市算法不一樣，而且會改。**補助上限、自付比例各縣市各自公告。跨縣市服務的車隊，同一套系統裡要同時跑好幾套規則，公告調整後，舊的趟次還要照舊的算。 3. **DA01 和 BD03 是兩種東西。**一個是往返就醫復健，一個是往返日照中心。計費方式不同，月底要交的報表也不同，不能當成同一種趟次處理。 4. **月底才是壓力最大的時候。**整個月的乘車紀錄要整理成各縣市主管機關指定的格式。靠人逐筆謄寫的話，一個數字錯就可能整份退回。 5. **司機是最重要的資料來源。**實際里程、跳表金額、收了多少自付額、個案有沒有簽名，都在司機手上。司機那一端不順，後面全部都不準。 ## 動工之前，我們會先問的事 想做或想換派車系統的車隊，我們會先問這些。很多答案會直接改變系統該長什麼樣子。 - 你們服務哪幾個縣市？各縣市月底要交哪些報表，現在是誰在做、做多久？ - DA01 和 BD03 的比例大概多少？有沒有日照或居家護理的接送？ - 現在司機怎麼知道今天的行程？怎麼回報里程和收費？ - 個案的補助身分和額度，現在記在哪裡？多久更新一次？ - 哪些個案是固定班次？臨時改期或取消，通常是誰通知誰？ - 調度的人有幾位？如果最熟的那一位請假，誰能接？ ## 我們在這個現場做了什麼 1. **個案與預約**：失能等級、補助身分、輪椅與陪同需求，就醫、復健、日照的預約 2. **里程與計費**：地圖算出行車里程，依縣市與服務代碼套用計費規則 3. **調度派車**：調度台批次指派車輛與司機，並顯示該時段已有任務的車與人 4. **司機執行**：司機在 LINE 行程頁或 App 回報開始與完成，里程、車資、簽名都留下紀錄 5. **支審核銷**：月底依 BD03、DA01 格式產出請款檔，匯入政府支審系統 一趟接送的資料，從預約一路用到月底核銷，中間不重打。 做法的核心只有一句話：**預約時記下的東西，要夠月底用。**所以我們是從核銷報表往回設計的。 - **調度：**一張預約單記下個案、上下車地點、輪椅與陪同需求，地圖算出預估里程，調度指派車與司機。[調度作業的細節 →](https://rusin-tech.com/long-term-care/dispatch/) - **計費：**補助上限與自付比例存成各縣市的規則資料，公告調整時新增一筆，舊趟次照當時的規則。[計費規則怎麼設計 →](https://rusin-tech.com/long-term-care/fare-rules/) - **司機回報：**司機在 LINE 裡開啟行程頁或用 App，回報開始與完成、實際里程與車資，並完成簽名。 - **核銷：**月底依縣市的範本產出 BD03、DA01 的 Excel 請款檔，資料直接來自每一趟的紀錄。[核銷檔怎麼產出 →](https://rusin-tech.com/long-term-care/reimbursement/) ## 如果你也在這一行，可以先想的事 - **先解決月底，再談調度。**調度靠人還撐得住，月底請款才是最先壓垮行政的地方。 - **不要一次換掉所有做法。**先讓幾位司機、一個縣市的報表用起來，穩了再擴大。 - **規則不要寫死。**各縣市的數字一定會變。問清楚你的系統遇到公告調整時，是改設定還是要請人改程式。 - **系統產出的報表，送件前還是要有人看。**系統能拿掉重打的錯，但資料齊不齊、符不符合該縣市的規定，仍要承辦人把關。 **適合來談的人：**長照特約交通接送單位、想跨入長照接送的車隊與租賃業者、需要接送個案的日間照顧中心，以及要替這類單位建置系統、需要有人懂這一行的軟體公司。 ## 常見問題 **長照派車和一般車隊派車差在哪裡？** 一般派車只管車和趟次。長照交通接送多了三件事：每位個案有失能等級與補助身分，車資要拆成政府補助與民眾自付；各縣市的補助上限與自付比例不同，而且會調整；月底要依政府規定的格式請款。這三件事沒處理好，行政人員就得用試算表補。 **BD03 和 DA01 是什麼？** 兩者都是長照給付及支付基準裡的服務代碼。DA01 是交通接送，用於個案往返就醫或復健；BD03 是社區式服務交通接送，用於往返日間照顧中心等社區式服務據點。兩者的計費方式與請款報表都不同。 **我們車隊想做派車系統，應該從哪裡開始？** 從月底請款那一段往回看。先弄清楚你服務的縣市各要交什麼報表、欄位從哪裡來，再回頭決定預約與司機回報時要記下哪些資料。從調度畫面開始做，常常做到月底才發現缺欄位。 **已經有派車軟體了，只想補核銷報表可以嗎？** 可以先看看。只要既有系統的乘車紀錄能匯出或資料庫能讀取，而且當初有記下計費與核銷需要的欄位，就可以只補這一段。缺欄位的話，要先談怎麼從現在開始補記。 **司機年紀比較大，不習慣用 App 怎麼辦？** 這是導入時最常遇到的事，不是技術問題。做法之一是讓司機直接在 LINE 裡開啟行程頁，不必另外裝東西、記帳號。先讓幾位願意試的司機用，其他人看到月底不必補單，會比較願意跟。 這個案例實際用的技術：ASP.NET Core（.NET 8）、SQL Server、Vue 3、LINE、Android、Google Maps。技術跟著問題走，不是重點。 --- --- title: 合作方式：依你現在的處境，短期契約或長期顧問｜如新科技 RUSIN Tech url: https://rusin-tech.com/services/ description: 如新科技（台中）的合作方式不從「要做什麼系統」開始，而從你現在卡在哪裡開始：還沒動工、用 AI 做到一半、做完沒人用、系統太多沒人整理。可以是一次談清楚的短期契約，也可以是每月固定時數的長期顧問。 --- 合作方式 # 不從「要做什麼系統」開始，從你卡在哪裡開始 現在要把一套系統寫出來並不難。難的是決定該不該做、先做哪一段、做完誰來顧。所以我們的合作方式是依你現在的處境分的，不是依產品分的。 還沒開始 ## 先談清楚，再決定做不做 有想法，但不確定該不該做、該做多大，或部門之間還沒有共識。 - 到現場看現在實際怎麼做，包括不照規定的部分 - 看真實的資料，找出缺漏與例外 - 聽各部門的立場，把範圍談到大家能接受 - 排出導入順序：誰先、哪一段先、這次不做什麼 **你會拿到：**一份大家看得懂的範圍與順序。結論也可能是「買現成的就好」或「先不要做」。 **形式：**短期契約，依時數或階段計價 做到一半 ## 接手看一遍，決定怎麼收尾 自己、同事或外包用 AI 做了一半，越改越亂，沒有人敢再動。 - 把現有的程式與資料讀一遍，整理出現況 - 分出哪些可以留、哪些要重來、哪些其實沒人用 - 整理資料結構，讓之後改得動 - 把維護的責任從做的人身上交接出來 **你會拿到：**一套收得起來的系統，和一份接手的人看得懂的紀錄。 **形式：**評估依階段計價，後續可轉長期 做完了 ## 找出為什麼沒人用 系統做好了、功能也都有，現場還是回去用 Excel 和 LINE。 - 到現場看大家實際怎麼繞過系統 - 分辨是資料不可信、流程對不上，還是某個部門沒有好處 - 重新排導入順序，先讓一個部門真的省到事 - 只改必要的地方，不重做 **你會拿到：**一個重新開始的順序，和第一個真的在用的部門。 **形式：**短期契約，依時數或階段計價 越來越多 ## 長期有人看著全貌 系統和小工具一套一套加，沒有人說得清楚有幾套、誰在顧、壞了影響誰。 - 盤點現有的系統、資料與負責的人 - 找出重複的、沒人顧的、出事最嚴重的 - 每次要加新東西時，先一起判斷該不該加、由誰顧 - 日常的維護、修正與因應流程改變 **你會拿到：**一張隨時更新的全貌，和一個出事時找得到的人。 **形式：**長期顧問，按月計價，時數可調整 ## 另外兩種比較明確的工作 ### 在既有 ERP 旁邊補一段 已經在用鼎新、正航或其他套裝系統，但有一段行業專屬的作業放不進去。我們不換掉原有的系統，在旁邊補上那一段，資料直接相通。做法見 [ERP 與既有系統整合](https://rusin-tech.com/integrations/)。 ### 你的人用 AI 開發，我們在旁邊看 公司裡有人想自己用 AI 做，這很好。我們可以在開始前一起把整體想過一次，過程中看方向與資料結構，並在一開始就談好系統之後歸誰顧。為什麼要先談這個，見 [一問一答寫出來的系統，很快就沒人敢改](https://rusin-tech.com/insights/conversation-built/)。 ## 怎麼開始 1. **留言或來信。**說說行業、現在用什麼、卡在哪裡。不需要準備規格書。 2. **第一次談。**我們會問很多現場的問題。談完你會知道這件事大概多大、要不要做。 3. **從一件小事開始。**例如一次需求的釐清，或一次現有系統的盤點。合得來再往下。 4. **每一段都有交付。**文件與原始碼都交給你。要繼續或停在這裡，都清楚。 ## AI 做什麼，我們做什麼 | 工作 | AI | 我們 | | --- | --- | --- | | 了解現況 | 整理訪談紀錄 | 到現場看、問、聽出沒說出口的規則 | | 決定範圍與順序 | 列出選項 | 和你一起決定，包括這次不做什麼 | | 寫程式 | 主要產出 | 拆解任務、審查、要求重寫 | | 確認能用 | 產生測試 | 拿真實的資料和例外去試 | | 上線與之後 | 協助排查 | 負責 | 這個網站本身就是這樣做出來的：由 Claude Code 生成，方向、取捨與事實由我們負責。 ## 不適合找我們的情況 - 只有你自己或兩三個人要用的工具。用 AI 自己做就好。 - 套裝軟體已經夠用。買現成的比客製划算。 - 只想找人把規格照做、越便宜越好。 - 需要大量人力進駐的專案。 - 形象網站、行銷活動頁、手機遊戲。 ## 關於費用 網站上不列價目，因為同一句「做一套派車系統」背後的範圍可以差很多。計價方式只有三種：依時數、按月、依專案階段。第一次談完會給你明確的範圍與報價。 ## 地點 如新科技在台中。 --- --- title: 售後維修管理系統：難的是報價與保固之間的那段等待｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/after-sales/ description: 如新科技（台中）在一家設備代理商的售後現場工作過。RMA 維修工單卡在等客戶確認報價、等原廠判定保固的那段時間，保固與自費要分開核銷，領料要對得上正航 ERP 的庫存。寫下這一行外人不會知道的事，以及動工前該先問清楚什麼。 --- 待過的現場・設備售後維修 # 維修工單真正難的，是停在「等客戶確認」和「等原廠判定」的那幾天 我們在一家設備代理商的現場做過售後維修管理系統，從收件、報價、領料、完工到返還收款。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **進銷存只知道交易結果，不知道案件停在哪一步。**一般進銷存只有銷貨單和庫存單，表達不了「等客戶確認報價」「等原廠判定保固」這類中間狀態。客戶來電問進度，櫃台只能去翻維修部的試算表。 2. **零件常常先拿走，單據晚點才補。**螺旋槳、馬達、電路板這類小件，技師在現場先拿，單據等收工才補。帳上還有貨，架上已經沒料，下一張工單就卡住了。 3. **同一種故障，可能是保固，也可能是客戶自費。**螺旋槳斷裂，要看是原廠責任還是摔機。出保的部分要附料件資料向原廠索賠，自費的部分要開給客戶。兩邊分不清，漏報或漏開都是實際的損失，通常要等月底對帳才看得出來。 4. **機器會換門市送修。**客戶把機體拿到另一間門市，上次換過什麼、保固還剩多久、少了哪些隨機附件，如果查不到，櫃台就只能請客戶從頭講一次。 5. **隨機附件要在收件時登記。**電池幾顆、鏡頭、遙控器有沒有一起來，完工交回時要對得上。收件的人換班以後，這份紀錄是唯一的依據。 ## 動工之前，我們會先問的事 想做或想換售後系統的代理商，我們會先問這些。每一題的答案都會改變系統該怎麼排。 - 維修單現在怎麼流轉？從收件到返還，每一步是誰在記、記在哪裡？ - 報價送出後，客戶通常要等多久才回覆？等待期間，機器放在櫃台還是維修部？ - 原廠保固由誰送出、用什麼格式？出保案件要附哪些料件資料？ - 正航 ERP 的客戶主檔和機身序號，現在是誰在維護？有沒有重複或過期的資料？ - 技師領料現在怎麼登記？有沒有先拿、後補單的情況，多久一次？ - 門市之間會互相送修嗎？同一台機器跨門市的紀錄，現在是怎麼查的？ ## 我們在這個現場做了什麼 做法的核心只有一個判斷：維修單要能停在中間狀態，而且每一次停留都看得出是誰、停在哪一步、接下來會交給誰。 - **收件與機身履歷：**用機身序號查詢，可以跨所有門市找出過去的維修紀錄。客戶與機身資料從正航 ERP 的 `CHI_CustomerView`、`CHI_SrvStkSNView` 讀取，櫃台不必重打。 - **報價與領料：**報價保留歷次版本，每一版都能回頭看。領料作業會顯示各倉的在庫數量與庫存狀態，已經領料的維修單不能直接刪除。突發的退修或誤打的資料，改由獨立的進階調整模式處理。 - **保固與自費分開：**原廠出保狀態分六段，從未出保、出保未送、已送，到審核通過、審核未過與結案。完工分為一般完工與出保完工，出保案件記錄出保案號。 - **返還與收款：**返還作業和收款作業是兩個步驟，各自記錄日期。返還方式、收款方式都由系統內的代碼設定維護，不寫死在程式裡。 目前我們只讀取正航 `CHI_ProductWarehouseQty` 等資料表的庫存與主檔數字，售後的單據存在售後系統自己的資料庫，不回寫正航。讀取與對接的範圍，詳見[正航 ERP 整合](https://rusin-tech.com/integrations/chi/)。 ## 如果你也在這一行，可以先想的事 - **先把中間狀態講清楚，再談系統。**維修單有哪幾個停留點、每個點由誰負責，先用白板排出來。這一步做不清楚，系統只會把混亂存得更整齊。 - **先不要把所有單據搬進系統。**從一個門市、一類設備開始，報價和領料穩了再擴大。 - **保固判定的條件寫成設定，不要寫死。**原廠的保固期和出保條件會改，內部人員要能自己調整。 - **有些事不必交給系統。**技師的現場判斷、跟客戶溝通的語氣，還是要人來做。系統只負責讓這些判斷留下紀錄。 **適合來談的人：**無人機、農用機械、工業儀器等高單價設備的代理商與經銷商，其售後服務部門或維修中心；需要跨門市追蹤機身維修紀錄與保固狀態的業者；想把售後流程和正航 ERP 接在一起、但還不確定從哪裡開始的資訊人員。 ## 常見問題 **正航 ERP 的銷貨單和庫存單，不能直接拿來做維修單嗎？** 銷貨單和庫存單適合記錄交易結果，但維修還要經過收件、報價、等客戶確認、等原廠判定這些中間狀態。比較穩的分工是：正航繼續管客戶主檔、機身序號與庫存數字，售後的維修工單與各階段單據放在售後系統裡。目前我們只讀取正航的資料，不回寫正航。 **售後維修管理系統要從哪裡開始做？** 從收件到報價那一段開始，先弄清楚櫃台要查得到什麼、工單停在每一步時是誰負責。領料與保固核銷接在後面，順序不要顛倒。從領料或月底核銷開始，常常做到一半才發現收件資料不夠用。 **保固與自費核銷可以分開記嗎？** 可以。完工時依維修責任分流：出保案件記錄原廠出保案號與出保狀態，自費案件產生客戶收費明細。分流的條件要以原廠條款與公司的收費規定為準，系統負責的是記錄與分流，不替你判定哪一筆該出保。 **已經用正航 ERP，只想補 RMA 維修系統可以嗎？** 可以先看。要確認正航裡的客戶主檔與機身序號乾淨不乾淨、讀取權限夠不夠，以及售後的哪些單據將來是否需要回寫正航。回寫會牽涉到正航的銷貨與庫存帳，應該另外評估，不要和流程改版一起做。 這個案例實際用的技術：C# 與 .NET Framework、Windows Forms、DevExpress、Microsoft SQL Server、Dapper，正航 ERP 唯讀對接。技術跟著問題走，不是重點。 --- --- title: 學校宿舍點名系統：不換門禁機，從刷卡紀錄自動點名｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/campus-access/ description: 學校宿舍點名的難處，不在刷卡機本身，而在刷卡紀錄能證明什麼。如新科技（台中）為一所大專院校的宿舍做過校園門禁整合，不更換既有刷卡機，從門禁資料庫自動點名並寄出缺勤名單。這一頁寫動工前該先弄清楚的事。 --- 待過的現場・大專院校學生宿舍管理 # 學校宿舍點名系統：刷卡紀錄很完整，但它證明不了學生在哪裡 我們為一所大專院校的學生宿舍做過點名與警示系統，走校園門禁整合的路子：不換既有刷卡機，直接讀取門禁資料庫的紀錄。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **刷卡只能證明人在機器前。**刷卡機記下的是卡號、時間與機器位置。學生刷完往哪裡走，紀錄不會寫。把「刷過卡」直接當成「人已經在宿舍」，是最常見的誤會。 2. **門禁設備與資料庫都不是我們的。**通常由廠商安裝維護，資料庫多半封閉，讀取方式與授權要先談，且不能影響門禁本身的運作。 3. **點名用哪一台機器，要先講定。**不同位置的刷卡機，意義不同，不能只看機器的名稱。 4. **點名時段與名冊一定會變。**晚點名的時間、住宿名單、臨時請假，每天都在動。寫死在程式裡，學校就得每次找廠商。 5. **日期怎麼算，要先說清楚。**晚歸的紀錄算前一天還是當天，連續沒刷卡以整天計還是以小時計，不先定，同一份資料會得出不同名單。 ## 動工之前，我們會先問的事 每一題的答案，都會改變系統該怎麼做。 - 點名要以哪一台刷卡機為準？這台機器只設在大廳嗎？ - 點名時段是固定的，還是每天、每學期都不同？誰有權限改？ - 名冊從哪裡來？學務的學生資料與門禁系統裡的一致嗎？ - 門禁資料庫能不能開唯讀帳號？廠商願意配合到什麼程度？ - 缺勤與異常名單寄給誰？夜裡有沒有人實際在看信？ - 晚歸、外宿、請假的學生，現在怎麼登記？有沒有書面紀錄可以對照？ ## 我們在這個現場做了什麼 做法的核心是**不動既有設備，只在旁邊讀資料、算結果**。系統給的是提醒，判斷留給宿舍管理人員，目的是協助他們掌握出入狀況。 - **門禁資料：**定時讀取門禁資料庫的原始刷卡紀錄，包含刷卡時間與刷卡機編號。刷卡機不更換、不加裝。 - **點名判定：**點名機與時段存在後台參數裡可以調整。時段內在指定的點名機刷卡的學生記為已點名，時段外的刷卡不計入當晚結果。 - **連續無刷卡通報：**點名結束後，檢查名單內的學生前兩個整天是否有任何刷卡紀錄。兩天都沒有的，列入缺勤警示。 - **排程寄信與後台查看：**點名失敗名單與缺勤警示依排程經 SMTP 寄出。點名成功、點名失敗與缺勤警示也都能在後台查詢。 ## 如果你也在這一行，可以先想的事 - **先不要讓系統判斷學生去了哪裡。**刷卡紀錄只是線索，當成定論，會讓人跳過該查的事。 - **先確認讀得到資料，再談功能。**資料庫讀不到，點名規則再好也派不上用場。 - **不必用系統取代夜間巡視。**系統排出名單，查證仍由人處理。 - **名單含學生個資，收件對象要先定。**誰能收到、保存多久，上線前講清楚。 **適合來談的人：**大專院校的學務處、總務處與宿舍管理單位，以及需要為校園門禁做整合或二次開發的弱電工程商與系統整合商。 ## 常見問題 **學校宿舍點名系統需要更換現有的刷卡機嗎？** 不需要。系統讀取既有門禁系統資料庫裡的刷卡紀錄，刷卡機維持原狀。能不能讀、要怎麼讀，要先確認該門禁系統的資料庫結構與授權。 **現有門禁系統不好加規則，可以做門禁系統二次開發嗎？** 可以先評估。系統只讀取門禁資料，產生點名與缺勤結果，不改動門禁硬體與控制功能。是否可行，要先確認該系統的資料庫與授權。 **學生刷完卡就離開，系統能確定他有沒有回寢室嗎？** 不能確定。刷卡紀錄只能證明學生在那台刷卡機前刷過卡。系統給的是提醒，最後由宿舍管理人員查證。 **宿舍想做刷卡自動點名，應該從哪裡開始？** 先問清楚點名結果給誰看、何時要看，再確認門禁資料能不能讀。先在一個棟別試用，比一次全校上線穩。 這個案例實際用的技術：ASP.NET Core（.NET 8）、Dapper、SQL Server、Angular、Serilog、SMTP。技術跟著問題走，不是重點。 --- --- title: 材質證明系統：鑄造爐號追溯與 EN 10204 3.1 材證｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/casting-mtr/ description: 精密鑄造與工業閥門外銷的材證難在哪裡？一張材證要同時對上閥體等部件的爐號，化學成分與機械性質要比對規範上下限，耐壓數據也要跟鼎新 ERP 製令接在一起。如新科技（台中）在這個現場做過材質證明系統，寫下動工前該先弄清楚的事。 --- 待過的現場・精密鑄造與閥門外銷 # 材質證明的難處不在填表，而在一張材證要同時對上好幾個爐號 如新科技在台中替一家精密鑄造與閥門外銷廠做過材質證明系統，與鼎新 ERP 整合。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **一張材證，常要對好幾個爐號。**閥體、閥蓋、閥球、閥桿常是分開鑄造，各自有爐號。材證要說清楚每個部件來自哪一爐，不能整張寫成一個號。 2. **數字要跟規範上下限對過。**化學成分與機械性質逐項比對規範，超出的值要在製作材證前就被看見，而不是等客戶來退貨才發現。 3. **耐壓紀錄也是材證的一部分。**殼體與閥座的測試要記下壓力與持壓時間，判定結果跟著材證走。少了這兩個數字，材證就不算完整。 4. **製令改了，材證表頭要跟著改。**常見的麻煩是製令拆單或改數量，表頭沒有同步，客戶收到的數字就對不上訂單。 5. **多年後的回查，取決於當初怎麼歸檔。**外銷客戶常在出貨很久以後追問某一批的材證。紙本夾在倉庫裡，找起來只能靠人記得。 ## 動工之前，我們會先問的事 想做材證系統或想換掉現在做法的廠，我們會先問這些。每一題的答案都會影響系統該怎麼長。 - 你們出貨的閥門有哪些系列？各部件是自己鑄造，還是外包？ - 客戶合約要求哪一種材證格式與規範版本？品保手上是哪一版？ - 化學成分與機械性質的上下限現在放在哪裡？規範改版時由誰更新？ - 製令在鼎新 ERP 裡常見拆單或改數量嗎？改了之後，材證是誰去改？ - 化驗數據與拉伸試驗，現在是紙本、Excel，還是儀器直接輸出？ - 耐壓測試由誰記錄、誰簽名？材證要不要依箱號或序號歸檔？ ## 我們在這個現場做了什麼 做法的核心是一個判斷：材證資料應該從製令、爐號數據與測試紀錄三個來源接起來，由系統帶出，而不是由品保一欄一欄抄進範本。 - **製令從鼎新帶入：**輸入製令後，客戶、品號、訂單號與生產數量從鼎新的 `MOCTA`、`COPTC`、`COPMA`、`INVMB` 讀出，不必重打。[鼎新 ERP 整合怎麼接 →](https://rusin-tech.com/integrations/digiwin/) - **爐號與規範比對：**製令上登錄閥體與閥蓋的爐號，材證依爐號帶出化學成分十五項、機械性質六項與衝擊四項。數值超出規範上下限時以紅字標示。 - **耐壓與材證輸出：**殼體、閥座、氣密等測試項目各記下壓力與持壓時間，連同判定寫入材證，並以 EN 10204 3.1 格式輸出。 - **裝箱與回查：**裝箱時序號與箱號綁在一起，箱號不可空白。事後要查某一批，可以從查詢畫面調出材證。 ## 如果你也在這一行，可以先想的事 - **先把製令和爐號的對應弄清楚，再談系統。**如果現場自己說不清同一個製令對到哪一爐，系統只會把混亂存得更快。 - **先不要一次做完所有規範與格式。**從客戶最常要的一種格式開始，用順了再加其他版本。 - **規範版本與等級，不必交給系統判斷。**採用哪一版、哪個等級，仍由品保依合約決定。系統負責的是把上下限放在對的地方。 - **材證送出前，仍要有人看過。**系統能拿掉重打的錯，但數字是否符合合約，還是要由品保簽名負責。 **適合來談的人：**精密鑄造廠、工業閥門製造與外銷廠，以及需要附 EN 10204 材質證明的金屬零件製造商；品保與文管部門想把材證流程理清楚的人，也可以來聊。 ## 常見問題 **材質證明系統和用 Excel 做材證，差在哪裡？** 差在資料來源。Excel 做法要把製令、爐號數字與測試紀錄逐欄抄進範本，抄錯一格整份就要重做。系統把這三處接起來，製作材證時直接帶出，品保的工作變成核對。 **鼎新 ERP 的製令可以直接帶進材證嗎？** 可以。輸入製令單號後，客戶、品號、訂單號與生產數量會從鼎新 ERP 讀入材證表頭，不必重打。 **EN 10204 3.1 材質證明書要附哪些內容？** EN 10204 3.1 是一種檢驗證明書類型，通常附上材料的化學成分、機械性質與測試結果。實際要放哪些項目，仍以客戶合約為準。 **材證導入應該從哪裡開始？** 從最耗人工的兩段開始：製令表頭如何帶入，以及爐號數字如何對應規範上下限。先讓一位品保試用幾張材證，確認格式與簽核都能接受，再擴大到其他製令。 這個案例實際用的技術：C# 與 .NET Framework（Windows Forms）、DevExpress、Dapper、Microsoft SQL Server。技術跟著問題走，不是重點。 --- --- title: 工業單據辨識：AI 會讀錯，系統要讓錯被看見｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/document-ocr/ description: 工地與工廠的紙本單據，難的不是把字讀出來，而是讀錯的那一張沒人發現。如新科技（台中）在工業單據辨識的現場做過一頁多單切割、先分類再讀取與人工複核，這一頁寫這一行外人不會知道的事，以及動工前該先問清楚什麼。 --- 待過的現場・工地與工廠 # 工業單據辨識真正難的，不是讀出字來，而是讓讀錯的那一張被看見 我們在工地與工廠的單據現場做過一套辨識系統，讓 AI 負責讀字，讀之前的切割與分類、讀之後的確認，都是我們設計的。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **一張紙上常常不只一張單。**磅單三四張貼在同一張 A4 上很常見，印表機一次吐出好幾份同版型的單據也很常見。先切開，才能一張張對應到一筆紀錄。切錯一次，後面的數字就全部跟著錯。 2. **原圖本來就不乾淨。**工地的單據多半是手機隨手拍，紙面歪、有陰影與摺痕。點陣印表機加上複寫紙，墨色淡、筆畫斷，0 跟 8、1 跟 7 看起來很像。 3. **同樣叫送貨單，版型可能完全不同。**同一家廠商換了印刷廠，欄位位置就跑了。混凝土送貨單、過磅單、水電費單的欄位更是各自不同，先判斷是哪一種，才知道該去哪裡找數字。 4. **數字之間的關係，單據上通常不寫。**淨重其實是總重減掉空車重，但紙上只印一個結果。登打的人通常不會逐筆去算，錯誤就這樣一路進到請款與計價。 5. **最後那個人，才是真正的關卡。**送進請款或計價之前，總要有一位承辦人對照原圖看過。系統能做的，是讓他看得快、看得出哪裡可疑，而不是替他決定數字對不對。 ## 動工之前，我們會先問的事 動工前，我們會先問下面這些。每個答案都會改變系統怎麼做。 - 單據是怎麼進到系統的？拍照、掃描，還是有人直接打字？一天大約幾張？ - 同一種單據有幾種版型？印刷廠或表單換過幾次？ - 一張紙上通常貼幾張？是要切開一張張登，還是整張一起看？ - 讀錯的數字，現在是在哪一步、由誰發現的？ - 這些數字最後流向哪裡？請款、計價，還是 ERP？接收的人能不能接受「標示異常、由人決定」？ - 有沒有哪些欄位只有老師傅看得懂，寫在備註或角落的手寫字裡？ ## 我們在這個現場做了什麼 做法的核心是：**AI 只負責讀字，什麼時候讀、讀完怎麼擋、讀錯時誰看得見，是我們設計的。**系統的可靠來自後面這幾道設計，不是來自模型不會錯。 - **先切再讀：**由人指定一頁要切成幾列幾欄。系統找出頁面上有字的範圍，等分成格子，每一格存成獨立影像，空白的格子會被標出來。 - **先判斷是哪一種單據，再依該類型讀：**每一格先判斷單據類型，再套用該類型的提示詞與欄位定義，請 Claude Vision 讀取。類型清單與欄位定義可以在系統內維護。 - **讀出來要標信心，低信心不能直接用：**每一筆結果都帶有高、中、低的信心等級。等級為低時，畫面會以紅色警示「請勿直接使用」，要求人對照原圖逐欄核對，而不是把猜出來的數字直接交出去。 - **由人決定哪一格算數：**切割後，人可以勾選要納入或排除的格子。辨識完成後，每一格都要按下確認或拒絕，拒絕時要寫原因。原始檔、切出的格子與模型的原始輸出都保留，回頭查得到。 ## 如果你也在這一行，可以先想的事 - **先不要追求全自動。**能讓人一眼看出哪裡讀錯，比少點幾次確認更重要。確認這一步省不掉，只能讓它變快。 - **先不要把所有單據一次做完。**挑一種量最大、版型最穩的，例如混凝土送貨單，讓承辦人先習慣，再加過磅單或水電費單。 - **有些事不必用系統解決。**量不大時，逐張人工核對可能比導入系統更省事，先把量算清楚。 - **把「誰看最後那一關」寫清楚。**系統會標出異常，但決定數字算不算數的人必須明確。不能讓大家都以為是別人在看。 **適合來談的人：**營造工程單位、預拌混凝土廠、有地磅與大量水電費單據的製造業與公用事業單位，以及想把紙本單據接進既有系統、需要有人懂現場的開發團隊。 ## 常見問題 **AI 單據辨識會讀錯嗎？讀錯了怎麼辦？** 會。字跡模糊、版型不熟、數字長得很像時都可能讀錯，我們不承諾每個字都對。系統的做法是讓錯誤被看見：信心低的結果會標成紅色，原圖與讀出的欄位並排，每一格都要有人按下確認或拒絕，才算完成。 **照片拍得歪、有陰影，還能讀嗎？** 要看原圖本身。字跡還清楚，讀得出來就讀；字糊到連人都要猜，讀出來的結果會被標成低信心，請人對照原圖逐欄核對，不會硬給一個數字。拍照時盡量讓整張紙入鏡、光線平均，能省下很多複核的時間。 **一張 A4 上貼了三四張過磅單，怎麼切？** 上傳時由人指定要切成幾列幾欄，系統找出頁面上有字的範圍後等分成格子，每一格存成獨立影像，空白的格子會標出來。切割是依格數等分，不是自動找出每張紙的邊界，所以紙貼得不整齊時，要在切割畫面確認每一格有沒有切到別張的字。 **工地或工廠要導入，應該從哪裡開始？** 從量最大、版型最穩的一種單據開始，例如混凝土送貨單或過磅單。先拿近三個月的實際單據試讀，看哪些欄位最常讀錯，再決定要不要上線。上線初期保留紙本流程並行，讓承辦人有退路。 這個案例實際用的技術：Python（FastAPI）、Claude Vision、Pillow 與 NumPy 做影像處理、Angular、SQL Server。技術跟著問題走，不是重點。 --- --- title: 電子廠 ERP 客製：工程變更、品管與條碼標籤現場｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/electronics-manufacturing/ description: 如新科技（台中）在一家精密電子零件製造廠的現場，做過工程變更、IQC IPQC FQC 品管與條碼標籤列印的系統。這一頁不列功能，寫的是這一行的難處，以及動工前該先弄清楚的事。 --- 待過的現場・精密電子零件製造 # 電子廠的工程變更，難的不是改設計，是改完之後還有多少舊料在線上 我們在一家精密電子零件製造廠的現場，做過工程變更（ECR、ECN）、IQC IPQC FQC 品管與條碼標籤列印的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **設計改了，產線不一定知道。**研發發出新版，採購單、料架與班長的認知不一定同時換版。舊料繼續組裝，常要到檢驗或客訴時才發現。 2. **停用和報廢是兩件事。**料號停用，只是不再下新單。手上的庫存還要決定消化、退回或報廢，報廢要算數量、找倉庫、留紀錄。 3. **檢驗員看到的常是實物，不是歷史。**同一料號過去出過什麼不良、哪批特採過，多半散在各班的紙本單或個人試算表裡，同樣的瑕疵會一批一批再出現。 4. **標籤是批號追溯的一部分。**料盤、外箱與序號標籤要能回查批次與來源。連續列印時格式跑版或停機重印，批次對應就容易斷掉。 5. **碳排數字要先有重量和運距。**客戶要求出貨附碳足跡，但料件重量與供應商運距記在哪裡，多數工廠一開始都沒整理過，第一次通常是月底手算。 ## 動工之前，我們會先問的事 想做或想換工程變更與品管系統的工廠，我們會先問這幾件。每一題的答案都會改變系統的設計。 - 工程變更一年大約幾次？每次影響的是整個料號，還是某幾批、某幾站？ - 舊料停用後，現在是誰通知採購與車間？庫存是誰決定消化、退回還是報廢？ - 檢驗員開單時，同料號的不良紀錄查得到嗎？現在是翻紙本，還是問老師傅？ - 標籤要貼在料盤、外箱，還是每一個序號？印表機目前是怎麼接的？ - 客戶要的碳排報表依哪一套計算方式？料件重量與運距現在記在哪裡？ - 哪一站的不良最常出現？那一站的檢驗紀錄是誰填、填在哪裡？ ## 我們在這個現場做了什麼 做法的核心只有一個判斷：**料號是所有環節共用的鑰匙，變更、檢驗、列印與碳排都以料號累積紀錄。**所以各模組讀的是同一份料號資料，不是各自維護一張清單。 - **工程變更：**申請時可選設計變更、零件耗完停用、替代、報廢等原因，申請單上看得到庫存數量。停用的料號會寫入料號主檔；報廢作業會檢查庫存是否足夠、是否集中在單一倉庫。 - **品檢：**IQC、IPQC、FQC 各有檢驗作業。IQC 作業頁內附同料號的歷史紀錄分頁，不良與特採紀錄在開立檢驗前就能看到。 - **條碼與標籤：**直接呼叫 Argox 條碼機的 SDK，送出 PPLA 指令列印標籤，標籤內容由系統資料產生。 - **碳排：**採購收料與外包收料的碳排報表，以料件重量乘數量，再乘供應商運距計算；銷貨作業也有對應的碳排報表，重量資料有缺時可以重新計算。 ## 如果你也在這一行，可以先想的事 - **先定停用之後怎麼處理，再談系統怎麼擋。**規則沒有人定，系統擋下來也只會換成另一種紙本流程。 - **歷史資料從不良最常出現的料號開始整理。**檢驗員先看得到，才會真的去用，不必一次整理全部料號。 - **標籤機先挑一條線試。**格式與序號規則穩了，再推到其他線，先不要一次換掉所有機台。 - **特採與報廢的判斷不必交給系統。**這些仍由品保主管決定，系統的工作是把決定與理由留下紀錄。 **適合來談的人：**精密電子零組件製造廠、電子組裝與代工廠的生產、品保與採購主管，以及要替這類工廠建置系統、需要有人懂工程變更流程的軟體公司。 ## 常見問題 **電子廠 ERP 客製和套裝 ERP 差在哪裡？** 套裝 ERP 的流程由廠商定義，工廠常得調整習慣去配合。客製開發會先問清楚工程變更、檢驗與列印的規則，再寫進系統。前期的訪談與驗收比較花時間，但之後的規則就不必全靠人記。 **工程變更之後，舊料會不會還在下單或領料？** 系統可以把停用的料號寫進料號主檔，工程變更時也能列出庫存數量，並在庫存足夠且集中於單一倉庫時作報廢處理。採購單與領料單遇到停用料號要不要擋下，要先和你們的採購與領料流程對過，再決定規則。 **IQC 檢驗時，檢驗員看得到同料號的不良紀錄嗎？** IQC 作業頁內有同料號的歷史紀錄分頁，檢驗員開始檢驗前，就能看到過去的不良與特採紀錄。IPQC、FQC 的查詢方式要依各段的流程確認，動工前會一起對過。 **電子廠的 ERP 應該從哪裡開始？** 通常從最常出問題的那一段開始，例如工程變更後的舊料停用，或某一站的檢驗歷史。先讓一條線或一類料號用起來，確定資料對得上，再擴大到其他線與其他料號。 這個案例實際用的技術：C# / .NET Framework（Windows Forms）、Microsoft SQL Server、Argox 條碼機 SDK。技術跟著問題走，不是重點。 --- --- title: 系統家具拆料系統：板材裁切尺寸為什麼不能心算｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/furniture-cutting/ description: 如新科技（台中）在系統家具工廠的拆料現場做過板件展開與五金配套。這一行難的不是算一個數字，而是板厚、背板溝槽、L 櫃與推拉門的例外，多半只存在老師傅的記憶裡。這一頁寫動工前該先問清楚的事。 --- 待過的現場・系統櫥櫃與客製家具 # 系統櫃算料：難的不是算數，是板厚、溝槽和那些例外 我們在系統家具工廠的拆料現場做過板件展開與五金配套的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **同一個櫃，每片板要扣的不一樣。**側板、頂底板、層板和背板各有自己的扣減方式。頂底板的寬度要扣掉兩片側板的厚度；背板要嵌進溝槽，溝槽深度不同，背板的裁切尺寸就跟著變。只要有一邊少扣，裁下來就裝不進去。 2. **板厚不只一種。**櫃體常見的板厚有 18mm 與 25mm，而且同一個工廠裡，不同櫃型、不同門板可能各用各的規格。換了板厚，扣減值就整組要換，不是改一個數字。 3. **L 型轉角和推拉門的規則，常常只在老師傅腦子裡。**L 型櫃要避開轉角的交接位置，推拉門要扣掉兩扇門片的重疊量，鋁抽和吊褲架又另有五金的安裝間隙。這些規則很少寫在圖面或規格表上，要問到人才知道。 4. **吊櫃和地櫃的五金算法不同。**KD 扣件的朝向、鉸鏈的顆數，要看門片的高度與櫃體是吊櫃還是地櫃。同一種五金，裝在不同位置，數量和配置的邏輯就不一樣。 5. **裁完的板子容易分不清楚。**同一批次裡常有尺寸一樣的板。貼標不清楚，封邊與排鑽的作業員只能靠位置猜哪一片屬於哪個櫃，錯裝的板就要重來。 ## 動工之前，我們會先問的事 想做或想換拆料系統的工廠，我們會先問這些。每一題的答案，都會改變系統該怎麼算。 - 你們的櫃體有哪幾種？一般吊櫃、地櫃、L 櫃、抽盒櫃、推拉門各佔多少？ - 目前用的板厚、封邊條與背板溝槽有哪幾種規格？各櫃型是不是共用同一套？ - 老師傅算料時，有哪些例外沒有寫在圖面上？這些規則現在是誰記得？ - 五金的數量現在是依什麼算？鉸鏈、KD 扣件、滑軌各自對照哪一份規格？ - 裁完的板子現在怎麼分辨櫃號？貼標或記號是哪一站在做？ - 拆料單會交給哪些部門？裁板、領料與封邊各用哪一份資料？改了尺寸，要通知誰？ ## 我們在這個現場做了什麼 做法的核心只有一句話：**把板件的扣減規則從師傅的手上移到參數裡，規則改了只需要改一處。** - **櫃體展開：**輸入櫃體的高、寬、深與櫃型，系統依該櫃型的規則列出每一片板件的裁切尺寸。側板、頂底板、固定層板、活動層板、背板與抽屜各有獨立的公式。 - **櫃型分組：**一般櫃體、L 櫃、抽盒櫃的內外兩種、鋁抽、門板、推拉門、造型門、枱面、分隔抽與吊褲架，各自是一組獨立的規則，不會被當成一般櫃體處理。 - **五金配套：**依 KD 扣件、鉸鏈、滑軌與木筍的規則算出數量，再匯整成備料清單，採購與領料看的是同一份數字。 - **工單與板件標籤：**拆料結果可以列印板材排版明細、五金備料單，並以標籤列印出每片零件的名稱、尺寸與數量、色號規格，以及案名與備註。 ## 如果你也在這一行，可以先想的事 - **先把扣減值寫成一張表。**寫程式之前，先讓師傅對過每個櫃型用的板厚、封邊與溝槽數值。規則能寫在紙上，系統才寫得出來。 - **先不要把所有例外都寫進系統。**一年只遇到兩次的櫃型，先用人工處理並記下來，確定是常態再做。 - **有些事不必用系統解決。**一張單只做一次的特殊造型，用師傅的圖面與手算就好，硬接進系統反而增加維護的負擔。 - **先看現場找板和裝錯邊的情況，再決定標籤做到哪一步。**如果問題出在算料，先修算料；如果問題出在裁完之後，再談貼標與追溯。 **適合來談的人：**系統櫥櫃與客製家具製造商的生管與拆料部門、想把算料規則留下來的老師傅與廠長，以及要替這類工廠開發系統、需要產業知識的軟體公司。 ## 常見問題 **系統櫃板材裁切尺寸怎麼算？** 從櫃體外觀的高、寬、深出發，逐片扣掉板材厚度與其他規定的數值，得出每片板的裁切尺寸。側板、頂底板、層板與背板扣的項目不同，不能全部套用同一個減法。 **系統櫃算料要怎麼做，才不必每張單都從頭算？** 把每個櫃型的扣減規則寫成一組參數，輸入櫃體尺寸後由規則展開板件，再由規則算出五金數量。規則改了只需要改參數，不必逐張重新手算。 **板件標籤要貼哪些資訊，才不會裝錯？** 至少要寫出櫃號、零件名稱、裁切尺寸、封邊方向與板材色號。封邊與排鑽的作業員只看標籤，就能確認板件屬於哪一個櫃、哪一邊要封。 **工廠已經有老師傅在算料，系統要從哪裡開始？** 先從最常見的一般吊櫃與地櫃做起，讓師傅對過扣減值與算出的尺寸，再補 L 櫃、推拉門這類例外。新舊算料並行一段時間，比一次換掉所有做法穩。 這個案例實際用的技術：C# / .NET Windows Forms、Microsoft SQL Server、DevExpress XtraReports。技術跟著問題走，不是重點。 --- --- title: 加工業 MRP 系統：料分兩階走，還會跑到外面｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/metal-mrp/ description: 如新科技（台中）待過一家金屬加工與外銷組裝廠的現場。這一行的難處在鐵材依重量計價、零件先加工再送外包烤漆、回廠總裝，還有每個國外客戶的箱嘜格式不同。本頁不列功能，寫動工前該先弄清楚的事。 --- 待過的現場・金屬加工與外銷組裝 # 加工業 MRP 真正難的，是料不在廠裡的那段時間 我們在一家金屬加工與外銷組裝廠的現場，做過生管、採購與外銷這幾條線的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **鋼材進貨與領料，單位常不一樣。**鋼材多半依公斤進貨，產線卻可能依片或件領料。單價帶小數三四位，金額每次都有尾差，進位方式要先定。 2. **零件加工到一半，就離開了工廠。**半成品常整批送外包烤漆，回廠才總裝。料在外面，工單卻還開著。 3. **採購料號與生產料號是兩套代碼。**供應商用他們的品號出貨，廠內用生產品號領料。對照表沒人維護，就會錯料、重複買。 4. **每個國外客戶的箱嘜都不一樣。**版面、條碼與箱號格式各家規定，同一家客戶換批次，要求也可能跟著變。 5. **成本其實在收料時就定了大半。**單價與重量在進貨當下已經決定，很多工廠卻要等月底對帳才看得到。 ## 動工之前，我們會先問的事 想做或想換 MRP 的工廠，我們會先問這些。答案通常會改變系統該怎麼設計。 - 鋼材進貨、領料、報價各用什麼單位？ - 哪些零件會送外包？送出去以後，現在是誰在追？ - 採購料號與生產料號的對照是誰在維護？供應商換料號時，怎麼通知你們？ - 外銷箱嘜是客戶給範本，還是你們自己排？每批要改哪些欄位？ - 半成品是先入庫再總裝，還是直接上線？ - 生管或採購最熟的那位請假，誰看得懂目前的工單和委外單？ ## 我們在這個現場做了什麼 做法的核心只有一句：**工單照加工順序分兩階，料在廠外的每一段，都要有人看得到。** - **雙階工單：**零件加工與總裝拆成兩階工單，需求運算時兩階連動，採購依淨需求展開，不必另外對表。 - **委外追蹤：**委外的料用轉外加工單與調撥記錄送出去。外包件的需求明細與數量統計查得到，烤漆另有進度管理。 - **鐵材計價：**鐵材價格另外設定。以捲採購的依實際公斤數計價，單價位數與進位依設定，鐵材對帳明細可以單獨查。 - **料號與外銷單據：**廠商料號與客戶料號分開維護，進貨時帶出生產料號。嘜頭依客戶與產品指定版型，裝箱單由出貨資料產出。 ## 如果你也在這一行，可以先想的事 - **先把單位定下來。**進貨、領料、報價各用什麼單位，寫成一張表再談系統。單位沒定，系統只會替每個人留一套算法。 - **委外先從一種製程開始。**先確認送出與收回對得上，再決定其他外包製程要不要進來。 - **料號對照不必一次對完。**先對最常買的料，其餘用人工對照表過渡。這一段不一定要系統來做。 **適合來談的人：**金屬加工與組裝廠的生管、採購與外銷業務，以及需要懂現場流程、替這類工廠開發系統的軟體公司。 ## 常見問題 **加工業 MRP 系統應該從哪裡開始導入？** 從採購與生管每天手動對照、手動查詢的那一段開始，通常是料號對照或委外在外數量。先讓一個部門真的得到好處，其他人才會跟進。一次換掉所有流程，通常不容易撐下去。 **鐵材依公斤進貨、依片領料，系統怎麼算？** 先定義進貨單位與領料單位之間的換算，再決定單價保留幾位小數、用哪種進位方式。收料時就算出金額，不必等月底對帳才發現尾差。 **零件送外包烤漆後，怎麼知道還有多少在外面？** 委外出去時記下數量與對象，回廠收料時與出去的數量對照，沒回來的就是還在外面的數量。系統可以隨時查，不必靠電話一家家問。 **外銷嘜頭每個客戶格式不同，要怎麼處理？** 每個客戶的版型各自存起來，訂單號、箱號、件數、淨重等欄位從資料帶入。版型改動在報表設計器裡做，不必每次找人改程式。 這個案例實際用的技術：C# 與 .NET Framework 4.8、Windows Forms、DevExpress、SQL Server。技術跟著問題走，不是重點。 --- --- title: 國貿 ERP 系統：一張外銷訂單，從背對背採購到發票利潤｜如新科技 RUSIN Tech url: https://rusin-tech.com/industries/trading/ description: 如新科技（台中）在一家進出口貿易商的現場，做過背對背採購、發票利潤與出口佣金。這一頁寫的是一張外銷訂單改量時，採購、單證與佣金會一起牽動的事，以及動工前該先問清楚什麼。 --- 待過的現場・國際貿易進出口 # 進出口貿易管理系統真正難的，是客戶改量之後，後面每一張單都要跟著對上 我們在一家進出口貿易商的現場，做過從訂單、背對背採購、出貨單證到發票利潤與佣金結算的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **接單的那一刻，採購就已經開始。**客戶的正式訂單確認後，業務通常要馬上向供應商下單。下單之後客戶才改量或改規格，採購端若沒有人接到消息，照舊的單子就會變成庫存，或是得額外處理取消。 2. **一張發票的利潤不在售價上。**售價常是外幣，進貨成本可能是台幣，運費、保險費與報關雜費又各自計價。出貨當下很少有人算得出這筆賺多少，往往要等月底結帳才看得到。 3. **佣金跟著出貨數量走。**代理商佣金多半以明細行計算。因短裝或溢裝改了數量，每一行都要重算。人工改很容易漏掉幾行，之後就成了對帳時的爭議。 4. **每個買主與海關的單證格式都不同。**商業發票、Packing List 的欄位，以及箱嘜的寫法，各買主各有要求。逐張用 Excel 謄寫，料號或件數打錯，貨物就可能卡在通關。 5. **客戶索賠與退換，通常不改舊單。**多半另開貸項通知單（Credit Note）沖帳，供應商端的扣款則用借項通知單（Debit Note）。這些單據要能追回原本的出貨。 ## 動工之前，我們會先問的事 每一題的答案，都會改變系統該怎麼接。 - 你們的訂單大多是固定量，還是常改量？改量通常是客戶提出，還是公司內部調整？ - 一張發票通常有哪些幣別？運費、保險費與報關雜費，是每張單自己算，還是月底統一分攤？ - 佣金怎麼約定？是按售價比例、按件，還是按單價？出貨數量改了，佣金以誰的數字為準？ - 你們服務的買主與海關，各自要求哪些單證格式？箱嘜是誰設計，誰負責核對？ - 採購單開出去之後，客戶改量的消息現在是怎麼傳到採購的？ - 月底的利潤與佣金對帳，現在是誰在做、用什麼工具？ ## 我們在這個現場做了什麼 做法的核心是一個判斷：訂單確認之後，採購、出貨、單證與佣金都從同一筆資料往下走，改了一處，其他地方看得到。 - **訂單到採購：**訂單經覆核鎖定後，需要對外採購的明細可以拋轉成採購單，規格與數量從訂單帶過去，不必重新抄寫。 - **出貨前的利潤：**Commercial Invoice 的售價、進貨成本與其他費用放在同一個畫面，外幣依匯率換算成台幣後，算出這張發票的毛利。 - **佣金重算：**出貨明細的數量或單價一改，該行佣金就依設定的小數位規則重新計算，不必等月底再人工核對。 - **單證與折讓：**Packing、Credit Note、Debit Note 各有對應作業，箱嘜由嘜頭編輯器設定，都從同一筆出貨資料產生。 ## 如果你也在這一行，可以先想的事 - **先不要急著把所有單證格式都做進系統。**常用的買主通常只有幾家，先做最常用的兩三種，其他的用既有範本，等真的需要再補。 - **先確定誰負責通知採購。**改量的決定通常在業務，但採購要知道。消息怎麼傳、傳給誰，先定好。 - **佣金規則放在設定裡，不要寫死在程式裡。**代理商的約定常會調整。 - **系統算出來的利潤，仍要會計看過。**雜費怎麼分攤、匯率用哪一天，是公司的決定。 **適合來談的人：**進出口貿易商、三角貿易與品牌代理商、需要自行出口的製造商外銷部門，以及要替這類客戶建置系統、需要有人懂國貿流程的軟體公司。 ## 常見問題 **國貿 ERP 系統和一般 ERP 差在哪裡？** 一般 ERP 多以庫存與應收應付為主，訂單、採購與出貨各自獨立。國際貿易還要處理多幣別報價、背對背採購、運費與保險等附加費用、佣金拆帳與多種單證格式。這些資料若沒有放在同一套系統裡，業務與會計就得在試算表之間來回搬資料。 **背對背採購要怎麼跟客戶訂單連動？** 訂單經過覆核鎖定後，需要對外採購的明細可以拋轉成採購單，規格與數量從訂單帶過去，不必重新抄寫。客戶之後改量，已開出的採購單要不要跟著調整，目前仍由人判斷，動工前要先問清楚改量的消息會傳到誰。 **Commercial Invoice 的利潤怎麼算？** 系統把發票上的售價、供應商進貨成本，以及其他費用放在同一個畫面。外幣依匯率換算成台幣後，出貨當下就能算出這張發票的毛利，業務與會計看的是同一組數字。 **第一次導入國貿系統，應該從哪裡開始？** 從最常出錯、或最耗時的一段開始，多半是佣金或月底對帳。先把主檔定清楚，包括客戶、品項、廠商，以及各買主的單證格式。等這一段穩了，再接訂單與採購，不必一次換掉所有做法。 這個案例實際用的技術：C# 與 .NET Framework 4.8、Windows Forms、DevExpress（表格與報表）、Microsoft SQL Server、ADO.NET 與 Dapper。技術跟著問題走，不是重點。 --- --- title: 一問一答寫出來的系統，很快就沒人敢改｜如新科技 RUSIN Tech url: https://rusin-tech.com/insights/conversation-built/ description: 用 AI 一來一往對話寫出的公司系統，每一段都對，合起來卻過度設計、難以維護。更少人注意的是責任：系統最後會落在做出它的那個人身上，主管變成資訊承辦。如新科技（台中）談這件事怎麼發生、怎麼避免。 --- 觀點 01 # 一問一答寫出來的系統，很快就沒人敢改 每一輪對話都得到一個滿意的答案。問題是，沒有人看過這些答案合起來的樣子。 ## 每一段都對，合起來不對 用 AI 寫系統最順的方式，是想到什麼講什麼。「加一個匯出 Excel。」「客戶要能分等級。」「這裡要可以退回重簽。」每一句它都做得出來，而且做得比你想的還周到。 這樣走三個月，系統裡會有很多功能。但你回頭看會發現： - 同一件事有兩三種做法，因為是在不同的對話裡分別做的。 - 同一份資料存在好幾個地方，改了這裡，那裡沒跟著改。 - 有些功能是為了某一次的特例加的，現在沒有人記得為什麼。 - 畫面上有一堆設定和選項，沒有人用過，也沒有人敢拿掉。 這不是 AI 寫得不好。它每一次都把你當下說的那件事做得很好。只是「把每一句話做好」和「把一套系統做好」是兩件事，中間缺了一個從頭到尾想過的人。 ## 便宜的東西會越做越多 以前加一個功能要排工期、要花錢，所以大家會先問「真的需要嗎」。現在加一個功能只要一句話，這個問題就沒有人問了。 AI 自己也有這個傾向。你請它做報表，它順手幫你加了篩選、排序、三種匯出格式和權限控管。看起來很貼心，但每多一樣東西，就多一樣之後要有人懂、有人顧的東西。 做的時候不花力氣，不代表之後不花力氣。這就是過度設計，而它在 AI 時代變得非常容易發生。 ## 沒人敢改，是什麼感覺 到某一天，你想改一個很小的地方，例如把單價從兩位小數改成三位。AI 改了，畫面也對了。隔天會計說月報的總額跑掉了。再請 AI 修，月報對了，換成匯出的檔案格式不對。 幾次之後，你會開始害怕動它。不是因為改不了，而是因為不知道改了會壞哪裡。系統還在跑，但它已經不再能跟著公司的需要調整。這時候它就從資產變成負擔了。 ## 更少人注意的事：責任會落在做的那個人身上 系統是誰做出來的，出了問題大家就找誰。這件事不會寫在任何地方，但每個組織都是這樣運作的。 如果用 AI 把系統做出來的是一位主管，接下來會發生的事情大概是這樣： 1. 同事登不進去，找他。 2. 資料打錯了要改，找他。 3. 業務想多一個欄位，找他。 4. 月底報表數字怪怪的，還是找他。 他原本的工作是做決定、帶人、看方向。現在他的一天被切成很多小塊，用來回答操作問題和修資料。沒有人指派他當資訊承辦，但他實際上已經是了，因為只有他知道那套系統是怎麼回事。 這是角色的錯配。公司付的是主管的薪水，得到的卻是一位兼職的系統維護員，而且這位維護員沒辦法請假，也沒有人可以交接。時間久了，疲勞是一定的。更麻煩的是，他該做的那些決策，沒有時間做了。 很多人一開始自己動手，是因為「這樣比較快」。當下確實比較快。只是沒有算到後面這一段。 ## 可以怎麼做 1. **先把整體想過一次，再開始對話。**要管哪些東西、資料之間的關係、誰會用，寫成一兩頁。有了這個，AI 的每一次產出才有地方可以對照。 2. **每加一樣東西，先問誰來顧。**答不出來的功能，先不要加。 3. **定期回頭刪東西。**沒人用的設定、為了特例加的分支，隔一段時間就清一次。系統要能變小，才改得動。 4. **一開始就決定系統歸誰。**做的人和顧的人可以不是同一個。主管可以決定要什麼，但日常的維護要有明確的承接者，不管是內部的人還是外部的顧問。 5. **留下別人看得懂的紀錄。**為什麼這樣設計、哪些是刻意不做的。這份紀錄的讀者是半年後的你自己，或是接手的人。 **如果已經走到沒人敢改的那一步：**先不要急著重寫。把現況讀一遍，通常會發現真正有人用的只有一部分。留下那一部分、整理資料、把維護責任交接出去，往往比全部重來實際。 ## 常見問題 **為什麼用 AI 對話寫出來的系統很難維護？** 因為每一次對話只處理當下想到的那一小塊，AI 會把那一塊做得很完整，卻沒有人從頭規劃整體。同一件事可能被做了兩三種寫法，資料存在好幾個地方，改一處會牽動別處，久了沒有人敢動。 **什麼是過度設計？AI 為什麼容易過度設計？** 過度設計是做了比實際需要更多、更複雜的東西。AI 產出的成本很低，又傾向把每個要求做到周全，所以會順手加上用不到的設定、狀態與選項。這些東西當下不花力氣，之後每一項都要有人理解和維護。 **主管自己用 AI 做系統有什麼風險？** 最大的風險是責任歸屬。系統是誰做的，出問題大家就找誰。主管原本的工作是決策與帶人，卻漸漸變成回答操作問題、修資料、改功能的承辦人。時間被切碎，角色也錯位了。 **已經用 AI 做了一套難改的系統，該怎麼辦？** 先不要急著重寫。找人把現況讀一遍：資料存在哪裡、哪些功能真的有人用、哪些可以關掉。多數情況是留下有用的部分、整理資料結構、把維護責任交接出去，而不是全部打掉。 ## 接著讀 - [觀點 02：自己用的小工具，和一群人要用的系統，是兩回事](https://rusin-tech.com/insights/personal-vs-organization/) - [觀點 04：功能可以一直加，但誰來整理、誰來顧](https://rusin-tech.com/insights/who-maintains/) - [全部觀點](https://rusin-tech.com/insights/) --- --- title: AI 一秒就想出一套流程，但你的公司沒有那套流程｜如新科技 RUSIN Tech url: https://rusin-tech.com/insights/imagined-process/ description: 用 AI 開發公司內部系統時，AI 很會補上聽起來合理的作法與理想情境。照著做，現場一次次不順，磨掉的是組織對再試一次的信任與耐心。如新科技（台中）談這件事為什麼發生，以及動工前該先做什麼。 --- 觀點 03 # AI 一秒就想出一套流程，但你的公司沒有那套流程 它給的方案通常很完整，看起來也很合理。問題是，那是一家不存在的公司的流程。 ## 事情通常是這樣開始的 有人對 AI 說：「幫我做一個請購系統。」幾分鐘後，畫面出來了。申請、主管簽核、採購下單、驗收、付款，五個步驟，每一步都有狀態，還附了通知信。 看的人很滿意，因為它比公司現在的做法整齊多了。於是決定就照這個做。 沒有人注意到的是：公司現在根本不是這樣跑的。急件是先打電話叫貨、事後補單。有兩位主管出差時由助理代簽。某幾家老廠商沒有驗收這一步，因為貨到了就直接上線用。這些事沒有人告訴 AI，因為問的人自己也覺得那是「不正規的做法」，不好意思講。 ## AI 不會說「這裡我不知道」 人接到一個模糊的需求，會回頭問。有現場經驗的人會問得更具體：急件怎麼辦？主管不在誰簽？有沒有哪些廠商是例外？ AI 的習慣不一樣。它不知道的部分，會用最常見、最合理的做法補起來，而且補得很順，看不出哪裡是你講的、哪裡是它猜的。你得到的是一份沒有破綻的方案，可是其中一大半沒有任何人確認過。 一來一往的對話會讓這件事更嚴重。你每次只講當下想到的那一小塊，它每次都把那一小塊做得很完整。十幾輪之後，系統裡有很多功能，卻沒有人從頭到尾看過它們合起來是什麼樣子。 ## 現場會怎麼回應 系統上線，第一個禮拜大家試著用。然後： - 第一張急件來了，系統不讓跳過簽核。採購只好照舊打電話，系統裡沒有這一筆。 - 舊資料匯進來，廠商名稱有三種寫法，同一家變成三家。 - 會計發現系統算出來的金額和她的對不起來，因為有一種折讓系統不認得。 - 有人開始在系統之外另外記一份 Excel，「以防萬一」。 每一件單獨看都是小事，都修得好。但對現場的人來說，感受是另一回事：又來了，又是一套說好要用、結果不能用的東西。 ## 真正被用掉的，是耐心 一套做錯的系統，錢和時間的損失算得出來。算不出來的是組織的耐心。 第一次導入不順，大家會幫忙回報問題。第二次，回報的人少了，抱怨的人多了。到第三次，資深的同事會直接說「你們先用，穩了再叫我」。這時候就算下一套系統做對了，也很難推得動，因為已經沒有人願意當第一個配合的人。 AI 讓「再做一版」變得很便宜，所以很容易產生一種錯覺：錯了沒關係，改就好。程式確實改得很快。人的信任改不了那麼快。 ## 動工之前，先做這五件事 1. **先看現在怎麼做，包括不照規定的部分。**到現場坐半天，比開三次會有用。那些「不好意思講」的做法，往往才是系統必須處理的重點。 2. **看過真實的資料再設計。**拿最近三個月的實際單據和檔案出來看。缺的欄位、重複的名稱、寫在備註裡的規則，都會在這時候出現。 3. **找出誰會受影響、誰會反對。**反對通常有道理。先聽完，系統才不會踩在別人的工作上。 4. **決定誰先上線。**挑一個痛得最明顯、也最願意試的部門先做。讓它先成功，其他部門才會想跟。 5. **明講這一次不做什麼。**AI 什麼都做得出來，所以更需要有人說「這個先不要」。範圍小，才收得起來。 這五件事都不需要寫程式，也都不是 AI 能替你做的。 **什麼時候可以直接叫 AI 做：**只有你自己要用、流程由你一個人決定、做壞了重來也不影響別人的工具。這種情況沒有上面這些問題，放心去做。 ## 常見問題 **用 AI 開發公司內部系統，最常見的失敗原因是什麼？** 不是程式寫錯，而是系統假設了一套公司實際上沒有的流程。AI 會把沒被告知的部分補成合理的樣子，這些補上去的部分沒有人確認過，上線後才在現場一一撞牆。 **為什麼 AI 會設計出不符合現場的流程？** 因為它只知道對話裡講到的片段。現場的例外、資料的缺漏、部門之間不成文的默契，通常沒有人會主動講，而 AI 不會停下來問，它會直接補一個聽起來合理的答案。 **系統導入失敗一兩次，有什麼關係？** 成本不只是那次的時間和費用。每一次「說好要用、結果不能用」，現場的人配合的意願就少一點。到第三次，大家會先觀望，新系統再好也很難推得動。 **動工之前應該先做什麼？** 先把現在實際怎麼做弄清楚，包括不照規定的部分；看過真實的資料；找出誰會受影響、誰會反對；決定哪個部門、哪一段先上線；並且明講這一次不做什麼。 ## 接著讀 - [觀點 04：功能可以一直加，但誰來整理、誰來顧](https://rusin-tech.com/insights/who-maintains/) - [觀點 02：自己用的小工具，和一群人要用的系統，是兩回事](https://rusin-tech.com/insights/personal-vs-organization/) - [全部觀點](https://rusin-tech.com/insights/) --- --- title: 自己用的小工具，和一群人要用的系統，是兩回事｜如新科技 RUSIN Tech url: https://rusin-tech.com/insights/personal-vs-organization/ description: 個人用的小工具可以放心用 AI 做。但公司內部或 B2B 系統要面對不完整的資料、不照規則的場景、部門之間多年的矛盾，功能寫完開個網頁請大家用通常不會成功。如新科技（台中）談導入順序為什麼比功能重要。 --- 觀點 02 # 自己用的小工具，和一群人要用的系統，是兩回事 差別不在程式的大小，在於系統之外的那些事：資料、例外，還有人和人之間的關係。 ## 先說可以放心做的 你想要一個幫自己整理報價的小工具、一個把幾份 Excel 合起來的程式、一個提醒自己追款的清單。這些請直接用 AI 做，不必找任何人。 原因很簡單：使用的人只有你。資料是你的，規則你說了算，哪裡不順你自己知道，改壞了重做也不影響別人。在這種情況下，AI 是很好的工具。 麻煩是從「這個不錯，讓全公司都用吧」那一刻開始的。 ## 一群人用，多出來三件事 ### 資料不是完美的 你自己的資料，你知道哪裡有問題。公司的資料累積了很多年、經過很多人的手，沒有人知道全貌。 - 同一家客戶有三種寫法，有的有統編、有的沒有。 - 品號的編法換過兩次，舊的沒有全部改過來。 - 真正重要的規則寫在備註欄裡，例如「此客戶月結，但十二月要提前」。 - 有些數字本來就對不起來，大家一直是靠人記得差在哪裡。 新系統上線的第一天，這些全部會浮上來。同事在系統裡查到一筆明顯不對的資料，就不會再相信它查到的其他東西。 ### 場景不是完美的 流程圖上每個步驟都有一個箭頭指向下一步。現場不是這樣。 - 客戶臨時改數量，貨已經出一半了。 - 負責簽核的人請了長假，沒有人知道誰可以代。 - 有一位老客戶二十年來都是口頭下單，沒有人敢請他改。 - 某個步驟規定要做，但大家都知道其實是事後補的。 這些例外不是偶發的，它們是日常的一部分。系統如果只做了正常的那條路，同事一天會遇到好幾次「系統不讓我做」，然後他們會繞過去。 ### 部門之間有長期的矛盾 這一點最少被提起，卻最常決定成敗。 業務希望接單越快越好，規格晚點再確認。生管希望規格確定了再排。會計希望每一筆都有單據。倉庫希望先把貨出掉。每個部門的立場都合理，而且這些拉扯已經存在很多年，靠的是彼此的默契和退讓在維持平衡。 系統會把規則寫死。原本模糊的地方，現在必須有一個明確的答案：誰先、誰後、誰說了算。這等於是在重新分配部門之間的權力和工作量。如果沒有人意識到這一點，系統就會在上線時引爆那些原本被默契蓋住的矛盾。 還有一種情況更常見：新系統讓甲部門多了輸入的工作，好處卻是乙部門拿到比較準的報表。甲部門沒有理由認真配合，而這不能怪他們。 ## 所以，不是寫完開個網頁就好 把功能做完、給大家網址和帳號、發一封公告請同仁開始使用。這個做法在個人工具上沒問題，在組織裡幾乎都會失敗。失敗的方式通常很安靜：沒有人反對，只是漸漸沒有人用。 組織裡的系統，重點在導入的順序。 ## 導入順序怎麼排 1. **先讓一個部門自己得到好處。**挑最痛、也最願意試的部門，先做對他們自己有用的那一段。他們省到事了，才會成為幫你說話的人。 2. **先整理主檔，再談交易。**客戶、品項、廠商這些基本資料先弄乾淨、定好由誰維護。歷史資料可以分批帶，或只留查詢。 3. **新舊並行一段時間。**讓大家有退路。並行的期間也是發現例外的期間，這段時間浮出來的問題，比任何訪談都真實。 4. **例外先用人處理，不要急著寫進系統。**觀察一陣子，確定是常態再做。很多例外其實一年只發生兩次。 5. **會動到部門分工的決定，要由有權決定的人來做。**不能讓寫系統的人，更不能讓 AI，默默替公司決定誰該多做事。 6. **一次只往前推一步。**前一段穩了，再開下一段。慢，但每一步都站得住。 **這些事裡，AI 幫得上忙的是寫程式那一段。**而排順序、聽出部門之間沒說出口的話、判斷哪個例外值得做，需要一個在現場、而且大家願意對他說實話的人。 ## 常見問題 **可以用 AI 自己開發公司的內部系統嗎？** 看是誰要用。只有自己或兩三個人用的工具，可以，而且很適合。要讓好幾個部門一起用的系統，寫程式只是其中一小部分，資料整理、流程協調和導入順序才是決定成敗的地方，這些需要有人到現場處理。 **系統功能都做好了，為什麼同事不用？** 常見的原因有三個：舊資料沒整理，系統裡查到的東西不可信；系統要求的做法和現場實際的做法不同；用系統讓某個部門多了工作，好處卻是別的部門拿走。這些都不是功能問題。 **系統導入應該從哪個部門開始？** 從最痛、也最願意試的那個部門開始，而且先做對他們自己有好處的那一段。讓第一個部門真的省到事，其他部門才會主動想加入。從最上游或最大的部門開始，通常不是最好的選擇。 **舊資料很亂，要先整理完才能上系統嗎？** 不必全部整理完，但要先決定哪些資料是系統的依據。通常的做法是先整理主檔，例如客戶、品項、廠商，歷史交易可以分批帶入或只留查詢。等資料完美才上線，等於永遠不上線。 ## 接著讀 - [觀點 03：AI 一秒就想出一套流程，但你的公司沒有那套流程](https://rusin-tech.com/insights/imagined-process/) - [觀點 01：一問一答寫出來的系統，很快就沒人敢改](https://rusin-tech.com/insights/conversation-built/) - [全部觀點](https://rusin-tech.com/insights/) --- --- title: 功能可以一直加，但誰來整理、誰來顧｜如新科技 RUSIN Tech url: https://rusin-tech.com/insights/who-maintains/ description: AI 讓加功能、加系統變得很便宜，真正的成本移到維運：現在有幾套、資料在哪、出事找誰、人力怎麼分配。如新科技（台中）談為什麼這個時代更需要一位長期站在你這邊的開發顧問，以及信任從哪裡來。 --- 觀點 04 # 功能可以一直加，但誰來整理、誰來顧 以前公司的問題是系統太少。接下來的問題會是系統太多，而且沒有人說得清楚全貌。 ## 加東西變得太容易了 業務部用 AI 做了一個報價工具。倉庫做了一個盤點的小程式。會計請外面的人做了對帳的外掛。老闆自己做了一個看業績的儀表板。每一個都解決了當下的問題，每一個都花不了多少錢。 兩年後，公司裡有十幾套東西在跑。這時候有人問了幾個簡單的問題： - 客戶資料到底以哪一份為準？ - 做報價工具的那位同事離職了，現在誰會改？ - 儀表板的數字和會計的報表對不起來，哪一個是對的？ - 哪一套有備份？上次確認備份能還原是什麼時候？ - 如果其中一套突然不能用，會影響到誰？ 沒有人答得出來。不是因為誰失職，而是從來沒有人被指定要回答這些問題。 ## 成本搬家了 過去做系統貴在「寫」，所以大家很謹慎，一套系統用十年。現在寫很便宜，貴的變成另外幾件事： - **理解。**每一套東西都要有人懂它在做什麼。 - **銜接。**系統之間的資料要對得起來，這件事不會自己發生。 - **日常。**帳號、權限、修資料、回答怎麼用，每一套都有。 - **變動。**法規改了、流程改了、合作的廠商換了，受影響的系統都要跟著動。 - **出事的時候。**要有人知道從哪裡查起。 這些成本不會出現在任何一張報價單上，所以很容易被忽略。它們會以另一種形式出現：某幾位同事越來越忙，卻說不清楚在忙什麼。 ## 維運其實是資源調度的問題 公司的人力和注意力是有限的。每多一套系統，就要從這個有限的量裡分一塊出來顧它。 所以真正要回答的不是「這個功能做不做得出來」，那個答案現在永遠是做得出來。要回答的是： 1. 這個新東西之後由誰顧？他現在手上還有多少餘裕？ 2. 它和現有的哪一套重疊？能不能用現有的改，而不是再多一套？ 3. 有沒有哪一套已經可以收掉，把人力換過來？ 4. 這幾套之中，哪一套出事最嚴重，值得多花力氣顧？ 這是管理的問題，需要一個看得到全貌的人。在很多公司裡，這個位置是空的。 ## 這個時代需要的是顧問，而且是好幾種 以前找軟體公司，是請他們做一套系統，做完驗收，關係就結束了。這個模式在寫程式很貴的年代是合理的。 現在客戶需要的東西變了，而且不只一種： - **還沒開始時：**有人幫忙判斷該不該做、買現成的夠不夠、先做哪一段。 - **自己或同事在做時：**有人看方向、看資料結構、提醒哪裡之後會出事。 - **請別人做時：**有人站在你這邊驗收，確認交到手上的東西之後顧得動。 - **上線之後：**有人長期知道全貌，系統增加時幫忙維持秩序。 - **已經亂了時：**有人幫忙盤點、整理、決定留哪些。 這幾種需要的都不是「把規格做出來」，而是判斷，以及願意說「這個先不要做」。 ## 信任從哪裡來 顧問這種關係，建立在信任上。而信任沒有辦法用宣稱的。它來自幾件很具體的事： - 他會勸你不要做某些事，即使做了他有錢賺。 - 他講的話你聽得懂，不用術語把你隔在外面。 - 他說的時程和範圍，後來都兌現了。 - 出問題的時候找得到人，而且他不推責任。 - 他記得你們公司的事，不必每次從頭解釋。 這些都要時間。所以我們通常建議從一件小事開始合作，例如一次需求的釐清，或是一次現有系統的盤點。合得來，再往下走。 **可以馬上自己做的一件事：**找一張紙，列出公司現在在用的所有系統、試算表和小工具，每一項後面寫上「誰在顧」。寫不出名字的那幾項，就是下一個會出事的地方。 ## 常見問題 **公司的系統越來越多，該怎麼整理？** 先盤點，不要先動手改。列出現在有哪些系統和工具、各自管什麼資料、誰在用、誰在維護、彼此怎麼交換資料。光是這張清單，通常就能看出哪些重複、哪些沒人顧、哪一套壞了影響最大。 **AI 開發的系統，維護成本會比較低嗎？** 寫的成本變低了，維護的成本沒有。系統上線後要有人處理帳號、修資料、因應流程改變、確認備份、在出事時查原因。AI 可以協助其中一部分，但需要一個了解全貌的人來判斷和負責。 **什麼是開發顧問？和外包廠商有什麼不同？** 外包廠商依規格交付一套系統，交付後關係通常就結束。開發顧問是長期站在你這一邊的人：幫你判斷該不該做、怎麼排順序、驗收別人或 AI 做出來的成果，並在系統增加時幫你維持整體的秩序。 **中小企業需要專職的資訊人員嗎？** 不一定。很多公司的規模還不到需要一位全職的資訊主管，但已經大到需要有人負責。這個中間地帶，可以用每月固定時數的長期顧問來補，需要時再增加。 ## 接著讀 - [觀點 01：一問一答寫出來的系統，很快就沒人敢改](https://rusin-tech.com/insights/conversation-built/) - [我們怎麼合作](https://rusin-tech.com/services/) - [全部觀點](https://rusin-tech.com/insights/) --- --- title: 正航 ERP 整合：正航沒有的那一段，在旁邊補上｜如新科技 RUSIN Tech url: https://rusin-tech.com/integrations/chi/ description: 已經在用正航 ERP，但維修這類行業專屬的流程放不進去？如新科技（台中）做過放在正航旁邊的外掛：讀取正航的客戶、機身序號與庫存，單據留在外掛，對正航先只讀不寫。這一頁寫動工前該先弄清楚的事。 --- ERP 整合・正航 # 正航沒有的那一段，在旁邊補上。而且先只讀不寫 我們做過一套放在正航 ERP 旁邊的外掛。這一頁不列功能，寫的是已經在用正航的公司常遇到的事，以及動工前該先弄清楚什麼。 ## 已經在用正航的公司，常遇到的事 1. **進銷存記的是結果，不是過程。**銷貨單和庫存單記得下一筆交易，卻記不下「等客戶確認報價」「等原廠判定保固」這種停在半路的狀態。維修、租賃這類流程，正航放不進去。 2. **放不進去的那一段，回到了 Excel。**於是維修部自己記一份，櫃台再記一份。客戶問進度，要先找到是誰手上那一份。 3. **同一位客戶、同一個序號，要打兩次。**正航裡明明已經有，另外記的那一份還是得重打。打錯一個字，兩邊就對不起來。 4. **很自然會想：讓外掛直接改正航的庫存就好了。**這件事做得到，但它會動到帳。一旦兩邊不一致，要查清楚是誰改的、哪一邊才對，比想像中麻煩。 5. **外掛做完不是結束。**正航會改版。改版之後，外掛讀的那些資料表還在不在、欄位意思有沒有變，要有人去確認。 ## 動工之前，我們會先問的事 每一題的答案，都會改變外掛該做多大、該怎麼接。 - 卡住的是哪一段作業？現在是用什麼在撐，誰在維護那份資料？ - 這一段需要用到正航的哪些資料？客戶、品項、序號、庫存，還是單據？ - 真的需要寫回正航嗎？如果要，帳對不起來的時候由誰負責？ - 正航的版本和資料庫權限是誰在管？能不能開一個只讀的帳號？ - 正航裡的客戶主檔和序號乾不乾淨？有沒有重複或早就沒在用的資料？ - 外掛做好之後，誰來顧？正航改版時誰去確認？ ## 我們在一個現場做了什麼 做法的核心是一個判斷：**正航繼續管客戶、庫存與帳；外掛只讀它的資料，維修的單據放在自己這邊。** 這是替一家設備代理商做的售後維修系統。完整的現場紀錄在[設備售後維修](https://rusin-tech.com/industries/after-sales/)那一頁。和正航有關的部分是這樣： | 讀取的檢視 | 內容 | 在外掛裡的用途 | | --- | --- | --- | | `CHI_CustomerView` | 客戶 | 收件時帶出客戶，櫃台不必重打 | | `CHI_SrvStkSNView` | 機身序號 | 收件時帶出序號，並用它查這台機器過去的維修紀錄 | | `CHI_ProductWarehouseQty` | 各倉庫存 | 領料時看得到各倉目前的在庫量 | - **只讀不寫：**外掛沒有去扣正航的庫存，也沒有替正航產生單據。正航的帳只有正航自己在改。 - **單據留在外掛：**報價、領料、完工、返還與收款，都存在外掛自己的資料庫。 - **沿用正航已有的分類：**問題分類與維修代碼直接讀正航裡的設定，不另外建一套。 - **跨門市查得到：**用機身序號可以找出這台機器在各門市的維修紀錄。 ## 如果你也在用正航，可以先想的事 - **先確認正航是不是真的沒有。**有些功能正航本來就有，只是沒開或沒人會用。用原本的，比另外做一套好。 - **先只讀不寫。**只讀的外掛不會弄亂正航的帳，改版時的風險也小。多數情況這樣就夠用了。 - **要回寫，就另外評估。**不要和流程改版一起做。先讓新流程跑順，再談要不要動到帳。 - **先把主檔整理乾淨。**外掛會把正航裡的資料原樣帶出來。客戶重複、序號有錯，外掛只會讓它更明顯。 - **先講好誰來顧。**見[功能可以一直加，但誰來整理、誰來顧](https://rusin-tech.com/insights/who-maintains/)。 ## 常見問題 **正航 ERP 可以做外掛嗎？** 可以。外掛是放在正航旁邊的另一套程式，讀取正航資料庫裡的資料，處理正航沒有的那一段作業。正航本身不必更換，大家原本怎麼用還是怎麼用。能不能做，要先看卡住的是哪一段，以及資料庫的讀取權限。 **外掛會不會影響正航原本的運作？** 只讀取的外掛不會改到正航的帳，影響最小。要留意的是查詢不要拖慢正航，以及正航改版後，外掛用到的資料表與檢視要有人重新確認。 **外掛可以直接扣正航的庫存嗎？** 技術上可以評估，但我們做過的案例是只讀不寫。由外掛去扣庫存或產生單據，會動到正航的銷貨與庫存帳，兩邊要保持一致，出錯時也要分得清是誰改的。這件事建議另外評估，不要和流程改版一起做。 **正航改版後，外掛還能用嗎？** 不一定，所以要確認。改版後把外掛用到的資料表與檢視逐一比對，欄位還在不在、意思有沒有變，確認之後再更新。這件事要有固定的人負責，不能等出問題才發現。 這個案例實際用的技術：C# 與 .NET（Windows Forms）、SQL Server、DevExpress，正航 ERP 唯讀對接。技術跟著問題走，不是重點。 正航為其所屬公司之商標，如新科技提供的是獨立的第三方整合開發，並非正航原廠或其經銷夥伴。 --- --- title: 鼎新 ERP 整合：放不進 ERP 的那一段，在旁邊補上｜如新科技 RUSIN Tech url: https://rusin-tech.com/integrations/digiwin/ description: 如新科技（台中）在鼎新 ERP 旁邊做過外掛：不改動鼎新，讀取製令、訂單、客戶與品號主檔，行業專屬的爐號與材證資料放在外掛自己的資料庫。這一頁寫的是動工前該先弄清楚的事。 --- ERP 整合・鼎新 # 鼎新沒有的那一段，不必換掉鼎新 ERP，在旁邊補上就好 我們在台中替一家精密鑄造與閥門外銷廠做過材質證明系統，放在鼎新 ERP 旁邊，讀取製令與訂單資料。這一頁不列功能，寫的是已經在用鼎新 ERP、卻有一段行業作業放不進去的公司，外人不會知道的事，以及動工前該先弄清楚什麼。 ## 已經在用鼎新的公司，常遇到的事 1. **ERP 管得好訂單、庫存與帳。**這一段鼎新做得穩，沒有人會想碰它。但行業專屬的資料，例如爐號、成分數值與試驗紀錄，在鼎新裡沒有對應的欄位可放。 2. **於是那一段回到 Excel。**同一筆製令資料，ERP 裡登錄一次，Excel 裡再抄一次。哪一份才是準的，常常要靠人去問。 3. **換 ERP 太貴，也太冒險。**為了一段行業作業，把整套系統換掉，訂單、帳與既有流程都要跟著搬。多數公司不會為此做這個決定。 4. **請原廠客製，範圍與費用不一定划算。**客製的需求常常比一開始想的大，報價與工期也不容易預估。 5. **外掛做了之後，ERP 改版要有人重新確認。**外掛依賴的資料表與欄位，若鼎新改版時沒有人記得這件事，外掛就可能在某一天悄悄出錯。 ## 動工之前，我們會先問的事 想在鼎新旁邊補一段作業的公司，我們會先問這些。每一題的答案，都會改變外掛該怎麼做。 - 卡住的是哪一段作業？現在是用什麼在撐，Excel、紙本，還是某個人的記憶？ - 這段作業需要讀鼎新的哪些資料？製令、訂單、客戶與品號，各需要哪些欄位？ - 需不需要把結果寫回鼎新？如果需要，要寫哪一張表、哪些欄位？ - 鼎新的版本與資料庫權限，現在是誰在管？讀取用的帳號由誰開、由誰收回？ - 鼎新多久改版一次？改版之前，會不會先通知你們？ - 外掛上線之後，誰來顧？出了問題，找誰處理？ ## 我們在一個現場做了什麼 核心的判斷只有一句：**不改鼎新，只在旁邊讀它的資料，行業的東西放在外掛自己這邊。**使用者仍在原來的 ERP 裡做訂單與製令，流程不因此中斷。 - **製令帶入：**輸入製令號碼，客戶、品號、訂單號與生產數量自動帶出，不必重打。 - **爐號登錄：**閥體與閥蓋各自登錄爐號，分開記錄，不寫成同一個號。 - **規範比對：**數值超出規範上下限時以紅字標示，在出文件之前就看得見。 - **材證與裝箱：**依 EN 10204 3.1 格式輸出材質證明書；裝箱時，序號與箱號綁在一起。 這個案例讀取鼎新的四個資料表，對應關係如下： | 資料表 | 內容 | 在外掛裡的用途 | | --- | --- | --- | | `MOCTA` | 製令 | 以製令號碼為入口，帶出生產數量 | | `COPTC` | 訂單 | 帶出訂單號 | | `COPMA` | 客戶主檔 | 帶出客戶 | | `INVMB` | 品號主檔 | 帶出品號 | 這裡寫的是讀取。若你的需求需要回寫鼎新，會動到鼎新的帳，要另外評估。這一段的行業細節，寫在 [鑄造與閥門材質證明的案例頁](https://rusin-tech.com/industries/casting-mtr/)。 ## 如果你也在用鼎新，可以先想的事 - **先確認鼎新本身是不是真的沒有這個功能。**有的話用原本的就好，不必另外做一套。 - **先只讀不寫。**讀取出錯的影響小。等資料對得準、流程跑順了，再評估要不要回寫。 - **外掛的維護責任要先定。**改版後的確認由誰做、故障時找誰、要不要升級，在開工之前就要講清楚。 - **一次只補一段。**先挑最卡的那一段，用順了再補下一段，不必想一次把所有行業作業都搬進外掛。 **適合來談的人：**已經使用鼎新 ERP、但有一段行業作業放不進去的製造業與貿易業公司，以及想找有行業經驗的團隊接手外掛維護的資訊主管與老闆。 ## 常見問題 **鼎新 ERP 可以做外掛嗎？** 可以。外掛是跑在鼎新旁邊的獨立應用程式，處理 ERP 裡沒有欄位可放的行業作業。使用者仍在原來的鼎新 ERP 裡做訂單與製令，不必換系統。 **外掛會不會影響鼎新？** 外掛與鼎新是分開的。我們做的這個案例只讀取鼎新的製令、訂單、客戶與品號資料，行業資料則存在外掛自己的資料庫。若你的需求要寫回鼎新，會動到鼎新的帳，需要另外評估。 **鼎新改版後，外掛還能用嗎？** 要重新確認。外掛讀取的資料表與欄位，改版後可能有變動，需要先在測試環境驗證，確認沒問題再上線。這是維護外掛的一般步驟，不能因為外掛是獨立系統就省略。 **可以把資料寫回鼎新嗎？** 技術上要先評估。回寫會直接影響鼎新裡的資料，影響範圍、寫入的資料表與欄位、以及稽核紀錄都要先講清楚。我們的建議是先從讀取開始，資料對得準、流程跑順了，再決定要不要回寫。 這個案例實際用的技術：C# 與 .NET（Windows Forms）、SQL Server、DevExpress。技術跟著問題走，不是重點。 鼎新為其所屬公司之商標，如新科技提供的是獨立的第三方整合開發，並非鼎新原廠或其經銷夥伴。 --- --- title: 長照派車調度：難的不是排車，是預約單當下沒記下的東西｜如新科技 RUSIN Tech url: https://rusin-tech.com/long-term-care/dispatch/ description: 如新科技（台中）在長照交通接送的調度現場，整理預約單該記的欄位、調度台的派車方式、里程的查詢方式與司機回報。這一行難的不是排車，是當下沒記下的資料，月底補不回來。 --- 長照派車・調度作業 # 長照派車調度，難的不是排車，是一張預約單當下沒記下的東西 我們替長照特約交通接送單位做過從預約、調度、司機回報到月底核銷的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。少記的那一欄，月底通常補不回來。 ## 這一行，外人不會知道的事 1. **同一位個案一天會有好幾趟。**去程、回程與日間照顧的接送分散在不同時段，調度要自己確認同一個人不會被排在兩個地方。 2. **地址寫法沒有統一。**家屬寫門牌，機構寫大樓名稱，同一個地點常有好幾種寫法。地圖查不到，就得回頭打電話問。 3. **輪椅與陪同是派車的條件，不是備註。**車型怎麼配，取決於這兩件事。但很多時候它只寫在紙條上，司機出車前還要再問一次。 4. **臨時改期與取消很常見。**地點一改，預估里程就得重算。取消也不能只是消失，原因要分派車前、派車後、行程中與管理員取消，才看得出問題出在哪裡。 5. **預估里程和實際里程是兩個數字。**建單時算出的是預估，司機結束行程後回報的才是實際。月底要用哪一個，得在一開始就講清楚。 ## 動工之前，我們會先問的事 想做或想換派車系統的車隊，我們會先問這些。每一題的答案，都會改變系統該怎麼記。 - 你們一天會替同一位個案排幾趟？去程、回程與日間照顧接送，是各建一張單，還是綁在一起？ - 上下車地址是誰寫的？地點現在有沒有存成固定的座標，還是每次都重打一次？ - 個案的輪椅型式與陪同人數，現在記在哪裡？司機出車前是怎麼得知的？ - 臨時改期或取消，通常是誰打給誰？取消的原因現在有沒有記？ - 調度的人有幾位？如果最熟的那一位請假，誰能接手派車？那些口頭約定的事，他能不能交出來？ - 司機回報的實際里程與車資，現在是用什麼方式交回來？多久一次？ ## 我們在這個現場做了什麼 做法的核心只有一句話：**預約時記下的東西，要夠調度、里程與月底核銷一起用。**所以預約單上的每一個欄位，都是從後面的步驟倒推回來的。 - **預約單：**個案與預約人分開記，上下車地址與座標各自保存，去程與回程兩筆訂單互相指向。陪同人數、乘車人數與輪椅型式分開記。 - **調度台：**車與司機必須成對指定，只選一樣會被擋下。上方的時段統計只是列出該時段已有訂單的車與司機數，並扣掉可用數，不會自動幫你排班。 - **里程：**用 Google Maps 的駕車路線計算。起點與終點有有效座標就用座標，沒有才用地址，地址只在台灣範圍內搜尋。建單時算預估里程，實際里程另外保存。 - **司機回報：**司機在 LINE 內開啟行程頁，只看得到派給自己的訂單。開始時記下實際上車點，結束後填寫實際里程、跳表車資與個案自付的部分，並可簽名確認。未填寫的訂單會停在待填寫記錄裡。 車資怎麼算、請款怎麼做，各有獨立的說明頁：[多縣市長照交通接送計費規則](https://rusin-tech.com/long-term-care/fare-rules/)，以及 [支審核銷](https://rusin-tech.com/long-term-care/reimbursement/)。 ## 如果你也在這一行，可以先想的事 - **先定預約單的欄位，再談調度台的畫面。**欄位少記一個，後面的里程、派車與核銷都會缺一塊，而且當下通常沒人覺得是問題。 - **地址先整理成幾種固定寫法。**把常去的地點存成座標，比追求每一筆地址都查得到，更快看到效果。 - **先不要做自動排班。**時段統計只是讓調度看清楚現況。要不要照著統計調整班表，還是要由調度的人判斷。 - **取消原因先記下來，不必一開始就做報表。**資料先留得住，之後想看趨勢都還來得及。 **適合來談的人：**有固定長照接送班表、車輛與司機多到靠一個人記憶排不完的車隊，需要安排日間照顧接送的單位，以及要替這類單位建置系統、需要有人懂這一行的團隊。 ## 常見問題 **長照交通接送的排班怎麼做才不會漏單？** 先把時間、上下車地址、輪椅與陪同需求記完整，再由調度台依時段排車。系統不允許只選車或只選司機就完成派車。 **預估里程和司機回報的實際里程不一樣，以哪一個為準？** 預估里程在建單時算出，實際里程由司機在行程結束時回報，兩者分開保存。月底核銷取用的是實際里程。 **派車之後，訂單還能取消嗎？** 可以，但取消時要選原因，原因分派車前、派車後、行程中與管理員取消。已完成簽名確認的訂單，司機端不能再取消。 **車隊要換調度系統，應該從哪裡開始？** 先從預約單開始。請調度照常記一段時間個案、地址、輪椅與陪同、去回程這幾個欄位，看哪些常常空白、哪些寫法最亂，摸清楚之後再決定調度台要做成什麼樣子。 這個案例實際用的技術：ASP.NET Core（.NET 8）、SQL Server、Vue 3、AG-Grid、LINE、Android、Google Maps。技術跟著問題走，不是重點。 --- --- title: 多縣市長照交通接送計費：同一趟車，金額不一樣｜如新科技 RUSIN Tech url: https://rusin-tech.com/long-term-care/fare-rules/ description: 如新科技（台中）在長照交通接送的現場做過計費規則。同一趟車在不同縣市、不同福利身分下金額不同，規定還會調整。這一頁寫的難處不在算，而在知道現在該用哪一版規定，以及導入前要先問清楚什麼。 --- 長照派車・計費規則 # 長照交通接送計費，難的不是算，是知道現在該用哪一版規定 同一趟車，在不同縣市、不同福利身分下，補助與自付額可能不一樣，而且規定會調整。我們在這個現場做過計費規則的設計。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **一趟車，有三個數字。**車資要拆成政府補助與民眾自付，兩者加起來才是車資。拆的方式看福利身分、服務類別、住在哪個行政區，還有當月額度用了多少。司機在車上就要知道該收多少，不能等月底才算。 2. **各縣市不一樣，而且會改。**補助上限與自付比例由各縣市公告。跨縣市服務的車隊，同一套系統要同時跑好幾套規則。公告調整後，新趟次用新規定，已完成的趟次還是要照當時的規定對得起來。 3. **偏遠地區另有規定。**個案住在哪個行政區，會決定比對哪一套規則。偏遠的標示要以主管機關為準，系統裡的行政區資料要定期對照。 4. **DA01 與 BD03 算法不同。**交通接送是往返就醫或復健，社區式交通接送是往返日間照顧這類據點。社區式以每趟基準計算，交通接送要比對當月額度，月底的報表格式也不同。 5. **每月額度會累計，超出的部分算自付。**同一位個案當月的車資一路加總，超過補助上限的那一段改算自付。有些縣市對超額另有特別處理，這類規定不一定能用一個數字表達。 ## 動工之前，我們會先問的事 想做或想換計費系統的單位，我們會先問這幾件事。每一題的答案，都會改變系統怎麼算、怎麼存。 - 你們服務哪幾個縣市？各縣市的補助規定現在是誰在對、多久對一次？ - 每位個案的福利身分與當月已用的額度記在哪裡？多久更新一次？ - 同一位個案一個月通常搭幾趟？超出額度時，現在是怎麼跟個案說明的？ - 哪些縣市對超額有特別做法？能不能用規則欄位表達，還是要另外寫例外？ - 偏遠地區怎麼判定？是看居住的行政區，還是另有名單？名單多久更新？ - 規定公告調整時，現在是誰通知誰？新規定通常從哪一天開始適用？ ## 我們在這個現場做了什麼 做法的核心是：**把規定當成資料，不寫死在程式裡。**公告一改，改的是資料，而且已完成的趟次保留當時算出的金額。 - **規則存成資料：**每筆規則記錄縣市、服務類別、是否偏遠、每月補助上限、每趟補助上限、依福利身分分三類的自付比例，以及生效日與失效日。 - **公告調整就新增一筆：**舊規則填上失效日，新規則填上生效日。已寫入的趟次保留當時的金額，不會因為後來的規則而改寫。 - **額度累計與超額提示：**每月額度累計的是當月未取消趟次的車資。超額時不擋下這一趟，把超出的部分列為自付，並在司機端提示，讓司機當場向個案說明。 - **政府補助由差額得出：**補助等於車資減自付額，系統不另存補助欄位。核銷報表用同一個差額產生，月底三者對得起來。 | 欄位 | 用途 | | --- | --- | | 縣市 | 規則適用的縣市，對應個案居住的行政區 | | 服務類別 | 區分社區式交通接送與交通接送，兩者的計算與報表不同 | | 是否偏遠 | 決定比對哪一筆規則 | | 每月補助上限 | 個案當月的補助額度 | | 每趟補助上限 | 單趟的補助基準 | | 自付比例 | 依福利身分分三類，各一欄 | | 生效日與失效日 | 規則的適用期間，失效日留空代表目前仍有效 | 司機端怎麼在行程中看到額度，見[調度作業怎麼串起這些資料](https://rusin-tech.com/long-term-care/dispatch/)；月底的請款檔如何從同一批趟次產出，見[核銷檔的產出方式](https://rusin-tech.com/long-term-care/reimbursement/)。 ## 如果你也在這一行，可以先想的事 - **有些例外不一定能用一個數字表達。**超額的特別處理、偏遠的判定、個別個案的例外，導入時要逐一問清楚，再決定做成規則欄位還是另外處理。 - **規則的生效期間不要重疊。**同一縣市、同一服務類別、同一偏遠組合，任何一天只能有一筆有效規則，否則同一趟會對到兩筆，不知道以哪一筆為準。 - **規則是誰在維護，要先定。**誰能新增與修改規則、誰對公告內容負責、改了之後誰會被通知，動工前講清楚。沒有人管的規則，系統再準也會慢慢不準。 - **先不要做全部縣市。**先從一個縣市、一種服務類別開始，把規則、額度與報表跑通，再擴大。一次把所有例外都做進來，通常是最慢的路。 **適合來談的人：**長照特約交通接送單位、想跨入長照接送的車隊與租賃業者、需要接送個案的日間照顧中心，以及要替這類單位建置系統、需要有人懂這一行的軟體公司。 ## 常見問題 **長照交通接送的自付額怎麼計算？** 自付額由車資、個案福利身分對應的自付比例、每趟補助上限，以及當月已使用的額度共同決定。各縣市的規定不同，而且會調整，實際金額要以該縣市現行公告為準。系統只負責把規定套用到每一趟。 **各縣市的長照交通補助上限一樣嗎？** 不一樣。各縣市公告的上限與自付比例各自獨立，公告調整時也會變動。系統把這些數值存成各縣市的規則資料，新公告生效時新增一筆規則即可，已完成的趟次金額不會被改寫。 **長照補助額度每個月怎麼累計？** 系統把個案當月未取消的交通接送車資加總，作為已使用額度，再與本趟車資相加和每月補助上限比對。超過的部分列為自付，司機端會顯示提示。累計的是車資金額，不是補助或自付額。 **我們車隊想做長照交通接送計費，應該從哪裡開始？** 先把服務縣市的現行公告整理成一張表，列出補助上限、自付規定、偏遠判定與超額做法，並標明來源與生效日。這張表弄清楚，系統該長什麼樣子就清楚了。動工前先確定誰負責更新它。 這個案例實際用的技術：ASP.NET Core（.NET 8）、SQL Server、Vue 3。技術跟著問題走，不是重點。 --- --- title: BD03、DA01 長照支審核銷：難在月底的紀錄對不對｜如新科技 RUSIN Tech url: https://rusin-tech.com/long-term-care/reimbursement/ description: 如新科技（台中）在長照交通接送的現場，整理 BD03、DA01 支審核銷的難處：月底要對的不是報表格式，而是整月乘車紀錄當初有沒有記對、記全。本頁寫報表怎麼從每一趟紀錄產出，以及送件前仍要人工核對的地方。 --- 長照派車・支審核銷 # BD03、DA01 長照支審核銷：難的不是產報表，是整月的乘車紀錄有沒有記對、記全 我們在長照交通接送的現場做過核銷報表的系統。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工之前該先弄清楚什麼。 ## 這一行，外人不會知道的事 1. **請款是以個案與趟次為單位。**同一位個案一個月可能有好幾趟，每一趟的日期、里程、時段與自付額都要對得上。少一趟或多一趟，該個案的數字就跟著錯。自付額怎麼拆，見[計費規則怎麼設計](https://rusin-tech.com/long-term-care/fare-rules/)。 2. **DA01 與 BD03 的報表欄位不同。**DA01 是交通接送，用於往返就醫或復健，報表有跳表與自付額等欄位；BD03 是社區式服務交通接送，用於往返日間照顧等據點，範本以日期、起迄點、時間、里程與個案簽名為主。兩種要分開處理，不能當成同一種趟次。 3. **每個縣市的衛生局與長照管理中心各有自己的範本。**同一種服務，不同單位的標題、欄位順序與頁尾都不一樣。範本還會跟著公告調整，換一個縣市，等於換一套格式。 4. **紙本紀錄簿、調度表、試算表分開存，月底就要逐筆比對。**司機的紀錄簿、調度表與試算表各記一部分，行政人員得一筆一筆對過，才敢把數字打進報表。最花時間的就是這一段。 5. **一個數字錯，可能整份退回。**人工謄寫整月紀錄時，一個日期或一格費用抄錯，就可能整份檔案被退件重做。退件的代價不只是重跑，還會拖慢整個月的請款時程。 ## 動工之前，我們會先問的事 想做或想換核銷流程的單位，我們會先問下面這些。每一題的答案，都會改變系統產檔的方式。 - 你們服務哪幾個縣市？各縣市要交哪幾種報表，範本是誰提供的、用的是哪一版？ - 交通接送與社區式服務交通接送各佔多少趟次？兩種報表現在是分開做，還是混在一起？ - 司機的紀錄簿、調度表、試算表各記哪些欄位？有沒有哪一份是唯一的依據？ - 月底對帳時，通常是誰跟誰對？對到什麼程度才算完成？ - 範本或送件規定改過的時候，是誰發現的、怎麼通知承辦人員？ - 上一次被退件，是格式問題、資料缺漏，還是數字對不上？ ## 我們在這個現場做了什麼 做法的核心只有一句話：**報表直接取自每一趟的乘車紀錄，不另外填表。**月底不再把整月紀錄逐筆重打，同一筆紀錄直接轉成報表欄位。 - **依範本對位產出：**依各縣市主管機關的範本，表頭與欄位位置照範本對位，產出 Excel 檔。範本缺漏時產檔直接失敗，不會留下欄位不完整的檔案。 - **核銷檔可一次匯出多種服務：**DA01 與 BD03 可同時勾選，並依日期、縣市、個案身份字號與訂單狀態篩選。 - **月報與明細並列：**另有運輸服務月報表，依日統計趟次與服務人數；服務費用明細表則逐筆列出訂單，可依歸屬縣市篩選。 - **查無資料不產檔：**條件下查不到任何趟次時，系統不會產出空白報表。 | 報表種類 | 對應的服務 | 用途 | | --- | --- | --- | | 核銷檔（核銷用 Excel） | DA01、BD03 可同時勾選 | 依日期、縣市、個案身份字號與訂單狀態篩選，一次匯出多種服務的核銷明細。 | | BD03 特約社區式服務交通接送表 | BD03 | 依各縣市範本產出，每一列為一趟，頁尾有使用組數與加總。 | | DA01 交通接送請款表 | DA01 | 依各縣市範本產出，含跳表、乘車數、自付額與共乘欄位。 | | BD03 個案服務紀錄一覽表 | BD03 | 以個案與日期排成每日使用狀況，供每月勾稽與稽核留存，部分縣市需要。 | | 運輸服務月報表 | DA01、BD03 | 依日統計趟次與服務人數，供月報與趟次核對。 | | 服務費用明細表 | DA01、BD03 | 逐筆列出訂單明細，可依歸屬縣市篩選。 | 篩選時，BD03 與 DA01 報表必須填起迄日期與個案身份字號，缺一就不會送出查詢。趟次資料怎麼從調度進來，見[調度作業](https://rusin-tech.com/long-term-care/dispatch/)。 要注意的是，頁尾加總遇到空白的費用欄位會當成 0 計算，所以司機端沒填完整的趟次不會自己跳出來。送件前仍要抽幾筆，與司機端的簽收紀錄對照。系統不保證不被退件，審核結果取決於各縣市規定與資料是否齊全。 ## 如果你也在這一行，可以先想的事 - **先確認各縣市的範本與送件方式。**範本版本與送件管道都要先問承辦單位。手上的範本如果不是最新版，後面做得再準也是白做。 - **送件前，仍要有人看過。**系統能拿掉重打的錯，但資料齊不齊、符不符合規定，還是要承辦人員把關。頁尾加總不會替你找出漏填的趟次。 - **小數位數等格式要求，由承辦人員確認。**里程與費用在試算表裡很容易多出小數位，系統只把數值寫進範本，該保留幾位小數要依各縣市規定。 - **先不要一次接完所有服務與縣市。**先讓一種報表、一個範本、一位承辦人員的流程跑通，確認格式問題不再發生，再考慮擴大。 **適合來談的人：**長照特約交通接送單位的行政與會計人員、需要把既有乘車資料轉成支審格式的車隊與日照中心，以及要替這類單位建置核銷流程、需要有人懂這一行的軟體公司。 ## 常見問題 **長照交通接送的核銷報表要怎麼產生？** 在報表功能選擇報表種類，填入起迄日期與個案身份字號後匯出 Excel。BD03 與 DA01 的縣市範本報表，每一列是一趟乘車紀錄，頁尾會列出使用組數與自付額、補助額的加總。送件前仍建議抽幾筆與司機端的紀錄核對。 **不同縣市的核銷範本一樣嗎？** 不一樣。各縣市的衛生局與長照管理中心各有自己的範本，表頭與欄位順序不同。新增其他縣市時，需要先取得該縣市的範本，再建立對應的報表設定。 **用系統產出的核銷檔就保證不會被退件嗎？** 無法保證。系統可以降低格式錯誤與謄寫錯誤，但審核結果還取決於各縣市的規定與個案資料是否齊全。我們不會對審核結果做任何承諾。 **想從月底核銷開始導入，要先準備什麼？** 先把該月每位個案的趟次、服務項目與司機回報整理出來，同時拿到承辦單位要求的範本與送件方式。再用一個月的實際資料，比對系統產出的檔案和手上現有報表差在哪裡。差異清楚了，才決定要不要換掉既有的做法。 這個案例實際用的技術：ASP.NET Core（.NET 8）、SQL Server、NPOI（讀寫 Excel 範本）、Vue 3。技術跟著問題走，不是重點。