專案名稱：財務管理系統（OA）

專案介紹

該專案是一個OA系統，第二版本改為SAAS系統。主要用於公司經費的申請，將線下的流程變為線上。減低企業成本。打個比方說

A使用者請假：

線下情況：A使用者拿請假單，A使用者去找領導申請，發現領導不在，走不了,這下就麻煩了

線上情況：A使用者線上申請，領導收到通知，同意申請。

一  專案框架搭建

spring+springMVC+mybaties+activiti+mysql+maven+redis+前端（easyui）

二 技術選型

spring+springMVC的好處：

•  springMVC的結構層次分明：檢視，模型，控制器
• Spring MVC非侵入性特徵：業務邏輯程式碼與框架本身是相分離
• 控制反轉：鬆耦合,物件依賴的其它物件會通過被動的方式傳遞進來，而不是這個物件自己建立或者查詢依賴物件（儘量使用組合，少使用繼承）.
• AOP: 允許通過分離應用的業務邏輯與系統級服務（如：事務管理，快取，操作日誌）進行內聚性的開發。
• 輕量級開發框架
• 可定製的handler mapping和view resolution：Spring提供從最簡單的URL對映，到複雜的、專用的定製策略。 
• 可定製的繫結(binding)和驗證(validation):比如將型別不匹配作為應用級的驗證錯誤，這可以保證錯誤的值。再比如本地化的日期和數字繫結等等。
• 強大而直接的配置方式：將框架類和應用程式類都能作為JavaBean配置，支援跨多個context的引用，例如，在web控制器中對業務物件和驗證器validator)的引用。

MyBatis

• 程式碼鬆耦合，簡快開發難度。
• 小巧並且簡單易學，減低開發成本。
• 靈活，不會對應用程式或者資料庫的現有設計強加任何影響，SQL寫在XML裡，從程式程式碼中徹底分離，降低耦合度，便於統一管理和優化，並可重用。
• 提供對映標籤，支援物件與資料庫的ORM欄位關係對映,功能豐富，可以滿足企業開發複雜設計。
• 提供XML標籤，支援編寫動態SQL語句。

• 是一個靈活的DAO層解決方案。對效能的要求很高，或者需求變化較多的專案，如網際網路專案，MyBatis將是不錯的選擇。

maven

• jar 包管理，防止jar之間依賴起衝突
• 使用私有伺服器，統一開發jar包，防止版本衝突和避免從中央伺服器下載。
• 方便管理專案報告，生成站點，管理JAR檔案，等等。例如：專案開發中第三方jar引用的問題，開發過程中合作成員引用的jar版本可能不同，還有可能重複引用相同jar的不同版本，使用maven關聯jar就可以配置引用jar的版本，避免衝突。
• Maven會自動將你要加入到專案中的jar包匯入，不僅匯入，而且還會將該jar包所依賴的jar包都自動匯入進來。
• 藉助Maven可以以規範的方式下載jar包，因為所有的知名框架或第三方工具的jar包已經按照統一的規範存放到了Maven的中央倉庫中。
• 可藉助Maven將一個專案拆分成多個工程，利於分工協作。而且模組之間還是可以傳送訊息的。

 
activiti

• 原生支援spring 
• 支援分離執行時和歷史資料
• 資料持久化(mybatis)
• 更好的業務過程控制
• 學習成本低，各種資料豐富，是主流的流程框架
• 免費開源

MySQL

• 可以處理擁有上千萬條記錄的大型資料；
• 支援常見的SQL語句規範；
• 可移植行高，安裝簡單小巧；
• 良好的執行效率，有豐富資訊的網路支援；
• 除錯、管理，優化簡單（相對其他大型資料庫）
• 本人有MySQL叢集和主從設計經驗,以及表設計，索引設計，分割槽設計，搜尋引擎選擇經驗

redis

當初設計的時候有2重方案，redis和memcached，最終選出redis，是因為對比功能發現memcached是redis的子集，而且redis是記憶體資料庫，訪問速度非常快，而且本人也有reidis叢集和主從設計經驗。

優點

1. 速度快，讀寫效能優異,因為資料存在記憶體中，類似於HashMap，HashMap的優勢就是查詢和操作的時間複雜度都是O(1)
2. 支援豐富資料型別，支援string，list，set，sorted set，hash
3. 支援事務，操作都是原子性
4. 豐富的特性：可用於快取，訊息，按key設定過期時間，過期後將會自動刪除
5. 支援資料持久化，支援AOF和RDB兩種持久化方式
6. 支援主從複製，主機會自動將資料同步到從機，可以進行讀寫分離。

 

 easyui

1. 快速開發，減少專案的開發週期，從而節省專案成本
2. 功能豐富和強大
3. 網路上的學習資源多，社群活躍
4. 非常適合進行web的快速開發

三 在專案中責任

01 專案整體構建和對專案規劃的技術選型

技術選型略過（上面已經講了），主要j將專案的整體構建

層次結構

aop（系統級服務：作用分離應用的業務邏輯與系統級服務）
    舉例：操作日誌的紀錄
core（後改為分散式模組開發）
    bean（ 類的基本屬性,擴充套件屬性放到query中） 
    controller（action層,呼叫service,控制url的訪問）
    dao（底層資料訪問介面）
    query（查詢物件，相當於對bean的擴充套件,比如物件的序列化和分頁）
    service（服務，事務的控制,呼叫的是dao層，後期改為呼叫bll層）
    (後期新增bll層,多個dao的組合功能的介面，service不呼叫dao,而是呼叫bll，好處是功能和事務分離，提高介面的重用性和靈活性)
common
    工具類
    專案初始化類
    公共服務（如訊息推送,文件線上預覽,檔案上傳和下載,任務排程，流程公共介面等）
exception（如資料訪問層異常處理,自定義異常等）
    
interceptor（包含所有攔截器的設計，比如使用者登入攔截器，流程處理器攔截器,js和靜態資源的攔截器（url攔截器））
plugin（外掛的管理：如分頁外掛）
resourceView（自定義檢視解析器）
web（對web操作的工具類管理和session的管理）

 
02  專案的進度把控（個人認為這是最重要的）

1. 產品原型設計（集團提供），需求文件編寫，開需求會議，立項文件確認
   1. 文件編寫：和需求人員一起明確確定
   2. 需求會議：明確需求對應的功能，功能對應的表結構設計，以及提供開發週期預估
2. 影響專案進度的因素及解決辦法
   • 不斷有新需求插入
     • 01確定產品的方向：如果不明確產品的方向，會導致資料庫表結構的大改動。
     •  案例：使用者職位設計
       • 最初我們設計是一個使用者表，一個員工表（職位），一個部門表，當時沒有考慮到流程導致流程開發階段需要對錶結構進行改動
       • 後來設計：使用者表，部門表，使用者部門關係（實際職位，流程執行）
     • 表結構的改動是影響是最大的，因為這次改動，我們花了一週實際去修改程式碼和重新測試，相當於浪費了一週時間
   • 版本控制
     • ceo版本上面急功近利，在版本管理期間新增需求進來，這個時候你一定要認真估算新需求的時間，對於不影響進度的可以適當新增進來，如果是重大改動的,預估時間解決不了的一定需要提出來，一起開個會，明確造成的影響，怎麼解決方案（招人，外包，延遲開發時間），如果實在這個版本解決不了，那麼只能放到下一個版本中。  
     • 不斷調整需求邏輯
       • 這種情況我們遇到過，這是產品經理沒有理清需求造成的，找出的後果就是 開發和測試感覺自己好忙、好累、疲於應對開發中出現的各種問題。
       • 解決方法：對產品一定要認真分析，不斷和對方溝通，明確各個細節，提出各種問題出來。最後最重要的是立項文件確認後發郵件給雙方一起確定方案。規劃書一起簽字明確功能和版本週期。這樣即使後期對方要改動，責任明確，不會造成責任迷糊，雙方推卸責任
3. 開發階段：這個時候需求，產品已經明確了，這個時候只需要認真把控版本進度（不考慮人員離職問題）
   •   每天早上跟進專案進度。
   •  多鼓勵隊伍成員。
   • 對於隊伍中能力差的成員，多次鼓勵，幫他（她）想些方法，莫要責備，責備可能會打擊成員積極性，情況迴圈惡劣， 我隊伍中就有這麼一個人，早上彙報進度的時候，他不說話，要麼就是左右言你，當時我就生氣了，直接責備，後來他離職了。

03 專案的表設計

因為內容太多，直接放到下面將

四 表的設計（只涉及一些關鍵欄位）

01系統模組

使用者模組

userInfo：使用者表

• UserID：使用者id,  主鍵自增長
• LoginID：賬號,  登入使用
• Password：密碼,  登入使用
• CreateBy：建立者id,  用於操作記錄
• CreateDate：建立日期,  用於操作記錄
• ModifyDate：修改日期,  用於操作記錄 
• ModifyBy：修改者id ,  用於操作記錄

loginlog：登入日誌表（後期不用，日誌直接寫在日誌檔案中）

功能：用於記錄登入日誌   

•     ID    ,主鍵自增長
•     UserID  ,使用者id,記錄誰登入
•     LoginIP  , 登入IP,記錄登入的客戶端
•     LoginTime , 登入時間,記錄登入的客戶端時間 

loginStatus:登入狀態表（後期沒用，後期使用redis來儲存使用者的會話，key為登入的cookie+UserID）

•     UserID : 使用者id
•     LoginTime : 登入時間
•     LoginState: 登入狀態
•     LastUpdateTime : 最近登入時間
•     LoginIP : 登入ip
•     SessionID : 使用者sessionID

功能：當用戶A在c1客戶端登入時候，同時使用者A在c2客戶端登入,提示c1客戶端，你已經在別的地方登入，並強制跳轉登入頁面
客戶端：相同IP
            相同瀏覽器
                
            不同瀏覽器
            
        不同IP
        
實現：c2登入，判斷UserID對應的紀錄LoginState是否為登入，
                是：
                    判斷IP是否相同：
                        是：
                            判斷瀏覽器是否相同：
                                是：提示c2客戶端，使用者已經登入，禁止c2登入
                                否：c2登入，修改UserID的LoginState=false,並新增一條紀錄

                        否：
                否：新增一條紀錄
        如果是修改false，並新增一條紀錄，
攔截器實現：任何.do的url請求，都去判斷下對應sessionID和IP的LoginState是否為false,是的話直接跳轉登入頁面

userCompanyManager ：使用者組織表
    ID ：主鍵ID
    UserID ：使用者id
    CompanyID ：公司ID
 
 

userinfoDepartmentInfo ：使用者部門職位表
    UserID ：使用者id
    PositionID ： 流程職位ID
    PositionTrueID ：職位真實ID
    DepartmentID ：部門id
 
 

userPasswordHistory ：使用者歷史密碼錶
    ID ：id
    UserID ：使用者id
    Password ：登入密碼

部門模組

departMent:部門表

  功能：部門是一顆樹結構
    DepartmentID：部門id
    ParentID：部門父id
    DepartmentType：節點型別（一級部門，二級部門）
    FullDepartmentName：部門全稱
    PrivilegeID2：許可權id(部門的操作許可權ID)  
    PrivilegeID：許可權id(部門的檢視許可權ID)
    DepartmentCode：部門編碼
    DepartmentNameAbbreviation：部門名稱縮寫
    DepartmentType2：所屬型別(如：如果該部門是二級部門，該所屬型別是一級部門)
    DepartmentNode：節點屬性（open,closed）

 departMentDepartmentNameRelation :部門與部門名稱關係表（相當於部門的資料字典）
 功能：維護部門名稱和部門編碼的一一對應關係
  ID  ：主鍵自增長 
  DepartmentName：部門名稱（會有一個對應的編碼）
  DepartmentCode：部門編碼
  DepartmentType：所屬型別
 

選單模組

menu：選單表
    MenuID：選單id
    Title：標題
    ParentID：父id
    PageUrl：頁面url
    Sequence：顯示順序
    IsLeaf：葉子節點0否1是
    IconName：圖示 
    PrivilegeID：許可權id 
    
功能：顯示使用者的左側選單，樹結構

功能模組

sysFunction： 功能表（關聯選單表）
    FunctionID：功能id 
    Name：功能名稱 
    MenuID：選單id 
    IsActive：是否有用0否1是 
    PrivilegeID：許可權id 
    Sequence：顯示序列 
功能：顯示選單下的功能, 設定某些頁面的操作功能許可權,打個比方說，A使用者在使用者管理頁面有刪除使用者功能，B使用者沒有

角色模組

sysRole:系統角色表
    ID : 主鍵自增長
    RoleID：角色id
    RoleName：角色名稱
    IsActive：是否有用0否1是
提供給使用者設定角色，和部門職位不掛鉤，方便靈活給使用者配置許可權

科目模組

account:科目表
    AccountID：科目id
    ParentID：科目父id
    AccountName：科目名稱
    FullAccountName：科目全稱 
    IsActive：是否啟用 0不啟用，1啟用
    IsDelete：是否刪除 0沒刪除，1刪除
    PrivilegeID2：許可權id(操作許可權,判斷使用者是否可以操作對應的科目的資料)
    PrivilegeID：許可權ID(檢視許可權,判斷使用者是否可以檢視對應的科目的資料) 
    AccountType：科目級別
功能：顯示科目 

許可權模組

privilege：許可權表
    PrivilegeID：許可權id，主鍵自增長
    Type：許可權型別
功能：記錄許可權ID的自增長

userPrivilegeTemp ：使用者許可權臨時表
    UserID：使用者id     主鍵 
    PrivilegeID：許可權id 主鍵 
功能：記錄使用者登入後的，獲取的使用者許可權全部放到這個表裡。當用戶再次獲取許可權的時候直接從這個表獲取

userRole ：使用者角色表
    UserID：使用者id ，主鍵 
    RoleID：使用者角色id，主鍵 
功能：記錄使用者和角色的關聯關係

excludePrivilege ：禁止許可權表
    UserID：使用者id，主鍵 
    PrivilegeID：許可權id，主鍵 
功能：記錄使用者不能使用的許可權

extraPrivilege ：額外許可權表
    UserID：使用者id，主鍵 
    PrivilegeID：許可權id，主鍵 
功能：記錄使用者一般許可權

rolePrivilege ：角色許可權表
    RoleID：角色id，主鍵 
    PrivilegeID：許可權id，主鍵 
功能：記錄角色對應的許可權

資料字典模組

datadictionarymain ：資料字典主表
  GroupID：組ID 主鍵,自增長
  Title：資料字典名稱 
 
datadictionarydetail ：資料字典明細表
  ItemID：資料字典明細ID,主鍵,自增長
  Value：資料字典明細值
  Sequence：序號，排序使用
  Param：引數(引數是json型別)
  GroupID：組ID
 

流程模組

flowTask ：流程記錄表，記錄流程的每個操作
    ID ：主鍵ID
    taskID ：任務ID，
    taskDefinitionKey ： 任務節點
    assignee ：當前審批人，
    operationDepartID ： 操作部門ID
    positionID ：流程職位id
    positionTrueID ： 真實職位ID
    createTime ：流程審批時間
    state ：審批意見
    comment ：  審批備註
    proceedingApplicationMainID ：被審批的申請單主表ID
    flowType ：流程型別
    companyID ：操作人公司id
    processInstanceId ：流程例項ID
    executionId ：流程執行ID
    processDefinitionId ：流程定義ID
    nextTaskDefinitionKey ：下一個任務節點

wf_hi_rejectrecord ：多級駁回記錄表 
    ID ：主鍵ID
    fromTaskID ：駁回人任務ID
    toTaskID ：被駁回人重新提交的任務ID
    fromTaskDefinitionKey ：駁回人節點
    toTaskDefinitionKey ：被駁回人節點
    fromAssignee ：駁回人
    toAssignee ：被駁回人
    rejectTime ：駁回時間
    resubmitTime ：被駁回人重新提交時間
    rejectIsDone ：駁回是否處理（預設處理：1，未處理0），針對連續駁回設計
    processInstanceId ：流程例項ID
    executionId ：流程執行ID
    processDefinitionId ：流程定義ID
    proceedingApplicationMainID ：申請單主表ID
功能： A -->B---C--D--E，當E駁回給C，C駁回給A，A重新提交，直接提交給C，C提交直接給E
實現：當前提交時同意：通過processDefinitionId和rejectIsDone=0檢視是否有記錄，有就獲取最後一條U，更新U.rejectIsDone=1,流程跳到給節點
 

 

 

autoApprove  ：記錄自動審批資訊
    ID  ：主鍵自增長
    Message：批註 
    UserID：使用者ID 
    TaskDefinitionKey：任務節點ID 
    ProcessInstanceId：流程例項ID  
功能：記錄正在審批的流程的自動審批情.
實現:
    同意審批：如果流程例項ID和任務節點ID，檢視是否有對應的紀錄，有：copy該記錄作為新增記錄，沒有就新增記錄，
    駁回審批：刪除流程例項ID對應的所有記錄
    流程審批結束：刪除流程例項ID對應的所有記錄
    
flowParam  ：流程引數表
    Id：主鍵自增長
    ProceedingApplicationMainID：申請單主表（ProceedingApplication）的ID 
    ClassName：申請單的對應的類名 
    OperationUserID：申請單對應的操作人ID 
    ApplicationPeopleID：申請單對應的申請人ID 
    OperationDepartmentID：申請單對應的操作人的部門ID 
    ApplicationDepartmentID：申請單對應的申請人的部門ID 
    FlowType：流程型別 
    FlowParams：流程非開始節點的引數，按照map的json方式儲存 
    StartParams：流程開始節點的引數 
    DynamicParams：動態引數，按照map的json方式儲存：非流程) 
    ProcessInstanceId：流程例項ID 
    Version：版本號，每次重新提交，修改流程引數的時候，版本號+1，流程引數的獲取是最新版本引數 

功能：記錄流程在審批過程中，動態修改的流程引數。
實現：只記錄正在執行的流程引數，當流程執行完，刪除該記錄，並將該記錄放到flowParamHistory。
      將資料分為活躍資料和不活躍資料。
 

flowParamHistory  ：流程引數歷史表
    Id：流程引數id 
    ProceedingApplicationMainID：申請單主表ProceedingApplication的的ID 
    ClassName：申請單的對應的類名 
    OperationUserID：申請單對應的操作人ID 
    ApplicationPeopleID：申請單對應的申請人ID 
    OperationDepartmentID：申請單對應的操作人的部門ID 
    ApplicationDepartmentID：申請單對應的申請人的部門ID 
    FlowType：流程型別 
    FlowParams：流程非開始節點的引數，按照map的json方式儲存 
    StartParams：流程開始節點的引數 
    DynamicParams：動態引數，按照map的json方式儲存：非流程) 
    ProcessInstanceId：流程例項ID 
    Version：版本號，每次重新提交，修改流程的時候，版本號+1，流程引數的獲取是最新版本引數 
    ProcessID：流程ID 
 

以下是流程設計的主要表：
審批關係：審批是按部門和部門流程職位來
打個比方說：差旅費申請流程
部門申請--》部門負責人（流程職位）---》財務專員---》財務主管。
設計的好處：審批不需要指定的人，只要指定部門流程職位的人，這樣當相應部門負責人離職的，流程審批不需要改動

下面五個表的關係：

• 1 通過Type和DepartmentID在processDepartmentRelate表中找到唯一一條ProcessID
• 2 ProcessID在processy，processProcessOrganizationMainRelate的關聯表可以獲取唯一一條ProcessProcessOrganizationMainRelateID
• 3 ProcessProcessOrganizationMainRelateID在processOrganizationmain,processOrganizationDetail關聯出流程組織樹

這個是當初和技術總監一起商量的，我的當初的設計是3個表
流程與部門的關聯表（通過Type，DepartmentID，確定ProcessID），Process表（ProcessID），流程組織樹表（ProcessID，主鍵ID，部門ID）
後來不知道怎麼變成5個表，但是這樣的設計是討論後確定(分析方向在靈活性方面,具體的我就忘了)
案例
    
 ProcessID=1對應的流程組織樹
    12  
        11 
            6（審批部門的部門ID）
                2（申請部門的部門ID）
                1
                5
                4
                

 
processDepartmentRelate  ：流程與部門的關聯表
    ProcessDepartmentRelateID：流程與系統組織的關聯表ID，主鍵
    ProcessID：流程id 
    Type ：型別 
    DepartmentID ：部門id   
    
process  ：流程表
    ProcessID：流程id(主鍵自增長)
    Type：流程型別 
    Name：流程名稱  

processProcessOrganizationMainRelate  ：流程與流程組織主表的關聯表
    ProcessProcessOrganizationMainRelateID：主鍵
    ProcessID：流程id 
    ProcessOrganizationMainID：流程組織主表id 
    
processOrganizationmain  ：流程組織主表
    ProcessOrganizationMainID：流程組織主表id 
    Name：名稱 

processOrganizationDetail  ：流程組織明細表
    ID：主鍵id 
    ProcessOrganizationMainID：流程組織主表id  
    ParentID：父id 
    ProcessOrganizationDetailID：流程組織明細id 
    Remarks：備註 
 

 

訊息模組

unReadMessage ：未讀的訊息表
    MessageID：訊息ID
    FromUserID：訊息源
    ToUserID：訊息目的地
    MessageTitle：訊息標題
    MessageContent：訊息內容
    MessageType：訊息型別?
    IsRead：是否讀過：（1是，0否）
    ReadDate：讀訊息的時間
    IsSend：是否傳送過（1是，0否）
    CompanyID：公司ID

messageHistory ：訊息歷史表
    MessageID：訊息ID
    FromUserID：訊息源
    ToUserID：訊息目的地
    MessageTitle：訊息標題
    MessageContent：訊息內容
    MessageType：訊息型別
    CreateDate：建立日期
    ReadDate：讀訊息的時間
    DeleteDate：刪除日期
    CompanyID：公司ID
 

readMessage ：已讀訊息表
    MessageID：訊息ID
    FromUserID：訊息源
    ToUserID：訊息目的地
    MessageTitle：訊息標題
    MessageContent：訊息內容
    MessageType：訊息型別
    CreateDate：建立日期
    CompanyID：公司ID
    ReadDate：讀訊息的時間

userMessage ：使用者訊息表
    UserID：使用者ID 主鍵
    NewMessage：是否發生訊息（1傳送，0不傳送）
    Remark：備註
    CompanyID：公司ID
功能：使用者向客戶端傳送訊息
發生訊息的時候：往這個使用者訊息表新增（沒有對應的UserID）或者修改（有對應的UserID）一條記錄,NewMessage=0
迴圈訪問這個表，當UserID對應的NewMessage=0時，unReadMessage表ToUserID=UserID，IsSend=0的所有記錄傳送給客戶端使用者（前端頁面迴圈訪問）,
並修改unReadMessage表ToUserID=UserID的IsSend=0
 

附件模組

fileUpload ：附件上傳表
    ID ：主鍵自增長
    UploadNO：上傳批次號
    FileID：檔案id
    UploadFileName：上傳檔名
    UploadDate：上傳日期
    FileType：檔案型別
    SavePath：儲存路徑 
    FileSuffix：檔案字尾
    Sequence：排序

fileUploadTemp ：附件上傳臨時表
    ID：主鍵自增長
    FileID：檔案ID
    CreateDate：建立時間
    SavePath：儲存路徑
    Size：檔案大小
    ErrorCount：檔案轉換錯誤次數
    ErrorMessage：失敗訊息（json,key=訊息內容，value=失敗次數）
    功能：用於附件上傳後的線上預覽的轉換（佇列形式轉換上傳附件，轉換成功就從該表刪除，轉換失敗）
 

02業務模組（只列一小部分）

activityScheme ：活動方案表
    ID ：主鍵
    ActivitySchemeID ：活動方案ID
    MakeActivityPeople ：經辦人
    MakeActivityPeopleID ：經辦人ID
    SchemeName ：方案名稱
    ActivityDate ：活動時間
    ActivityContent ：活動內容
    SumPeople ：多少人
    Remarks ：備註
    FileID ：檔案ID
    ActivityScope ：動活範圍
    Money ：金額
    AccountID ：科目ID
    ResidueBudget ：剩餘預算 

applicationBuy ：申購表
    ID ：主鍵
    ApplicationBuyID ：申購ID
    ProceedingName ：事項名稱
    ProceedingType ：事項類別
    UseTime ：使用時間
    State ：狀態
    Remarks ：備註
    Money ：金額
    IsBorrow ：是否借款：1是0否)
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

applicationBuydetail ：申購單物品明細表
    ID ：主鍵
    ApplicationBuyDetailID ：申購單物品明細ID
    ApplicationBuyID ：申購申請表ID
    ItemID ：物品編碼
    Name ：物品名稱
    ModelNumber ：型號
    Price ：單價
    Number ：數量
    Money ：禮品金額
    Purpose ：用途
    Remarks ：備註
    DetailSupplierID ：申購單物品明細與供應商關聯ID

applicationBuySupplierRelation ：申購單物品明細與供應商表
    ID 主鍵
    ApplicationBuyID ：申購申請表ID
    ItemID ：物品ID
    SupplierID ：供應商ID
    SupplierCode ：供應商編碼
    IsChoose ：是否選擇（0：否，1：是）
    ItemInformation ：商品資訊
    Link ：商品連結
    Superiority ：優勢
    Price ：單價
    DetailSupplierID ：申購單物品明細與供應商關聯ID

BankAccount ：銀行賬戶表
    ID ：主鍵
    BankAccount ：賬號
    Payee ：賬號對應的單位
    DepositBank ：開戶行
    BankAccountType ：賬戶型別
    IsActive ：是否啟用 0不啟用，1啟用
    IsDelete ：是否刪除 0沒刪除，1刪除
    CreateDate ：建立者日期
    CreateBy ：建立者id
    ModifyDate ：修改日期
    ModifyBy ：修改者id
    Remarks ：備註
    CompanyID ：公司ID
    BankAccountUnitID ：賬號對應的單位ID,可以是使用者ID，公司名稱，銀行名稱

borrowMoneyApplication ：借款申請表
    ID ：主鍵
    BorrowMoneyApplicationID ：借款申請表ID
    BorrowMoneyType ：借款型別
    RepaymentDate ：還款日期
    GatheringType ：收款方式
    GatheringAccount ：收款賬號
    Remarks ：備註
    ProceedingApplicationID ：事項申請ID
    Money ：金額
    ProceedingID ：申請編碼
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

businessEntertainment ：業務招待表
    ID ：主鍵
    BusinessEntertainmentID ：業務招待表ID
    BusinessEntertainmentDate ：日期
    CountPeople ：人數
    BusinessEntertainmentType ：招待的單位或職位
    StandardMoney ：招待標準：每人)
    BusinessEntertainmentAddr ：招待地址
    Remarks ：備註
    Money ：金額
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

cashier ：出納表
    ID ：主鍵
    SqNumbers ：申請單編碼
    ReimbursementID ：費用報銷編碼
    AccountID ：科目id
    ProceedingType ：事項型別
    Money ：金額
    DepartmentID ：部門ID
    ApplicationPeopleID ：申請人ID
    ApplicationDate ：資金申請時間
    State ：狀態： 0未申請，1申請中，2審批中,3拒單，4通過')
    CompleteTime ：完成時間
    PositionID ：流程職位ID
    CompanyID ：公司ID
    ResidueBudget ：剩餘預算
    ReimbursementMoney ：報銷金額
    ReimbursementDate ：報銷日期
    PaymentBankID ：付款銀行ID
    ProceedingExplain ：摘要說明
    Remarks ：備註
    GatheringAccount ：收款賬號

compact ：合同表
    ID ：主鍵
    CompactID ：合同ID
    CompactName ：合同名稱
    CompactType ：合同類別
    CompactNum ：同合編號
    ACompanyName ：甲方公司名稱
    BCompanyName ：乙方公司名稱
    ThirdCompanyName ：第三方公司名稱
    CompactMoney ：合同價款
    IsTaxAfter ：是否含稅：1是0否)
    IsBudget ：是否在預算內：1是0否)
    PayType ：支付方式
    IsInvoice ：是否提供發票：1是0否)
    CompactBeginTime ：合同起始日期
    CompactEndTime ：合同失效日期
    FileID ：檔案ID
    Remarks ：備註
    Money ：金額
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

costdetails ：費用明細表
    ID ：主鍵ID
    CostdetailsID ：費用明細ID
    ProceedingID ：申請編碼
    Type ：事項
    StartAndEndTime ：起止時間
    StartAndEndLocation ：起止地點
    Money ：金額
    Remarks varchar：2000) DEFAULT NULL,
    StartAddress ：起點
    EndAddress ：終點
    TravelTools ：出行工具
 

gift ：禮品
    ID ：主鍵
    GiftId ：禮品ID
    WinItemID ：獲獎禮品表ID
    ItemID ：物品編碼
    GiftName ：禮品名稱
    Unit ：單位
    UnitPrice ：單價
    GiftMoney ：禮品金額
    GiftNum ：數量
    Purpose ：用途
    ModelNumber ：型號
    Remarks ：備註

groupBuild ：團建表
    ID ：主鍵
    GroupBuildID ：團建表ID
    SumPeople ：參與人數
    LeaderID ：參與領導的ID
    ActivityDate ：活動時間
    ActivityAddr ：活動地址
    Reason ：存在的問題原因分析
    Question ：存在的問題
    Content ：活動舉辦的形式及內容
    Purpose ：活動的目的
    HowTodoFromPurpose ：如何確保活動達成目的
    HowTodoFromAssess ：如何進行可量化、可衡量之有效評估
    Money ：金額
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

item ：物品
    ID ：主鍵
    ItemID ：物品編碼
    SupplierID ：供應商編碼
    Name ：物品名稱
    ModelNumber ：型號
    Price ：單價
    IsActice ：是否啟用（1是0否）
    IsDelete ：是否刪除（1是0否）
    Remarks ：備註
    CreateBY ：建立者
    CreateDate ：建立日期
    ModifyDate ：修改日期
    ModifyBy ：修改者

itemSupplierRelation ：物品表與供應商的關聯表
    ID 主鍵
    ItemID ：供應商編碼
    SupplierID ：供應商編碼
    ItemInformation ：商品資訊
    Link ：商品連結
    Superiority ：優勢

mbudget ：月預算費用表
    MBudgetID ：預算費用id
    DepartmentID ：部門id
    AccountID ：科目id
    Remarks ：備註
    MonthMoney ：月預算金額
    Month ：x月的預算
    Year ：x年的預算
    CreateDate ：建立日期
    CreateBy ：建立者id
    ModifyDate ：修改日期
    ModifyBy ：修改者id
    CompanyID ：公司id

proceedingApplication ：事項申請表
    ID ：主鍵
    ProceedingApplicationID ：事項申請ID
    ProceedingID ：事項ID
    ApplicationTime ：申請時間
    ApplicationPeopleID ：申請人ID
    ApplicationPeopleName ：申請人姓名
    ApplicationDepartmentName ：申請部門名稱
    ApplicationDepartmentID ：申請人部門ID
    CompanyID ：公司Id
    PositionID ：申請崗位ID
    FileID ：上傳檔案id
    BusinessType ：業務類別：1事項申請，2事項報銷,3借款型別，4預算調整，5預算調整申請，6資金管理)
    ApplicationType ：申請類別：編碼來自資料字典groupID=11)
    ProceedingType ：事項型別（對申請型別的補充，比如申請型別是借款申請，借款申請的子型別是日常借款，編碼來自資料字典groupID=5，18，2）
    State ：狀態： 0申請中，1審批中,3拒單，4通過')
    CompleteTime ：完成時間
    Money ：金額
    Remarks varchar：2000) DEFAULT NULL,
    IsActive ：是否啟用：1啟用，0 沒有啟用)
    IsDelete ：是否刪除（1是0否）
    CreateDate ：建立日期
    CreateBy ：建立者id
    ModifyDate ：修改日期
    ModifyBy ：修改者id
    PositionTrueID ：操作人真實職位ID
    OperationDepartID ：操作人部門ID
    AccountID ：科目ID
    功能：是所有申請單的主表（優化活躍資料，優化主表和明細表）

proceedingApproval ：事項審批
    ID ：主鍵
    ProceedingApprovalID ：事項審批id
    ResponsiblePeopleID ：經辦人ID
    ResponsiblePeopleName ：經辦人姓名
    Money ：金額
    Content ：內容
    Purpose ：用途
    Result ：事項效果評估/結果說明
    IsBorrow ：是否借款：1是0否)
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

reimbursementPayment ：報銷付款表
    ID ：主鍵
    ReimbursementID ：報銷付款ID
    ApplicationID ：申請編碼
    GatheringPeople ：收款人/單位
    GatheringAccount ：收款賬號
    ReimbursementDate ：報銷日期
    Money ：付款金額
    CostAccount ：費用科目
    GatheringType ：收款方式
    ResidueBudget ：剩餘預算
    ProceedingExplain ：摘要說明
    IsInvoice ：是否有發票
    ExpectedDateInvoice ：預計收到發票日期
    Remarks ：備註
    ReimbursementMoney ：報銷金額
    InvoiceType ：發票型別
    depositBank varchar：1000) DEFAULT NULL,
    ResidueBudgetReimbursementMoney ：剩餘可報銷
    IsNewCostDetails ：是否是新的費用明細
    ProcessType ：流程型別

reimbursementPaymentInvoice ：報銷付款發票資訊表
    ID ：主鍵
    ReimbursementPaymentInvoiceID ：發票ID
    ProceedingID ：事項ID
    InvoiceDate ：發票時間
    InvoiceCode ：發票程式碼
    InvoiceNumber ：發票號碼
    InvoicePartyName ：開票方名稱
    TaxpayerID ：開票方納稅人識別碼
    InvoiceContent ：發票內容
    InvoiceType ：發票類別
    Remarks ：備註

remittanceHistory ：打款歷史記錄表
    ID  ：主鍵
    bankAccount ：銀行賬號
    bankAccountUnit ：銀行賬號對應的單位
    depositBank ：開戶行
    createBy ：建立者ID
    createDate ：建立時間
    operationDepartID ：操作部門ID
    companyID ：公司ID
 

supplementaryBudget ：預算調整正式表
    SupplementaryBudgetID ：追加預算id
    DepartmentID ：部門id
    AccountID ：科目id
    Applicantid ：申請人ID
    CompanyID ：公司id
    PositionID ：流程職位id
    Money ：金額
    State ：   // 狀態 0未申請，1申請中，2審批中,3拒單，4通過
    ApplicationDate ：申請時間
    Month ：追加預算的月份
    Year ：追加預算的年份
    Remarks varchar：2000) DEFAULT NULL,
    CreateBy ：建立者id
    CreateDate datetime DEFAULT NULL,
    ModifyBy ：修改者id
    ModifyDate ：修改者id
    SupplementaryBudgetCode ：預算調整申請編碼
    FileID ：上傳檔案ID

supplementaryBudgetApplication ：預算調整申請表
    SupplementaryBudgetID ：追加預算id
    SupplementaryBudgetCode ：預算調整申請編碼
    FileID ：上傳檔案ID
    DepartmentID ：部門id
    AccountID ：科目id
    Applicantid ：申請人ID
    Money ：金額
    State ：   // 狀態 0未申請，1申請中，2審批中,3拒單，4通過
    ApplicationDate ：申請時間
    CompanyID ：公司id
    PositionID ：流程職位idID
    Month ：追加預算的月份
    Year ：追加預算的年份
    Remarks varchar：2000) DEFAULT NULL,
    CreateBy ：建立者id
    CreateDate datetime DEFAULT NULL,
    ModifyBy ：修改者id
    ModifyDate ：修改者id

supplier ：供應商
    ID 主鍵
    SupplierID ：供應商ID
    SupplierName ：供應商名稱
    SupplierCode ：供應商編碼
    SupplierRatepayingCode ：供應商納稅識別號
    SupplierBank ：供應商開戶行
    SupplierTelephone ：供應商聯絡電話
    SupplierAddr ：供應商地址
    SupplierBusinessType ：供應商經營種類
    Remarks ：備註
    IsActice ：是否啟用（1是0否）
    IsDelete ：是否刪除（1是0否）
    CreateBy ：建立者
    CreateDate ：建立日期
    ModifyDate ：修改日期
    ModifyBy ：修改者

travelbusiness 差旅費申請單
    ID ：主鍵
    TravelBusinessID ：差旅費申請單ID
    TravelBusinessDate ：出差日期
    TravelBusinessAddr ：出差地址
    TravelBusinessReason ：出差理由
    IsBorrowMoney ：是否借款：1是0否)
    Money ：金額
    AccountID ：科目ID
    ResidueBudget ：剩餘預算 

travelcostdetails ：差旅報銷費用明細表
    ID：主鍵
    ProceedingID ：申請編碼
    TravelCostdetailsID ：費用明細ID
    Type ：事項
    PeopleID ：出差人
    StartTime ：開始時間
    EndTime ：終止時間
    Days ：天數
    Standard ：標準
    Money ：金額
    Address ：出差地點
    Remarks ：備註
    AddressID ：出差地點ID

ybudget ：
    YBudgetID ：年預算費用id
    DepartmentID ：部門id
    AccountID ：科目id
    Remarks ：備註
    YearMoney ：年預算金額
    Year ：x年的預算
    CreateDate ：建立日期
    CreateBy ：建立者id
    ModifyDate ：修改日期
    ModifyBy ：修改者id
    CompanyID ：公司id
    TotalSum ：合計
    TotalUsedSum ：累計使用合計
    RemainingBudget ：剩餘預算

winitem ：獲獎禮品表
    ID ：主鍵
    WinItemID ：獲獎禮品表ID
    ItemID ：商品id
    OfferPeopleID ：資料提供人ID
    AuditPeopleID ：資料稽核人ID
    StatisticsPeopleID ：資料統計人ID
    FileID ：檔案ID
    GiftId ：禮品ID
    Remarks ：備註
    Money ：金額
    AccountID ：科目ID
    ResidueBudget ：剩餘預算

其他表（因為太多，就不列了）

5 功能設計

 登入模組

1.  按公司分，不同的使用者登入後看到的資料不同。
2. 同一個使用者不同同時登入多個瀏覽器，確保只能登入一個瀏覽器，當有第二個人同時登陸同一個賬戶，前一個人的賬戶要被踢出。
3. 使用者登入的快取設計（redis的鍵設計），如果使用者有登入，那麼一定時間內，關閉瀏覽器，在開啟瀏覽器,使用者跳過登入。

選單模組

1 選單的樹形展示，選單和功能的curd

角色模組

1. 角色的curd
2. 角色許可權（選單和功能，團隊，科目）的設定和分配

部門模組

1部門的curd

科目模組

1. 科目的curd
2. 科目excel匯出

使用者模組

1. 使用者的curd
2. 使用者許可權設定
3. 使用者崗位設定
4. 使用者銀行賬戶設定

流程配置模組

流程的curd

資料字典模組

資料字典curd

流程審批模組

 

1. 流程審批需要跨越多個部門或者公司。
2. 對同一個流程節點可以有多個人審批，但只能有一個人審批過了，跳過下一個節點。
3. 流程的自動審批。打個比方說,流程審批節點如下fa--fb---fc--fa--fd。當流程執行到fc時，fc同意後，下一個節點自動審批，進入到fd。
4. 流程的批量審批。領導可以對多個申請的流程進行批量審批。
5. 流程的多級駁回
6. 流程審批過程中，動態修改流程引數

 

業務模組

業務模組都是一些經費申請，有些情況比較複雜，舉個情景說下。    

1填寫申購申請單。（申請100雙鞋,流程審批）,
    申請結果
        申請成功：跳轉到報銷付款申請
        申請失敗：從新發起申請或者拋棄該申請單（通知該使用者）
2報銷付款申請
    2.1情況一：多次報銷（每次報銷50雙鞋）
    2.2情況二：一次報銷（報銷100雙鞋）
    
    申請結果
            申請成功：跳轉到資金管理（這裡出納會給錢的）
            申請失敗：從新發起申請或者拋棄該申請單（通知該使用者）
3資金管理
        申請結果：
            申請成功：領錢
            申請失敗：從新發起申請或者拋棄該申請單（通知該使用者）
 

        
        
1填寫借款申請單。（申請100元,流程審批）,
    申請結果
        申請成功：跳轉到資金管理
        申請失敗：從新發起申請或者拋棄該申請單（通知該使用者）
2資金管理
        申請結果：
            申請成功：領錢100元
            申請失敗：從新發起申請或者拋棄該申請單（通知該使用者）

3報銷付款申請
    2.1情況一：多次還錢（每次還50）
    2.2情況二：一次還錢（還100）
    申請結果
            申請成功：跳轉到資金管理（這裡出納會收錢的）
4資金管理    
    2.1情況一：核算使用者沒還完（還差50元）,將申請單跳轉到2，迴圈直到還清
    2.2情況二：核算使用者已還完，申請結束