返回列表 回复 发帖
分时段,多技能,不就可以了吗。

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

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

COMPIERE在这方面的功能做到什么层次?!
1

评分次数

  • 纵横四海

应该可以的,只要不是用预定功能
sofar1218已经说过这个问题就是一个科目维度的表示.
compiere 可以到产品(资源,实际产品...)和业务伙伴(员工,销售商,采购商)
原帖由 aoslee 于 2008-10-13 16:58 发表
sofar1218已经说过这个问题就是一个科目维度的表示.
compiere 可以到产品(资源,实际产品...)和业务伙伴(员工,销售商,采购商)
看来通过科目维度功能可以直接输出不同维度的报表了! 否则的话还有根据信息的源头(原始业务单据)来关联查询!
如果会计维度还不能满足的话,你还可以多套账务, multi accounting schema, 比如成本核算方法一套帐用平均法,另一套用标准法;

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

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

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

[ 本帖最后由 sofar1218 于 2008-10-14 05:13 编辑 ]
附件: 您所在的用户组无法下载或查看附件
原帖由 sofar1218 于 2008-10-10 11:18 发表
OB的财务里有会计维度这样的概念,你可以把账务细化到公司的部门(比如销售),项目组,具体某个项目,甚至具体某个客户或供应商,到年终做财务分析的时候你不仅知道整个公司的收入,还可以计算某个部门贡献的收入, ...
有了会计维度这样的概念在出多维度的财务报表是就不用再与原始的单据相关联了?!
原帖由 sofar1218 于 2008-10-13 19:13 发表
如果会计维度还不能满足的话,你还可以多套账务, multi accounting schema, 比如成本核算方法一套帐用平均法,另一套用标准法;
写入一条科目数据看来要写多遍了,每套帐套写入一遍?!
原帖由 hotkee 于 2008-10-14 08:30 发表

有了会计维度这样的概念在出多维度的财务报表是就不用再与原始的单据相关联了?!
关联?不明白指什么? 手工帐的话就只有财务数据啊,自动转入的凭证都是跟原交易有联系的,从财务的数据可以追溯到采购,采购计划。
多会计模式不建议使用,太慢。因为如果你多建一个会计模式就意味着所有的过账都是多笔的,这种冗余是太大了!
将业务伙伴及产品作为科目写到可目标中个人认为就是要不访问原始信息表取得科目数据。
原帖由 hotkee 于 2008-10-14 09:08 发表


写入一条科目数据看来要写多遍了,每套帐套写入一遍?!
那可不知足吧
原帖由 sofar1218 于 2008-10-13 15:51 发表
走采购表示你不仅关注结果,还关注流程,比如你到年底可以看到某员工到底参与了多少项目,任何项目都不要他,是不是@@¥%%I&(*YH, ...
正好用在我司项目二期规划的功能要求之一:对开发人员进行绩效考核。

[ 本帖最后由 hotkee 于 2008-10-14 12:59 编辑 ]
原帖由 sofar1218 于 2008-10-13 16:28 发表
分时段,多技能,不就可以了吗。

直接走采购的话以中国人的思维来看有些牵强:这个不牵强,只不过暴露了商业的本质,东方讲究含蓄,需要遮掩一下;那些外包公司不就是叫bodyshop吗?俺也是开发人员,听着是不舒服 ...
  • “多技能”能否这样理解?!——将某个员工的某一种技能定义成某种价格的产品(如技术开发),而另外一种技能定义成另一种价格的产品(如项目管理),这样,就达到了同一个人在不同项目中因身份不同而使得项目采购人力资源成本不同的目的。
  • "分时段"具体如何实现?!以避免人力资源的采购冲突!
  • 与项目所需的物质采购在业务操作流程上有无区别?!如通过何种方式发起采购(人力资源和物质)、如何形成应付账款、如何将这笔费用结算到项目中?等等、、、
1 多技能:就是产品细分,就是那个意思
2 分时段嘛,按理说人力资源应该定义成独占的,就像设备租赁。这几天为项目A工作, 过几天为项目B工作,就算是实际情况是同时工作,作为项目管理来说也要在书面上分时计量;你允许一台设备某段时间既租给A,又租给B?
3 区别就是不需要入库,不计入固定资产 , 物质采购你拥有使用权和财产权,人力资源顶多可以计入知识产权(不过国内很少计算这个);
   应收应付根据合同啊,至少某个项目组要人也得写个申请吧,没有进入项目组的人归谁管(一般是事业部)?结算就看有没有预付款?借款?合同变更?
这些还是可以借鉴一下Fidic
THANKS  ALL !
大家来谈谈项目型ERP系统在做月结时的处理细节啊!
月结时项目、采购、库存、销售和财务模块分别要作何操作?!
如:一个实施项目要好几个月,那项目库存的领用有必要按月分配吗?要做暂估入库与出库吗?!
是否每个月都对人力资源采购并结算一次?!
费用在日常是做归集,在月结是如何结算?!

[ 本帖最后由 hotkee 于 2008-10-14 17:04 编辑 ]
adempiere 和 compiere
都不需要做月结转,什么时候发生什么时候记账即可。
“资产是您采购或自行生产的某物。与产品相比,产品总是被您拥有,而资产则不一定被您拥有。资产可能被您自己或其它人使用,但资产的主要特征在于您会独立地追踪和维护它。可选地,资产可以被卖出。简言之,资产可描述为某产品的个体。”
看来把我司的软件产品作为“资产”对待更合适?!
我司与客户签订销售合同,然后按照合同收款;项目实施的时候先将合同分解成若干实施项目来实施。
在COMPIERE中没有现成的合同管理模块,就用销售订单来代替吧?!CAN I DO THAT?!
考虑服务协议吧,服务是产品的话,这样就有SLA和协议收费周期的管理,相当于fidic的计价清单。合同的撰写尽量规范一些。这个在财务的绩效管理模块里。SLA:service level agreements,这个可以定义商业过程的服务级别和关键点,比如:响应时间(24小时之类?),到货日期等
这个阶段个人感觉搂主的思路应该差不多清晰了,如果想要继续完成的话现在应该做需求分析了,通过对系统地了解把最终要做的事情描述清楚,从而看出需要配置量,需要开发量,需要培训量,需要业务重组量,从而规划周期,人员,资金配置等等。
ps:过多的概念讨论很容易走向标准误区,从而造成最终目标的混乱
原帖由 sofar1218 于 2008-10-17 07:18 发表
考虑服务协议吧,服务是产品的话,这样就有SLA和协议收费周期的管理,相当于fidic的计价清单。合同的撰写尽量规范一些。这个在财务的绩效管理模块里。SLA:service level agreements,这个可以定义商业过程的服务级别 ...
将软件产品做为“资产”看待可行否?!
把合同作为“SLA”来处理的话与“资产”有冲突吗?应为服务是一种产品,资产也是一种产品,那到底是吧软件产品做为资产还是服务来看待呢?!
如何生成服务协议?如何对服务协议生成发票和收款?!
谢谢积极探讨!!!
原帖由 sofar1218 于 2008-10-17 07:18 发表
考虑服务协议吧,服务是产品的话,这样就有SLA和协议收费周期的管理,相当于fidic的计价清单。合同的撰写尽量规范一些。这个在财务的绩效管理模块里。SLA:service level agreements,这个可以定义商业过程的服务级别 ...
ad绩效管理主要用于员工的sla,即内部的人员工作监控,即主控页面的绩效页面的生成,并没有后续的处理
原帖由 hotkee 于 2008-10-17 09:52 发表


将软件产品做为“资产”看待可行否?!
把合同作为“SLA”来处理的话与“资产”有冲突吗?应为服务是一种产品,资产也是一种产品,那到底是吧软件产品做为资产还是服务来看待呢?!
如何生成服务协议?如何对服 ...
根据你公司的业务流程分析,个人感觉不应该建立什么资产或者产品,而是直接建立项目。
原帖由 hotkee 于 2008-10-16 14:28 发表
“资产是您采购或自行生产的某物。与产品相比,产品总是被您拥有,而资产则不一定被您拥有。资产可能被您自己或其它人使用,但资产的主要特征在于您会独立地追踪和维护它。可选地,资产可以被卖出。简言之,资产可描 ...
1  软件的开发过程属于设计或者研发,它的产品是代码和文档,这个东西的评估是困难的,一行代码算一块钱?显然不能这样,你卖出的是拷贝,知识产品拷贝的生产很简单(比如,复制光盘,印刷品等);

2  资产是商业管理和财务里的概念,你公司开发的软件可以作为公司资产入账,但是这个知识产品他的评估是需要第三方来进行,你要登记著作权等,总之很麻烦。

3  当然你可以计入公司的内部账务,比如公司启动一个项目部来开发某个产品,耗时一年,投入多少人力物力,这个成本在公司内部可以算作软件资产的估值(无形资产,再说这个软件没卖出去的话怎么信誓旦旦的说他值多少钱?)。但是不会得到国家的财税体系认可的,不能计入对公的财务账务里,你必须去评估,而这种评估大部分时候意义不大,著作权认证这个意义大很多,可以据此申请资质啊,税收优惠啊等

4 还有个问题是产品的研发是个持续的过程,不断改进的,所以大点的公司都有专门的研发部门,那个怎么计算研发的收益或者评估他们的绩效?这就是管理层面临的问题,比如:
  卖出一套产品,30%计入 销售部,30%计入实施,30%计入研发,10%计入后台支撑(行政,人力, 财务等)。

所以你要叫产品也是可以的,问题是你这产品生产一套很便宜(复制光盘,印刷品等),而且产品必须加上服务才值很多钱,(你想光给你一套sap的光盘和说明书,那值多少钱啊,可以忽略不计吧)

5 是不是再次的体会到卖软件就是卖服务?

6 当然如果是你做外包的话,你的代码文档要交付的,这样的话开发过程就是生产。所以开发过程到底是研发还是生产是相对的

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