电商业务之订单篇.doc

OFBiz业务分析整理 ORDER(订单) 2 ACCOUNTING(会计) 2 HUMAN RESOURCES（人力资源） 3 Security(安全) 3 Party(会员) 3 Product(产品) 4 ORDER(订单) The Order entities是用来管理销售订单和采购订单相关的信息以及和订单相关联的其他信息的。比如，一个客户会提交一个针对指定产品或者物品的请求，那么，在in the Order package中，刚才的客户请求就会被request这个实体来跟踪。 这个请求会被跟踪，并且会转变一个需求，这个需求会被用来创建一个工作流Work Effort来满足这个需求和满足该请求。一旦一个需求被创建，那么报价就产生了，如果，这个报价被客户接受的话，这个这个报价会被用来创建一个订单(Order)。一旦订单履行了，那么这个订单的发票（发货单）就跟着创建了。发票是Accounting entity package中的一部分。 订单是有三部分组成的，一个是订单表头(Order Header)，二是任意数量的订单项(Order line Items)，三是关于订单的详细描述的调整(Adjustments)。有各种关于订单的信息，这些信息或者和订单表头有关系，或者和单个的或者多个的表单项有关系。比如，订单的发货目的地和发货偏好设定这些信息，也许针对多个订单项是一样的，也许的各个订单项都不一样。 调整是用来包含这样的一些信息，这些信息描述能改变订单上的价格的、而且不是真实的货物或者出售的服务或者购买力的这样的一些东西。比如，包括税收、运送、折扣、附加费等等。一个具体的调整可以是一个固定的金额、可以是按照数量的固定的金额、可以是所有订单或者一个订单的总账的百分比。税收和运送被当做一种特殊的case来处理，每一个调整都可以指定是否要记入税收的总账或者运送的总账中去。 由于订单的创建，一旦支票创建，付款偏好针对自动支付能被跟踪。通过信用卡或者其他的电子手段支付尤其有用的。如果没有设置支付偏好，那么一个标准的货品计价和结算会被使用。 ACCOUNTING(会计) The Accounting entities是按照久远的普遍接受的原则比如像复式记账，有多个分层账户的总分类账，日记账和交易的过账和相应的条目。这个构造主要是基于OMG GL标准和在AR/AP上，做了扩展OMG GL的标准的工作。这和其他的诸如ebXML和OAGIS标准相互关系的很好。 The Accounting entities被组织起来，以至于，多组织的账户能够被管理。多组织可以是多个公司，可以是多个部门，可以是一个公司内部的其他的组织。每一个组织拥有各种各样的GL账户来使用，因此，它能够和用自己的主会计科目表的子集来操作。每一个组织能够拥有子集的富有灵活性的日记账，甚至，日记账的使用会尽可能的最小，这样有利于让系统自动创建和发布基于像采购和销售订单、支票、库存转移、支付、收据等这样的驱动程序和单据等商业事件触发的交易。 也有预算和在一个特定的财务期间的针对实际的GL账户平衡的预算调解(对账)的entities。 Entities针对固定资产(Fixed Assets)也是Accounting entity package中的一部分。这包括除了固定资产的维护和调度之外的折旧信息的entity等。 HUMAN RESOURCES（人力资源） The Human Resources entities记录人事、部门、职位、绩效、技能、资质、培训、应聘、履历、考勤、福利以及其他的人力资源相关信息。 Security(安全) The Security entities被用来做访问系统的各个部分的控制，包含用户的登录账户、登录审计数据、权限(许可)数据等等。额外的更严格的安全(保证)是通过Party entities和Parties相关的在各种指定角色的数据来实现的。 Party(会员) 一个会员可以是一个人、可以是一组会员。一个会员组可以是一个公司、一个公司内部的组织、一个供应商、一个客户等等。描述会员或者和会员直接相关的信息都在这些实体中。 其中一种和会员相关的像邮政地址、电话号码、电邮地址、网址数据的类型是联系机制。另外的相关的数据就是会员扮演的像客户、供方、员工、经理、跟单员等的角色数据。一般的，一个单个会员会扮演很多不同的角色和系统的各个部分打交道。 另外一类属于会员范畴的数据是关于会员之间的交流和协议数据。这些属于关系管理并且包含关于一个会员拥有的对于争议或者麻烦门票的信息。这些实体在Work Effort entities的计划和跟踪下这对这些争议进行探索和解决。 Product(产品) The Products entities