compiere 数据库架构，欢迎各位交流，多谢。

herome

准备先熟悉COMPIERE的数据架构，因为这个才是这个软件的核心，那些代码只是展现了这个架构。有了这个基础，再开始真正的系统应用，这样对具体的业务就能熟悉点，因为我是做电信的计费系统的，没有ERP经验，只能是这样一步一步摸索了，里边有不少错误或者不到位地方，欢迎各位指点，这里先谢谢各位，期待大家一起学习进步。

herome

权限管理：权限管理采用两层（组织和权限）对于每个任务和每个实体功能提供校验，0是默认值：
每个实体表引用组织表（ORG_ID），每个实体表有ACESS权限表，配置读写属性，同时引用ROLE控制功能特性，常用以下：
AD_LdapProcessor=>AD_LDAPACCESS，控制LDAP的执行
AD_TASK=>AD_TASKACCESS,控制本地任务的执行，可以有环境变量，可以是客户端程序
AD_FORM=>AD_FORMACCESS，控制显示的FORM，一个FORM就是一系列TAB的组合，一个TAB对应一个TABLE_ID
AD_WINDOW=>AD_WINDOWACCESS，窗口显示
AD_WORKFLOW=>AD_WORKFLOWACCESS,工作流执行权限
AD_PROCESS=>AD_PROCESSACCESS,视图、报表等执行权限
对于实体表的控制有三个级别：
AD_TABLE=>AD_TABLEACCESS，表级别
AD_COLUMN=>AD_COLUMNACCESS,列级别
AD_RECORD=>AD_RECORDACCESS,记录级别
系统的用户信息权限表：
AD_USER=>AD_USER_ROLE（控制权限）＝》AD_USER_ACCESS（控制读写属性），用户权限

herome

账户管理
系统统一的时间定义，时间是一个企业的生命线，系统可以设置一个实体（CLIENT）有一个日历，一个日历下有多个year，每年定义piriod.(C_CALENDAR,C_YEAR,C_PERIOD)

AD_CLIENT:定义部门信息，AD_CLIENTINFO：定义实体所显示的菜单和功能，AD_TREE是内容的组织方式，一般用来组织树状的MENU。
账户模块涉及表：GL_Category(总帐目录)－》GL_Budget总帐预算，用于实体下balance。
关键的账户定义过程：
一个CLIENT指定一个会计计划（ACCOUNT_SCHEMA）这样就指定了一整套的账户行为，而这个账户行为引用了M_PRODUCT（产品）形成了产品定价表，每个会计计划的具体账户，根据C_ValidCombination将行为和由C_ELEMENTVALUE结合元素类型（账户、账户信用等）确定的值一起形成账户ID，而C_AcctSchema_Element则定义一个会计计划下的元素（一般是组织，业务伙伴和项目等），而C_ELEMENT则是定义会计模式的行为（是否自然账户，是否有balance）
Fact_Acct＝》Fact_Acct_Balance＝》C_AcctSchema＝》M_Product_Costing＝》C_ValidCombination＝》C_AcctSchema_Element＝》C_ElementValue＝》C_Element＝》＝》C_SubAcct

herome

默认账户
所有的系统账户都引用C_AcctSchema会计计划，而C_AcctSchema_Default会计默认计划则定义默认的会计账户行为，一般会计下有如下账户：
a。产品。一个产品M_PRODUCT可以对应M_Product_Acct,而该账户中定义产品的销售账户、资产账户等,账户ID引用由C_ValidCombination结合元素值得到的ID值
b。产品组。M_Product_Category可以对应M_Product_Category_Acct账户，默认取产品账户。
C。资产和资产组账户。A_ASSET
D。业务伙伴和伙伴组。业务伙伴下又区分员工（C_BP_Employee_Acct）、卖方和消费者等，还有用户的扣留账户等。

herome

AD字典
AD字典是系统的界面核心，其数据组织为：
系统从AD_MENU读取菜单信息，如果遇到是物料、产品和BPARTNER时候，在读取AD_TREE（AD_TREE是主表，后边衍生的有AD_TREENODEMM-系统菜单，AD_TREENODEBP和AD_TREENODEMP等，这里必须要明白TREE和MENU并不是一个事情，TREE是一个数据组织方式，MENU只是树的一种，TREE_ID=10是MENU）根据菜单类型决定具体到哪个表读取数据，如果菜单有快捷键，则读取AD_MENUBAR。在AD_MENU中可以得到一个AD_WINDOW_ID、AD_TASK_ID,AD_PROCESS_ID,AD_WORKFLOW_ID。这里以获取到窗口ID为例：
一个窗口包含若干个TAB，一个TAB会有多个FIELD，一个FILED包含于一个TABLE下的COLUMN，所以引用关系是：
AD_TAB引用窗口，标志是哪些窗口引用TAB；一个TAB对应一个或多个实体TABLE，一个TABLE有多个列，一个列有一个ELEMENT（一般是负责报表的显示需要），一个TAB有多个FILED（FIELD是COLUMN的显示定义，可以这样说，COLUMN存储具体数据逻辑和值，而FIELD定义具体的显示方式），如果一个COLUMN值有引用关系，则引用AD_REFRERCE，而系统根据引用类型（L：是LIST方式数据，则从AD_REF_LIST读取，如果是T方式，则是从表中读取数据，从AD_REF_TAB读取），同时一个COLUMN可以定义CALLOUT（该字段是一个轻量的JAVA代码，在初始化和该列的值发生UPDATE后调用，一般用在比如单价、数量和总价格时，则总价格指定一个CALLOUT，每次数量变化后自动更新）；一个COLUMN可以有值校验定义，从AD_Val_Rule一般根据SQL语句校验。
用户自定义的窗口、TAB和FIELD分别存储于：AD_UserDef_Win、AD_UserDef_TAB和AD_UserDef_FIELD中。
AD_Attribute定义值校验属性和在AD_PROCESS_PARAM参数调用中使用，具体含义还不是太清楚

goodmorning

不错！
还有吗？

herome

我也看的是哪个ER模型图，一个一个看看模型，分析下数据，再对下代码，再写上边的那些记录。。后边再继续研读下去，期望各位的指点，多谢各位的鼓励。

herome

资产管理ASSET（以A_打头的表）
资产一般有折旧（Depreciation,折旧可以）、转移（delivery），系统的所有的折旧规则很单薄，没有可学习价值，后期有需要，建议自行设计结构。
拍卖管理AUCTION（B_打头的表）
主要管理拍卖议题（B_Topic），对于B_BID（竞价）对于卖方和买方进行管理，这个功能在国内应该不需要，可以直接从菜单上注释掉。

审核（Audit）
系统涉及的几个审核表：AD_Sequence记录每个表的主键SEQ获取方式，AD_Sequence_Audit对序列号的审核；AD_Session客户登陆系统记录，如果用户修改了系统表或者COLUMN记录，则记录到AD_ChangeLog；AD_WF_EventAudit工作流审核记录表；

银行&现金（BANK & CASH）
这部分看着比较模糊，后边再仔细看。该部分核心是C_PAYMENT、C_ORDER和C_INVOICE，还有C_CASH，C_CASHBOOK定义现金簿类型，C_CASHBOOKACCT定义现金BOOK的账户，C_CASHLINE定义每笔CASH交易的明细。另外，该部分还有催欠部分，C_DunningRun，定义催欠入口，LEVEL表定义催欠的级别，可选方式是PDF的传真或者邮件。一般国内这种方式不常用，所以该部分重点关注CASH部分。银行部分国内不知道用不，先可以不关注。

bank stament不明确什么意思和用途，先跳过，不关注

herome

业务伙伴(BPARTNER)
系统核心表是AD_USER和C_BPARNTER，其中USER表定义可以登陆系统的用户，一般有管理员、员工和业务伙伴；BPARTNER定义业务伙伴，包括员工、客户和供应商，如果有些用户可以直接通过网上下业务订单，则需要加入到AD_USER中。这里先介绍AD_USER扩展部分：AD_USERQUERY表定义用户执行指定操作的SQL语句，为此需要先定义用户执行权限，AD_UserBPAccess定义可以用户可以执行的权限，具体所指的请求类型用R_RequestType定义；每个用户需要定义关注的兴趣爱好，R_ContactInterest（兴趣）和R_InterestArea（兴趣大类），这个也是系统CRM的核心，所以个人认为CRM功能需要后期重点扩展。另外，每个用户登陆系统可以定义问候语，C_GREETING。
接下来，看下C_BPartner,一个业务伙伴可以拆分为：客户、员工和卖主，分别对应几个账户表为（C_BP_Customer_Acct，C_BP_Employee_Acct和C_BP_Vendor_Acct),而这些账户都通过会计模式表C_AcctSchema和一个指定的ACCT_ID关联起来，这样就定义了一个财务关系。一个业务伙伴，必须有营销上概念，系统的物理位置用C_LOCATION定义，但是一个业务伙伴必须有C_BPartner_Location，而这个表就是讲营销区（C_SalesRegion）和物理位置结合起来定义的。
业务伙伴可以分组（C_BP_Group），系统中组的概念就是将具体元素对象归类，它用于和元素一起的所有业务属性，比如一个业务伙伴可以定义价格（M_PriceList）和折扣率（M_DiscountSchema），同样一个业务组也同样可以；一个伙伴可以定义催缴（C_Dunning，里边根据催缴LEVEL和具体类型定义邮件和传真），一个组也可以。业务伙伴同时定义支付规则（C_PaymentTerm），比如一次支付打折9.8折等；定义C_InvoiceSchedule发票计划（具体业务含义不清楚）；可以定义多个业务伙伴之间的关系C_BP_Relation，比如A伙伴可以为B伙伴付费或者大于发票等；可以定义业务伙伴的扣留（C_BP_Withholding，该表继承于C_Withholding），对于扣留可以理解为：如果是员工，比如代扣公积金等。定义伙伴的银行账号（系统所有银行账号都按照C_BP_BankAccount－》C_Bank＝》C_BankAccount＝》C_Currency定义）

collabration协作管理
系统对于协作管理，主要是CHAT表设计，其实这里设计到协作管理的，可以有chat和电话业务管理。CHAT的核心可以由CM_Chat扩展，包括聊天类型、CM_ChatEntry记录聊天记录，

commission委托
跳过，不明白业务含义


common application基础应用
该部分讲述系统的基础实例表，主要是业务伙伴和产品扩展出来。以下分几条线阐述：
  a).日期。C_NonBusinessDay（定义节假日）－》C_Calendar（定义一套日期，一个实体一般一个）－》C_Year（定义系统定义年份）－》C_Period（系统月份）＝》C_PeriodControl（日期和文档关联管理，好像不太对这里）
  b).会计部分。C_ValidCombination引用C_ElementValue和C_Element定义银行账户，银行(C_BANK)定义银行账户（C_BankAccount），C_BP_BankAccount也引用自C_ValidCombination。每个账户定义伙伴类型C_Currency，每中货币类型要定义和本地的汇率转换C_Conversion_Rate，
  d).位置信息。C_COUNTRY定义国家，C_region定义省份，C_City定义每个省份的城市，C_LOCATION定义每个城市的街道位置，C_BANK引用C_LOCATION_ID定义银行地址。
  e).产品。M_PRODUCT，一个产品指向一个仓库M_Warehouse，一个仓库可以是一个真正的仓库实体，也可以是一个虚拟仓库实体（比如人力资源和咨询），一个产品引用税率目录ID，C_TaxCategory，税率目录引用C_TAX，一个税率一般引用一个国家ID，这个是国税。象国内环境，这里应该引用到REGION一级。
  f).业务伙伴。业务伙伴有员工、卖主和客户，分别对应三者的账户。业务伙伴可以定义扣留。。这里和上边的业务伙伴部分类型，唯一不同的是多了一个C_Campaign营销策略，这里感觉可以监控一个公司的营销方向，比如展会和广告投放等，其中C_Channel定义营销取道或者方式。不过这里不明白的是，为什么C_PRODUCT和C_ValidCombination要引用营销ID

content manage内容管理
这部分定义WEB部分，先跳过不处理


COUNTRY部分关键要清楚COUNTRY/REGION/CITY/LOCATION的关系就可以


CRM
COMPIERE的CRM功能相当弱，使用C_PROJECT表述，意思是跟进一个客户的过程，就是一个项目的进展。C_Phase定义和客户接触的阶段，有访客、有意向和顾客。C_CycleStep和C_Cycle定义和顾客的接触阶段。同时一个顾客的跟进，可以有优惠的支付手段（C_PAYMENTTERM）等

CURRENCY货币转换
这个模块很简单，直接跳过

数据复制DATA_replatition
从入口表AD_Replication定义目的地址和端口，AD_ReplicationStrategy定义复制策略，AD_ReplicationTable定义复制表，AD_Replication_Log记录复制日志

xuchanghong

框架分析的不错,谢谢!!

java_go

楼主，接着往下吧，期待着

fatkids

楼主很强！期待中。。。。

vito_fh

确实好东西，继续等待

vito_fh

是否可以共享一下您的开发指南 或者 数据库 E-R 中文模型 呢，
我的email: ricardo-fLu@hotmail.com

herome

楼上的朋友，你好，那个ER模型就是compiere代码里边的那个，没有中文的；开发指南也没有，我不是他们的合作伙伴，也是个人。
只是相信compiere这么好的东西，好好做好支持和本土化，肯定在国内有很大市场的。
最近，没有写这个，我都在看财务知识和那个260的用户手册了。

多谢各位的支持，也期待更您的指导。

vito_fh

怪不得，你写的都是财务的呢。我的理解方法就是看个页面，找到对应的表，再看看各个字段大概意思；很多都搞不懂啊～功能是强大，但感觉很多不适用哦～个人意见而已。。。。

flyit2008

我也看了，很支持楼主

fatkids

不知道用逆向工程能不能导出UML模型和数据库模型

Miles.C

一个TAB对应一个或多个实体TABLE==> 僅可對應一個，但COMPIERE 之TABLE 也可以是資料庫中的VIEW，故可彈性應用。 另，TAB 可"包含"另一個TAB，達到 MASTER / DETAIL 同一個畫面同時呈現

COLUMN存储具体数据逻辑和值，而FIELD定义具体的显示方式==> FIELD 的顯示"控制" 僅在於畫面中的"位置"(上下 & 左右), 顯示長度 ( 不需要和資料庫相同), 動態顯示的邏輯 (displaylogic) , 排序 等等, 至於與數據本身性質相關的邏輯, 主要還是在 COLUMN 的 REFERENCE 欄位來設定 .  雖然FIELD 仍可以使用 'REFERENCE OVERWRITE' & 'Mandatory Overwrite' 來改變COLUMN的設定, 畢竟COLUMN設定修改後, 所有該欄位地畫面處理方式也同步變更, 由COLUMN 設定還是比較一致
==> COLUMN 藉由 REFERENCE 的不同設定, 畫面也會有不同的顯示方式  EX: DATE屬性 畫面點選該欄位時出現日期輸入小視窗, NUMBER屬性可輸入小數資料, INTERGER 僅接受整數資料, TIME屬性僅接受"時間"輸入 ( 資料庫存的是 1970/1/1 的時間)
==> 若COLUMN 為另一資料表格的 KEY 名稱時, TABLE DIRECT 屬性可以讓你直接於畫面呈現該資料之內容, 例如訂單明細中的產品資料, 資料庫存的是產品的 KEY 值, 畫面則是 產品代號 & 名稱 ( VALUE & NAME ) , 而且你可以在TABLE/COLUMN 中調整本資料想呈現的欄位 & 順序
==>COLUMN 的屬性(REFERENCE)為TABLE時, 你還可以設定'REFERENCE KEY' (和 LIST屬性效果類似) 讓你從下拉式視窗中選取指定資料表  符合你設定條件的資料, 如果你再加上 VALIDATION RULE 設定, 更可以依據其他欄位資料異動 動態的調整下拉式選單資料  ( 例如 訂單資料中選取 客戶 之後, 可在挑選 出貨地點, 更改客戶之後, 地址選單資料也會跟著改變, BUT 沒有去點選可不會修改資料庫... )   該REFERNECE KEY 也就是樓主所提到 AD_REFERNECE 中類別為 T 者
==> COLUMN 的屬性(REFERENCE) 也是存放在 AD_REFERENCE 中, 但類別為 D ( DATA TYPE )
==> 屬性為LIST 時, REFERENCE_KEY 超連結(LINK)出去可以維護畫面中下拉式資料的選項 ( AD_REFERENCE 之類別為 L: list )
也就是說畫面上的顯示邏輯, 基本上仍以COLUMN 設定為主 ( 除非在FIELD中使用 REFERENCE OVERWRITE 的功能)

一个COLUMN可以定义CALLOUT（该字段是一个轻量的JAVA代码，在初始化和该列的值发生UPDATE后调用==>該JAVA代碼是在游標離開'該欄位' 時觸發, 非該列資料值異動時調用.  該JAVA 代碼執行後, 該列資料是否異動要看使用者有沒有"存檔"  EX:訂單明細中, 修改數量, 單價, 產品單位 等欄位 在AD_COLUMN 中都使用同一個CALLOUT, 幫你即時計算本項次 & 本訂單之正確金額

pophu

楼主慢慢看吧