必須要說，sbo在中小型企業erp軟體中的確是佼佼者，靈活的配置，周延的考慮，不錯的泛型適應性，友好的業務結構跟蹤，強大的二次開發支援，儘管二次開發包幫助檔案中似乎總是欲露還留的那麼一手，讓開發人員無法展開手腳在其之上自如的開發。
不過，據我觀察，sbo也存在著設計上的缺陷--當然也可能是因為本人目前還沒有琢磨透sbo的基礎構架或者設計理念。今天在此向談一談的是sbo在單據物件--即憑證物件上的設計侷限。
sbo的單據物件，至少由兩個資料表予以業務支援，乙個是我在描述中所謂的資訊表--sbo中稱之為憑證標題，另乙個我稱之為單據清單--sbo稱之為憑證行，sbo的稱呼更加合適。當然不同的單據物件在不同的管理方式下可能還存在著不同的業務表單支援，在此不予討論。
單據資訊表--憑證標題--用於記錄單據發生時候的狀態資訊，同時記錄了這個憑證的業務物件型別，對應的關鍵字段為：objtype、docentry、docnum、docdate，這幾個字段分別是業務型別、憑證內部編號、憑證號碼、憑證日期。儘管每個業務物件對應著不同的資料表，仍然在單據資訊表中通過objtype欄位指明了業務型別。
單據清單--憑證行--用於記錄了單據發生時單據專案對應的清單資訊，包括專案在單據中所在的位置(linenum)、專案內容(itemcode, dscription)、專案發生屬性(quantity、price、currency等)，同時指明了專案的業務型別(objtype)。考慮到單據之間的互相引用，用basetype、baseentry、basenum、baselinnum分別指明引用項在原業務單據中的屬性即引用業務專案的業務型別、單據內部編號、單據號碼、專案在清單中的行號；同時，單據還用targettype、targetentry指明被引用的目標單據的型別和內部編號。
如果某個單據被另乙個單據業務所引用，sbo也預設在資訊表中的備註和ref1、ref2欄位中指明被引用單據的單據號碼。
這的確是個不錯的設計方案！熟悉演算法的朋友們看到這種結構就會馬上聯想到雙向鍊錶吧，我曾經在電信97工程--電信營銷系統中採用過類似的方法，我們當時的確稱之謂面向資料表的雙向鍊錶，這種設計結構將不同的物件以鍊錶的形式鏈結在一起了。
不過，用雙向鍊錶支援的業務總是簡單的，支援更加複雜的多引用業務就會顯得力不從心了。因為這個時候資料關係呈現的是樹形結構。
是的，sbo是這樣的，sbo的單據業務被引用後將導致被引用單據處於關閉狀態，其它的單據業務物件無法再引用這張單據。無法讓sbo的單據項被引用兩次--特別被不同業務單據引用兩次甚至更多次數，但是，這種業務還是有很多需求的。比如銷售200臺電視機，通過三次交貨，每次分別交貨80臺、70臺、50臺，交貨引用這個業務專案的時候，targetentry到底應該怎麼填寫呢？結果是，或者根本無法實現多次交貨--代客發貨，很普遍的業務呀，或者這個targetentry沒有了實際意義。這還是同一業務的分次引用，事實上不同業務引用同乙個單據項，又是怎樣處理的呢？
不知道sbo到底怎樣處理乙個單據專案行被不同業務的多次引用是怎樣處理的，但是通過其資料結構分析，應該很難支援。到底是因為對sbo了解的過於膚淺，還是sbo的設計侷限甚至缺陷，在此還是留個問號吧！
如何接管SBO系統的內建業務流程
有問 怎樣在基於sbo ui api開發的addon中接管系統提供的業務功能頁面中的處理方式而改為採用自定義的處理流程？答 首先，本人並不建議這樣去做，畢竟sbo作為一款成熟的財務 業務一體化的erp軟體，在業務處理上有著系統內在的資料和業務一致性約束和規則。但是在此既然提出，可能就有業務需要，這中...
單據套打類報表的設計要點
wyn enterprise報表的特色功能之一，是支援精確定位的單據套打。與普通的 類報表不同，套打單據類報表有幾個特點 1 資料內容的輸出位置必須精確定位，以便準確地列印到印刷好的空白單據紙張上。2 乙個報表頁面往往只輸出一條記錄的內容。普通 類報表往往一頁輸出數十條記錄。下面以乙個快遞單據為例，...
flask多對多的正向 反向引用
flask多對多關係的查詢 新增 刪除 角色模型 class role db.model tablename role r id db.column db.integer,autoincrement true primary key true r name db.column db.string 1...