基于COMPIERE之上开发项目流程管理与项目成本核算系统

aoslee

我有以下几点建议:
1.先确定到底要做什么，个人认为如果不将openbrave,compiere或者adempiere进行比较详细的规划整合其实是很难达到楼主的全部要求的。而且感觉要做的东西和讨论的东西有些偏差，希望楼主先做好定位。
2.如果做预算的话可以参照产品标准成本方法计算方法来实施，一层BOM
3.不建议将人力工资同项目成本核算一同考虑
4.项目实际成本核算建议使用资源方式来考虑.资源=一类人。资源可以定价从而形成转化。
项目可以进行资源的领用，从而实现项目成本的实际核算。
5.项目计划不建议同这些混到一起，感觉有些乱，可以独立考虑最后联合

hotkee

原帖由 aoslee 于 2008-10-13 11:49 发表
我有以下几点建议:
1.先确定到底要做什么，个人认为如果不将openbrave,compiere或者adempiere进行比较详细的规划整合其实是很难达到楼主的全部要求的。而且感觉要做的东西和讨论的东西有些偏差，希望楼主先做好定位 ...

为何不建议将人力工资同项目成本核算一同考虑呢？？？

项目实际成本核算一定要从薪酬系统中取得。因为某个开发人员的薪水计算其实相当复杂，包括基本工资，加班工资，奖金，病假扣发等。这些不是经过简单“资源”定价就能计算出来的。而开发人员的工资都将分摊到他所参与的每个项目中。
用“资源”的话感觉在项目标准成本核算中比较合适：分别给不同级别的人员定义不同标准的人天的价格，此价格乘以天数即为此人力成本的标准成本金额。

aoslee

人力工资是以员工为基础的,员工是业务伙伴。
资源是产品类别的，可以采购销售的。
项目成本核算分三类:
1.计划成本：（计划工时*标准费率(资源价格))
2.标准成本: (实际工时*标准费率(资源价格))
3.实际成本：（实际工时*实际价格(实际工资))
个人认为可以达到2层次在项目管理上就很不错了
主要是实际工资很难确定，当一个人在多个项目中怎么来确定他在这个项目中的工资呢？
在A项目中是项目经理，在B项目中是程序员，在C项目中是框架师,三个项目同时进行此人的工资怎么分摊？
问题很多，请楼主斟酌

[ 本帖最后由 aoslee 于 2008-10-13 14:10 编辑 ]

sofar1218

原帖由 aoslee 于 2008-10-13 14:07 发表
人力工资是以员工为基础的,员工是业务伙伴。
资源是产品类别的，可以采购销售的。
项目成本核算分三类:
1.计划成本：（计划工时*标准费率(资源价格))
2.标准成本: (实际工时*标准费率(资源价格))
3.实际成本：（ ...

分摊是个一刀切的近似简化方法，就像邮票价格，他优先考虑实施难度（容易), 而牺牲公平。

所以分摊注定是一种粗略的算法。我也推荐采用内部市场模拟，这本身也是 compiere的核心思想（要不怎么把员工也看做商业伙伴呢）；
我以前的帖子也说过，知识生产者的劳动评估目前多半就是技能工资x时间（IBM也这样），作为人力资源采购计入成本，至于说请假那就是时间上折扣呗，保险那些费用计入公司的运营成本就是了。

项目组和事业部完全可以看成没有法人资格的子公司。一个人多角色那也要分解，至于每个角色算多少天，那还不是人来估算啊（不就是个大约的合计合计嘛，这个人到底分量多少还不是要在管理人员心里的称上衡量，不就是把感性的认识给个数字表达出来吗，就像你说某某美女外表可以给80分）

sofar1218

作为成本中心，或者核算中心，所有支出都走采购流程， 所有收入都走销售流程， 进销存，进销存！一进一出，干净利索， 这就是西方原子化的思维！分割不了才分摊，比如资产损耗。

如果是临时工这样的就直接用费用表入账，不走采购；

走采购表示你不仅关注结果，还关注流程，比如你到年底可以看到某员工到底参与了多少项目，任何项目都不要他，是不是@@￥%%I&(*YH，再说某个员工作为一种资源( 是不是独占类型也可以定义吧？不记得了)如果被某个项目组订购，那么别的项目组就无法下单要他，这些都是流程带来的规范，要不拿erp干嘛，直接电子表格多好

[ 本帖最后由 sofar1218 于 2008-10-13 16:15 编辑 ]

hnjzmc

学习呀

hotkee

原帖由 aoslee 于 2008-10-13 14:07 发表
人力工资是以员工为基础的,员工是业务伙伴。
资源是产品类别的，可以采购销售的。 ...

如何在系统中做到某个人既是业务伙伴中的员工又是产品中的资源？！

sofar1218

业务伙伴有分类的，其中就有雇员，客户，供应商and so on，雇员的技能可以定义成产品的啊

aoslee

to sofar1218 最好不要用业务伙伴类别这种软分类做
建议在员工的字段中加一个资源ID即可，后期怎么处理都可以。
to sofar1218 谢谢支持

hotkee

原帖由 sofar1218 于 2008-10-13 15:51 发表
所有支出都走采购流程， 所有收入都走销售流程， 进销存，进销存！ 这就是西方原子化的思维！分割不了才分摊，比如资产损耗。

如果是临时工这样的就直接用费用表入账，不走采购；

走采购表示你不仅关注结果，还 ...

开发人员的工资看来不用走分摊流程了，直接走采购的话以中国人的思维来看有些牵强。
应该能重复采购吧？！否则一个员工就不能同时参与多个项目了！真不能的话做何种调整以达到重复采购的目的。

sofar1218

分时段，多技能，不就可以了吗。

直接走采购的话以中国人的思维来看有些牵强：这个不牵强，只不过暴露了商业的本质，东方讲究含蓄，需要遮掩一下；那些外包公司不就是叫bodyshop吗？俺也是开发人员，听着是不舒服，慢慢习惯吧。
另外：compiere.com.cn上的版本也是一个分支，就是修改过的版本，不是仅仅汉化！！

[ 本帖最后由 sofar1218 于 2008-10-13 19:03 编辑 ]

hotkee

财务核算要做到按公司部门、销售区域、产品线和单个项目来核算。
为了达到这个目的，目前用友等财务系统都提供“辅助核算”功能。辅助核算是针对科目的，是对账务处理的一种补充，即实现更广泛的账务处理，以适应企业管理和决策的需要。  
辅助核算一般通过核算项目来实现。核算项目是会计科目的一种延伸，设置某科目有相应的辅助核算后，相当于设置了该科目按核算项目进行更为明细的核算。
但核算项目又不同于一般的明细科目，它具有更加灵活方便的特性，一个核算项目可以在多个科目下挂接。而且一个会计科目可以设置单一核算项目，也可以选择多个核算项目，例如可以将应收账款(1131)科目同时设置为往来核算与部门核算，方便进行财务管理。
设置核算项目的目的至少有两个:
1、在财务系统总账中，简化会计科目的设置，核算项目的对象越多、涉及核算项目的会计科目，减少的工作量越明显，这实际上是利用了数学上的组合原理；
2、使用核算项目的目的，不仅仅是为了总账，而是保证书ERP 不同子系统的关联，比如“客户”就是贯穿 销售、应收到总账的的一条红线。

COMPIERE在这方面的功能做到什么层次？！

aoslee

应该可以的，只要不是用预定功能

aoslee

sofar1218已经说过这个问题就是一个科目维度的表示.
compiere 可以到产品(资源，实际产品...)和业务伙伴(员工，销售商，采购商)

hotkee

原帖由 aoslee 于 2008-10-13 16:58 发表
sofar1218已经说过这个问题就是一个科目维度的表示.
compiere 可以到产品(资源，实际产品...)和业务伙伴(员工，销售商，采购商)

看来通过科目维度功能可以直接输出不同维度的报表了！ 否则的话还有根据信息的源头（原始业务单据）来关联查询！

sofar1218

如果会计维度还不能满足的话，你还可以多套账务， multi accounting schema, 比如成本核算方法一套帐用平均法，另一套用标准法；

compiere的设计者好像就是财务出身的吧，这套十年前着手设计的财务系统，今天看来也不落后吧。

在基础参数配置的时候叫会计维度，等到具体数据录入的时候叫科目组合（就像java里的对象定义时叫class, 创建时叫object），adempiere 提供了三维，把 组织机构， 产品 ，以及业务伙伴的组合跟会计科目关联起来；

OB提供了五维，加了项目和销售，销售比如你可以定义销售区域（西南，东北等）。

[ 本帖最后由 sofar1218 于 2008-10-14 05:13 编辑 ]

hotkee

原帖由 sofar1218 于 2008-10-10 11:18 发表
OB的财务里有会计维度这样的概念，你可以把账务细化到公司的部门（比如销售），项目组，具体某个项目，甚至具体某个客户或供应商，到年终做财务分析的时候你不仅知道整个公司的收入，还可以计算某个部门贡献的收入， ...

有了会计维度这样的概念在出多维度的财务报表是就不用再与原始的单据相关联了？！

hotkee

原帖由 sofar1218 于 2008-10-13 19:13 发表
如果会计维度还不能满足的话，你还可以多套账务， multi accounting schema, 比如成本核算方法一套帐用平均法，另一套用标准法；

写入一条科目数据看来要写多遍了，每套帐套写入一遍？！

sofar1218

原帖由 hotkee 于 2008-10-14 08:30 发表

有了会计维度这样的概念在出多维度的财务报表是就不用再与原始的单据相关联了？！

关联?不明白指什么？ 手工帐的话就只有财务数据啊，自动转入的凭证都是跟原交易有联系的，从财务的数据可以追溯到采购，采购计划。

aoslee

多会计模式不建议使用，太慢。因为如果你多建一个会计模式就意味着所有的过账都是多笔的，这种冗余是太大了！
将业务伙伴及产品作为科目写到可目标中个人认为就是要不访问原始信息表取得科目数据。