在評估POS系統好壞優劣筆者建議可由三大要點來初步區分；其中[POS系統的種類] 及 [POS系統功能架構] 已於前篇介紹。
而本篇筆者將說明最為重要且關鍵的[POS系統軟體架構]。但因涉及 （程式撰寫） 和 （資料庫語法） 等專業資訊工程領域術語而容易被忽略或誤解；【系統軟體架構】相對於POS系統 好像是（地基 對於 建築物 ）或是 （底盤 對於 整車）的重要性，是決定性的因素但一般使用者因 資料不對稱或 資料不透明 而無法了解明白。
所以外顯在 POS系統上可明顯呈現的是，支援 【多點連鎖】並【即時集中】資料處理的POS系統不多，而實際上線使用並且有客戶滿意的POS系統更少，實在是程式撰寫、資料庫語法、資料連線處理等技術門檻太高。
系統軟體架構之二層式架構及DBF資料檔
針對【系統軟體架構】。筆者區分為資料庫或資料檔、二層式架構及三層式架構、單店或多點資料連線、集中或分散資料連線、即時或批次資料連線及其他。
在台灣商用軟體市場上，某些單機單店及簡易POS系統為二層式軟體架構，可再區分為使用DBF資料檔及SQL資料庫，大致如下：
以上二層式軟體架構有致命的缺失，在POS系統上線使用後，使用人員都必須面對承擔。
第一種架構最明顯的問題是系統不穩，資料易遺失。為何會如此？以搜尋為例：
如果這時User2，新增、修改、刪除資料，會造成Cache資料
User1的Cache資料過時，很容易用過時資料運作；或剛好整個電腦因為停電當機等某種因素，不正常的回寫資料而讓DBF損毀。
系統軟體架構之二層式架構及SQL資料庫
而第二種架構最常見的問題有多人同時過帳及資料斷頭斷尾這兩個致命傷。
何謂多人同時過帳：以扣庫存為例，如果庫存有鉛筆10支。這時有二人同時出貨。User1出貨2支，user2出貨3支。照理庫存應剩5支。但實際呢？
資料庫會剩下鉛筆數量不是7支，不然就是8支；至於為什麼？
相信透過圖解應該是很清楚，因為二層式系統軟體架構無法處理多人同時過帳。
至於，資料斷頭斷尾這問題其發生的原理是：以常見的報價單據為例
在資料庫的設計原理至少要有兩個資料表格。
因此如果要存回資料庫，至少要有二個Update SQL。
在某些特殊情況下如：網路斷線或當機，萬一只有一個Update SQL 成功，另外一個SQL失敗會造成所謂資料斷頭斷尾，其後遺症相當多。
那如何防制資料斷頭斷尾呢？
在回答此問題之前，先解釋一個資料庫術語「Transaction」稱為交易。
「交易」是指一連串對後端資料庫異動的SQL。
以ATM提款動作為例：1.晶片卡扣帳2.機器吐出錢。
這二個動作是完成後交易「Transaction」才成立，不可能只有晶片卡扣帳而機器不吐錢。
在資料庫的設計功能中會提供一個確保完整交易的機制。
POS系統必須利用此機制確保POS每一筆資料交易「TRANSACTION」被完整執行，才能避免所謂資料斷頭斷尾。
系統軟體架構之三層式架構及SQL資料庫
既然常見二種架構都有缺點，難道三層式的架構就能避免缺失?
答案是不盡然，必須輔以幾個特性才能完全避免。
在進一步解釋之前，先解釋何謂三層式：
Client端：作用是讓使用者輸入的畫面，通常Client端可以透過Browser來自動安裝。
Server端：其作用有：
1. 一般Client端負責收集，使用者輸入的值之後傳回Server端，根據定義好的商業邏輯來存入資料庫。
2. 負責管理後端資料庫的連線，管理的方向大致是－－有使用才連線，不然挪給別人使用或預留幾條連線，讓使用者可快速連線。
3. 前端狀態的儲存，如使用者資訊，連線時間．．．等。
資料庫：其作用是資料儲存。
在初步了解完三層式的架構之後，接下來筆者深入討論完整三層式架構。
一般廠商為了節省成本往往單機版採用檔案型資料庫（DBF或Access．．．）；網路版採用資料庫（MySQL、SQL Server、DB２或Oracle．．．）及Web版會採用不同的架構。其最大的後遺症是－每轉換一個版本，便需重新轉換一次系統；重新匯入資料；重新熟悉新的操作畫面；重新上線教育使用者。
行業別雲端系列的三層式架構，不管是單機版、網路版及Web版均採用以下三層式。
因此，在轉換版本的過程幾乎是「無法感覺它的存在」。至於最為人詬病的資料損毀問題，因採用SQL資料庫「Transaction」機制幾乎不會發生。
系統軟體架構之集中式或分散式
企業只要經營順利，往往很快便會趨向多點經營。對經營者而言所面對的問題是管理時所帶來的困擾，至於MIS所需面對的則是資訊系統如何配合公司的成長計劃。
就筆者所見過的系統會以下列幾種方式呈現：
· 利用Terminal Service的方式將舊系統上網，讓遠端人員操作。
· 分別於每一分點個別安裝每一套系統，然後想辦法將各個分點資料作一匯總。
· 每一分點利用Internet即時連回總公司的主機進行電腦操作。
事實上，會選擇上述三種方案均有其背景及理由。
以第一種方案為例，經常是基於舊系統不需任何修改就能上網，成果很快就能顯現。
美中不足的是使用上較不具親和力，檔案系統(Local與Server端)互不連通，Local端硬體設備無法被Server端使用(除了印表機)，除此之外，同時上線人數也較受限。因此，可定位於緊急備案，並非長期的最佳方案。
以第二種方案為例，經常應用於二種狀況：
1. 同樣舊系統也不需大量修改，只要加寫匯總程式，不過前提是要對舊系統的Table Schema(資料結構)夠了解。
2. 是Local端需獨立運行的系統，即使與Server端的網路斷線，典型像流通業、賣場均是屬於這種系統。這種系統一般均較複雜與需較多的人力能維護，因此，經常是公司花錢請人或委外專案客制。成功上線系統經常見於成功的企業，因為負擔的成本及所需的人才，絕非一般小公司所能輕易負擔。
以第三種方案為例，由於Internet的頻寬越來越大所至，通訊成本也越來越低，現行企業多點的解決方案，幾乎以這種方式進行。其顯而易見的好處是資料庫屬於集中式免去擾人資料匯總的問題，另外，程式碼的更新也只要在Server端即可。不過，實務上，要將這類系統寫好並不容易，經常會出現二個缺點：
1. 是輸入畫面不親和（以Pure HTML方式實作）。
2. 是反應速度過慢（以Java、Net、ActivForm）。
這其中較值得深入討論是第二及第三種解決方案，也是本篇文章所下的標題–集中式或分散式。
幾乎一開始會選擇集中式的企業，一定是著眼於其較低成本的維護成本，再者是企業本就對資訊系統依賴較不深入，一時的斷線或操作反應速度較慢均能接受，如果隨著分點的規模逐漸擴大，資訊系統的操作反應速度同時也逐漸被要求時，才認真思考讓分點獨立擁有資訊系統，這時包袱已深，不容易提出較完整解決方案，經常是延伸既有的系統，然後利用外加程式，把一些額外衍生的問題想辦法克服。
記得921時及SARS來襲，企業被迫思考異地備援及多點解決方案(SARS來襲，經常只要有一員工疑是SARS患者，政府規定企業必須歇業十天，因此，許多企業將員工分成二組分別在兩地上班)，那時企業才匆匆忙忙提出一些方案，實在令人懷疑是否可行。
除了所提的連線方式外，其實在多點的整合系統有以下幾個共同的基本問題是必須面對。
1. 如何確保分點資料是完整被匯整。
2. 如何將總公司所建檔資料寫入分點系統。
3. 分點傳回總公司的資料，總公司是否能刪除或修改。
4. 分點能否修改或刪除已傳回總公司的資料。
5. 分點是否因情況緊急而授權從事原本屬於總公司專屬建檔工作。
6. 如何確保各個分點的資料，不會有資料衝突的情況。
7. 系統如何追蹤同一筆資料，不巧同時被分點與總公司修改。
8. 系統如何追蹤分點因情況特殊所作修正行為。
當這些基本的資料交換問題若是資訊系統無法自動處理時其影響是相當深遠。
我們一起來看看一般POS系統分為前台POS及後台資訊匯總系統是如何面對這問題?
前台POS經常扮演是銷售及客戶資訊的收集（年齡、性別…），至於後台資訊匯總系統則扮演將各個分點POS資訊匯總，以利於總公司深入了解每個分點的銷售狀況、庫存狀況，而且會將總公司的產品定價策略自動輸送至每一分點的POS。
如果將之以圖示的方法表達大致如下：
這樣的系統理論上不會太困難，無非是先製作一個POS（單機系統），然後再製作一個後台系統，最後再將這二個系統的資訊交換。
分開考量POS或後台系統在台灣均是相當的成熟，但奇怪的是，整合起來的資訊系統在台灣就不常見。原來這實務上，這樣的系統細節相當的繁複，以POS將銷售、庫存狀況回傳至後台為例：
POS有300筆資料，會被壓縮成一的檔案或多的檔案，傳回總公後，然後再被解壓縮一筆一筆寫回台資訊系統。這樣的流程相當方便，也容易實作，但問題來了，一旦因某種情況，傳回的300筆資料，因某種情況只成功寫入298筆，試問遺漏是哪2筆，而總公司的人員又怎麼能相信每天資料都有被完整傳回，想當然爾，一定要每日製作分點報表，傳回總公司然後立案備存，一旦有問題再一筆筆肉眼核對。於是乎，隨著分點越開越多，總部資訊人員也成等比級數增加，其絕大部分的工作不是接收傳檔，不然就是核對資料。
以後台系統將產品價格傳至POS為例：如果考慮單純的價格傳送大致不會有太大問題，但往往一般為了競爭，常常會開發新產品組合或新的價格促銷策略，那萬一原本POS系統無法負荷，必須先更版之後才能達成新品的銷售，單店越多越見其難度。
因此，這樣的系統不是幾乎是以各個獨立POS存在，不然就是專案客製，由資訊人員一肩挑下所有重擔。因此，雖然經營者雖然能體認到多點整合系統的重要性，但要實施起來，可說是千心萬苦。
而如何由系統軟體架構從根本解決，其中相關細節以下篇幅再來討論。
系統軟體架構之多點即時集中式
在行業別雲端系統，在以上問題均被仔細分析考量之後提出【多點、即時、集中式整合方案】，跳脫傳統單向檔案傳輸的施工方法，採用較複雜較高技術的雙向單筆資料傳輸方式。
其POS系統資料交換方式大致如下：
單點的電腦操作人員，就可動手操作將資料傳回總公司後台系統，不需總公司有人負責照顧資料轉回的細節。而且無需擔憂萬一資料有漏失，必須耗費大量人力去以報表一筆一筆核對資料正確與否。
從成本上，總公司所需的資訊人一定會被大大降低，至於資料漏失的情形，系統會自動記錄下次再傳。
這裡有些技術細節必須逐一被釐清。
1. 在分點安裝總公司版行業別雲端系統的Client端，由總公司版行業別雲端系統Client端負責寫回總公司，必須克服萬一總公司程式碼修改，每一分點的程式碼要能自動版本更新，一筆一筆資料透過網路回寫，其執行速度是要被接受。
2. 如何能確保分點的兩個行業別雲端系統是同步運作，不會發生總公司版已成功寫入，分公司版還記錄未成功。
3. 如何實作一套追蹤系統，開放讓分點資訊人員修改已上傳過的資料，才能作事後追蹤。
一般系統為了易於操作，往往讓整個上傳下傳的流程變得沒有人性化。例如：單向資料傳輸，已上傳過的資料不准修改，甚且有一旦存檔過的資料不准修改，（對於銷貨單或許可以，但進貨單則有些不通情理）。
藉由將POS系統交易資料交換的動作細節仔細剖析之後，可見【多點即時集中式】的POS系統並不多見；因為相關的問題相當的繁複，而且企業期望在最精簡的人力下還能維護POS系統運作，簡直是少之又少。
或許讀者會問：既然這樣的施工方法有這些好處，那為什麼別家軟體公司不採用？
原因是程式技術困難度高，且要克服因多次傳輸之後，所帶來速度下降的難題。
在系統使用上管理人員及操作最常提及的問是—沒有某某報表，所以管理上會有不方便的地方，把這個問題如何克服呢?請參考鏈結[ 報表設計 智慧分析]
系統軟體架構之報表設計
