門市 POS 系統軟件更新與版本管理：更新前檢查、更新測試、回滾與更新紀錄實務

一、更新唔係按一個掣：點解每次更新都有風險

門市收銀枱每日開單、折扣、收據、庫存變動同報表，都經同一套 POS 系統運作。一次軟件更新改動的可能唔止一個畫面，而係牽動成條開單到對數的鏈，更新前無檢查、更新後無測試，問題往往喺最忙嗰陣先浮現。

根據 TestFort《POS Testing》（查閱日期：2026-10-19），POS 方案經常更新，目的包括新增功能、修正錯誤或者改善保安。每次更新都要測試同現有硬件、其他軟件模組同設定的相容性，並且需要持續回歸測試，確保更新唔會引入新問題。

更新風險的來源，唔係更新本身，而係更新同門市現有環境的互動。硬件型號、周邊裝置、原有設定、庫存同報表邏輯，任何一環同新版本唔夾，都可能令開單變慢、收據出錯、庫存數字唔啱，或者報表對唔返數。將更新當成例行小事，係門市常見的誤解。

目前未見香港有專門法例規管門市 POS 系統軟件更新，目前未見法例訂明強制更新期限、強制測試次數、強制備份保存期或者罰款。本文以下各節提出的檢查、測試、回滾同紀錄安排，屬於商戶自訂實務建議，唔係法例要求。

二、更新前檢查：版本、內容、裝置與時段

更新前檢查的第一項，係確認版本編號同更新內容。門市應該睇清楚今次更新係邊個版本、改咗乜嘢、係保安修正、功能新增，定係兩者兼有。更新內容唔清，之後的測試就無從入手，回滾嗰陣亦唔知要返去邊個版本。

第二項係確認適用裝置同系統要求。門市應該核對更新適用於邊啲裝置、需要乜嘢系統版本、會唔會影響周邊裝置。根據 TestFort《POS Testing》（查閱日期：2026-10-19），每次更新都要測試同現有硬件、其他軟件模組同設定的相容性，呢項檢查正正係為咗避免更新之後先發現裝置唔夾。

第三項係確認更新時段同負責人。根據 Moldstud《Essential Tips for Keeping Your Retail POS Software Running Smoothly with Regular Updates》（查閱日期：2026-10-19），更新應該安排喺非繁忙時段，並且通知員工更新時間表。門市應該事先定明由邊個負責執行更新、由邊個負責檢查結果，以及更新期間收銀安排點樣處理，唔好等到更新開始先至分工。

第四項係確認供應商更新通知已經收到同理解。通知內容、適用範圍同建議安排，應該喺更新之前登記落嚟，留待第七節的跟進流程處理。通知未齊全，門市應該主動向供應商查詢，唔好假設供應商一定會主動通知。

三、更新前備份：只寫同更新直接相關的檢查點

根據 Moldstud《Essential Tips for Keeping Your Retail POS Software Running Smoothly with Regular Updates》（查閱日期：2026-10-19），更新之前必須備份 POS 資料，以防更新期間遺失資料。可靠的備份系統喺更新出問題嗰陣可以快速復原。

更新前備份的檢查點，唔係備份咗就算，而係確認備份已經完成，並且可以還原。門市應該喺更新之前確認備份狀態，更新之後如果要回滾，先有可以還原的版本可用。備份完成但從來無驗證過可唔可以還原，等於未做呢項檢查。

備份制度的完整做法，包括備份頻率、保存安排同還原演練，本文不重複，詳見本系列 post-65 資料備份一文。更新前備份的安排，屬於商戶自訂實務建議，唔係法例要求，目前未見香港法例訂明 POS 更新的強制備份保存期。

四、更新測試：少量裝置先行與測試清單

以 Shopify 為例，Shopify 每兩星期發布一次更新版 POS；如果有多個零售地點，最好用流動裝置管理管理應用程式版本，並且喺向所有門市推出之前，先喺少量裝置上測試每個新版本（來源：Shopify《Retail Roundup (September 2026 – v11.15 & v11.16)》，查閱日期：2026-10-19）。呢個發布節奏係 Shopify 自身產品的安排，唔係所有 POS 系統的通用節奏。

門市更新測試的安排，可以參考上述 Shopify 做法：先喺少量裝置或者非正式環境測試，測試通過先至全面推出。多裝置版本不一致嗰陣，唔好全面推出，否則唔同裝置行緊唔同版本，開單同對數好容易出亂子。

測試清單應該覆蓋開單、折扣、付款方式記錄、收據、庫存變動、報表，以及掃描器同打印機等周邊裝置。根據 TestFort《POS Testing》（查閱日期：2026-10-19），整合測試須確保 POS 終端機、周邊裝置、庫存系統同其他第三方整合之間的數據流通，並且驗證數據一致性同準確性，例如售出之後庫存更新。

測試嗰陣要留意，POS 只負責記錄付款方式、分類及對數，實際收款經八達通機、KPay、YedPay 等獨立渠道進行。測試的對象係 POS 記錄付款方式、分類及對數係咪正確。

如果只係為特定終端機作有限度更新，門市必須仔細核查呢啲有限度更新唔會破壞成個系統（來源：TestFort《POS Testing》引述 TestFort QA Lead Michael Tomara 的意見，查閱日期：2026-10-19）。有限度更新影響範圍細，但唔代表可以跳過測試。

五、回歸測試：確保舊功能未被破壞

根據 TestFort《POS Testing》（查閱日期：2026-10-19），回歸測試係驗證新更新、錯誤修正或者新增功能唔會干擾現有功能，做法係對已經測試過的元件重新執行測試個案，確保變更無帶來非預期問題。

回歸測試的重點，係舊功能。新增功能測試通過，唔等於舊功能依然正常。門市應該喺每次更新之後，重新行常用功能的測試，包括開單、折扣、收據、庫存變動同報表，確認舊流程未被新版本破壞。

回歸測試亦需要持續進行。根據 TestFort《POS Testing》（查閱日期：2026-10-19），POS 方案經常更新，需要持續回歸測試，確保更新唔會引入新問題。門市唔好將回歸測試當成一次過的工作，而應該將佢寫入每次更新的固定流程。

六、更新失敗回滾：預先訂明的觸發與核對步驟

根據 TestFort《POS Testing》引述 TestFort QA Lead Michael Tomara 的意見（查閱日期：2026-10-19），測試系統更新係重要環節，要確保更新順利，並且補丁喺有需要嗰陣可以回滾。呢個係業界做法，唔係香港法例要求。

根據 Moldstud《Essential Tips for Keeping Your Retail POS Software Running Smoothly with Regular Updates》（查閱日期：2026-10-19），更新出問題嗰陣應該有回滾計劃，回滾可以快速恢復功能，並且記錄回滾原因。門市應該喺更新之前已經訂明回滾計劃，唔好等到更新失敗先至諗點樣返轉頭。

回滾計劃應該訂明邊種情況觸發回滾、由邊個決定回滾、回滾去邊個版本。觸發條件可以包括開單功能異常、收據出錯、庫存數字唔啱，或者報表對唔返數。觸發條件事先寫清，現場先唔使靠估。

回滾唔係重新開機了事。回滾之後，門市須核對版本係咪已經返到目標版本，核對資料同對數係咪正確，並且記錄回滾原因。回滾唔保證資料一定唔會遺失，門市唔好將回滾當成萬無一失的安排。目前未見香港法例訂明特定回滾時限，回滾安排屬於商戶自訂實務建議。

七、供應商更新通知跟進：登記、分類、排期與升級

供應商更新通知跟進的第一步，係收到通知之後登記。門市應該記錄通知日期、更新版本、更新內容同供應商建議的安排，令之後的評估同排期有據可依。

登記之後，門市應該將通知分類，例如保安修正、功能新增，或者供應商指明的強制更新。分類的作用係決定跟進的先後次序，保安修正同功能新增的處理緩急唔同，唔好一律當成普通更新排隊。

分類之後，門市應該評估影響同排期。評估包括更新會影響邊啲裝置、邊啲流程，測試需要幾耐，更新時段點樣安排。排期之後，門市應該跟進進度，逾期未跟進的個案要有升級處理，例如由負責人向上級匯報，或者再次聯絡供應商確認。

未收到通知嗰陣，門市仍然應該主動查詢供應商的更新安排，唔好假設供應商一定會主動通知。目前未見香港官方來源訂明 POS 更新通知的指定格式或者指定提前日數，供應商更新通知跟進屬於合約或者服務安排同門市內部流程，唔係法例要求。

八、更新紀錄：每次更新記乜嘢、點樣用

根據 Moldstud《Essential Tips for Keeping Your Retail POS Software Running Smoothly with Regular Updates》（查閱日期：2026-10-19），門市應該保留更新日期紀錄。更新紀錄的用途，係日後追查同對數，唔係為咗應付某條法例而寫。

每次更新的紀錄，應該包括更新日期、舊版本、新版本、更新內容、測試結果、負責人，以及有無回滾同回滾原因。紀錄寫得齊，日後發現問題嗰陣，先至可以對照邊次更新改咗乜嘢，邊個版本開始出現問題。

更新紀錄的保存期，門市可以自行訂立內部管理安排。目前未見香港法例規定 POS 更新必須保留指定年期的更新紀錄，保存期唔係法例要求。紀錄保存安排應該寫入門市內部流程，並且由負責人跟進。

更新之後，門市應該培訓員工使用新功能。根據 Moldstud《Essential Tips for Keeping Your Retail POS Software Running Smoothly with Regular Updates》（查閱日期：2026-10-19），更新後培訓員工使用新功能係更新流程的一部分。培訓內容可以包括新功能的操作、改動咗的流程，同埋遇到問題嗰陣點樣匯報。

九、個人資料提醒：只有改變目的等情況先觸發資料原則

《個人資料（私隱）條例》第 486 章保障資料原則，適用於個人資料的處理。根據 Linklaters《Data Protected Hong Kong》（查閱日期：2026-10-19），保障資料原則第二原則要求個人資料準確、最新，保存不得超過達致原來目的所需的時間；第三原則要求個人資料只可用於收集時的目的或者直接有關的目的，用於其他目的須取得資料當事人的訂明同意。

「訂明同意」的意思，係資料當事人自願給予的明示同意，並且未以書面撤回（來源：Linklaters《Data Protected Hong Kong》，查閱日期：2026-10-19）。「訂明同意」唔係指必須書面同意，重點係自願、明示，同埋未以書面撤回。

保障資料原則第四原則要求對個人資料採取適當保安措施。根據 CLIC「外判處理個人資料」（查閱日期：2026-10-19），如果將個人資料交予資料處理者，例如 POS 供應商或者更新服務商，資料使用者須以合約或者其他方法，防止資料保存超過處理所需的時間，並且防止未經授權或者意外的查閱、處理、刪除、喪失或者其他不當使用。保安安排必須包括「喪失」。

只有當 POS 更新改變個人資料的收集目的、使用目的、保存期或者保安安排嗰陣，先至觸發《個人資料（私隱）條例》第 486 章保障資料原則第二、第三同第四原則的要求。例行保安更新、沿用原有目的，唔等於每次更新都要重新取得訂明同意。門市唔好將「每次更新都要取得顧客同意」寫成規則，呢個講法並唔正確。

十、更新管理清單與聯絡

門市可以將本文各節整理成一份更新管理清單：更新前檢查版本、內容、裝置、時段、負責人同備份；更新嗰陣先喺少量裝置測試，覆蓋開單、折扣、付款方式記錄、收據、庫存變動、報表同周邊裝置；更新之後做回歸測試；更新失敗按預先訂明的計劃回滾同核對；供應商通知登記、分類、排期、升級；每次更新記錄日期、版本、測試結果、負責人同回滾原因。清單屬於商戶自訂實務建議，唔係法例要求。

保養合約同資料遷移的安排，本文不重複，詳見本系列 post-245 POS 保養合約及資料遷移一文。更新管理的焦點，係每次軟件更新的管理，唔係保養合約本身。

POSKing「POS 系統＋收銀鏡頭套裝」HK$4,950 一次性買斷免月費，免月費年費（來源：根據本系列既定實價，查閱日期：2026-10-19）

POS 只負責記錄付款方式、分類及對數，實際收款經八達通機、KPay、YedPay 等獨立渠道進行。查詢可致電／WhatsApp +852 2186 8010，地址：新界沙田石門安麗街18號達利廣場1209室，營業時間：每日 12:00–19:00。