2. iDempiere实战(实施)【7】 - 创建用户、员工

现在已经创建了组织,接下来维护用户、员工。

iDempiere的用户和一般系统的用户概念比较接近,定义了系统的使用者。而iDempiere的员工使用了客户供应商的结构,这个做法似乎更加大胆,我个人是在2005年左右第一次接触SAP的时候客户供应商的表设计可能是有问题的,或者说设计思想过于古老,至于国内的软件中能看到把客户供应商合并在一个表里面的话,最早大概也是2000年左右才看到的。可是没有想到,Compiere可以在上个世纪九十年代把员工也加进来,并且让人感觉依然十分合理,当然,我是井底之蛙的可能性更大一些。至于如何理解员工为什么和客户供应商绑定在一起比较合适,我觉得首先我们应该理解了员工和用户为什么要分开,一旦这两个概念分开了,我觉得员工其实是一个蛮鸡肋的东西,幸好iDempiere也传承了Compiere/ADempiere的设计,把这三者统一在了一起,随着理解的深入,相信在很多的场合都会让然叹为观止。这里再次敬仰一下大神们。当然,个人还是希望数据结构一样,但是维护员工的页面能再做一个就好了。

 

问题:还有一个销售代表的问题之后需要解决,也不知道这样配置是否正确。

1. 维护用户

    使用用户页面维护用户信息。

2. 维护员工

    使用业务伙伴页面维护员工信息。

3. 建立用户和员工的关系

    在用户页面的业务伙伴中选择于员工信息。

 

到这里为止就应该没有什么问题了,但是由于个人喜好,我还需要解决一个部门的问题。我在设计组织时制作两个分支,我维护了iDempiere的组织,同时也维护了我自己想要的部门,两者是使用组织类型区分的。

同时我个人认为员工是挂在部门下的,所以在用iDempiere来实现的时候,我还是对部门是挂在用户下还是员工下犹豫了一段时间。

我们看用户的页面会有很多个人相关的信息,而员工(业务伙伴)上更多的是一些业务往来相关的信息,只是按照iDempiere的结构来看似乎挂在用户上更合理,出于个人的习惯,我尝试把业务伙伴和部门进行关联。

注:当然,部门和员工的关系不应该是1:N的,但是为了简化问题解决方法,尝试用这个关系来推进。

1. 维护引用

    

    

 

    注:我添加的叫部门的组织类型的ID为100003,本来条件SQL应该可以写的更好一点。

2. 在业务伙伴表中添加部门字段(格式同组织)

3. 把该字段反映至iDempiere的应用字典中

4. 指定该字段使用1里配置的引用

5. 在业务伙伴页面中添加部门字段 

    业务伙伴页面效果     

        

    部门内容选取子页面效果

       

    再回顾一下组织树的构成,确认的确部门分支的内容显示出来了。

      

 

发布对象菜单: