OFBiz业务培训(04)-订单管理

OFBiz业务培训系列订单管理hongs目录•订单和订单条目、订单条目关联•订单当事人和联系机制•订单调整•订单状态和订单条款•需求•请求•报价•协议、协议项目、协议条款、协议定价。•协议到订单的关系1标准订单模型•大多数组织机构的订购活动是使用标准数据模型来建模的,这种模型在许多关于数据模型的教材中都有介绍。下图给出了这个标准数据模型的图示。标准订单模型•销售订单行项•销售订单•客户•产品•购买订单行项•购买订单•供应商2订单和订单条目•订单实体分为销售订单和购买订单，涵盖了销售和购买订单。订单由订单条目组成，指明了订购的产品，从而说明了和产品的关系。•在订单中名为订购日期的属性指明企业接收或是发出订单的日期。进入日期属性是订单进入企业系统的日期。订单实体为了容纳与销售订单或购买订单有关的特定属性或关系，分为销售订单实体和购买订单实体。•订单条目描述了对特定产品或服务的订购。因此，每个订单条目用一个且只有一个产品来定义。订单条目有数量属性。对于货物，它描述了订购的货物数量。对于服务，它描述了应该付款的小时数、天数或其他度量数。对数量的度量单位由和产品关联的试题单位来决定。单价属性存储了条目的收费或服务的费用。预计交付日期是货特预计被装运到客户的日期或是服务预计履行的日期。装运说明属性存储了运送产品到目的地的说明，例如，“禁止外放”、“易碎—小心轻放”或“交付时需要客户签名”。备注属性用于对订单条目的附加解释。条目描述属性提供了一种机制用于存储条目描述，这些条目是非标准的，不会在产品或产品特征实体中被维护。•条目描述属性也能说明非产品特定的订单，诸如完成工作计划或是预定专业服务的时间的订单条目。订单条目也能和一个或多个工作计划有关。订单和订单条目•订单条目（购买订单条目、销售订单条目）•产品•产品特征（产品质量、颜色、维、尺寸、品牌、软件特征、硬件特征、付款特征、其他特征）•订单（购买订单、销售订单）3订单当事人和联系机制•在订单中包括的主要当事人如下：下订单的当事人；接收订单的当事人；接收订单交付的当事人；为订单付款的当事人；安装和/或装配产品的当事人；在订单中涉及到的各种各样角色的人，诸如：录入订单的人、确保质量的人、管理订单的人等等。销售订单当事人和联系机制•联系机制•订单条目•订单•订单角色•当事人角色•当事人3.1销售订单当事人和联系机制•每一销售订单和销售订单条目有许多当事人角色子类和与当事人角色有关的联系机制.一个销售订单可能由下单客户下单,被内部组织联络员接收,产生一个需求账单给付款客户.•1、下单当事人和相关的联系机制：订单可能由个人或是组织下发,这取决于需要搭建系统的组织机构的业务需要.在邮购目录行业中,订单通常由个人下发。当事人关系实体可以识别出某些类型的当事人是否被允许为该企业下单，例如检查是否存在一种有效的经纪人关系。•2、接收订单当事人和相关的联系机制：订单总是由当事人人来接收。•3、装运目标当事人和联系机制：在一些情况下，订单由一个当事人下发，发送给另一当事人。•4、付款当事例和联系机制：订单需要指明负责为订单付款的当事人和联系机制，联系机制人微言轻订单的账单运达场所（通常是发票送往哪里）。具有需求账单的销售订单到一个付款客户间的关系指明了负责为发票付款的当事人。从具有需求账单的销售订单到联系机制间的关系指明账单送往哪里和接下来在哪里支付。•5、订单的人员角色：除了前面提到的主要订单关系之外，许多其他的当事人也涉及到订单处理中，例如交付订单的人员、处理订单的人员、批准订单的人员、协调安装的当事人和负责履行订单的当事人。购买订单当事人和联系机制•联系机制•订单条目•订单•订单角色•当事人角色•当事人购买订单当事人和联系机制•这个数据模型和前面的模型非常类似。因为销售订单和购买订单描述了当事人间的约定，不管是在购买方还是销售方，每个当事人都需要跟踪订单的细节。唯一的区别是涉及到的角色名称不同。通用订单角色和联系机制•订单条目角色•订单条目角色类型•当事人•订单角色•订单角色类型•订单条目•订单条目联系机制•联系机制•联系机制目标类型•订单•订单联系机制通用订单角色和联系机制•每个订单可能涉及到一个或多个订单角色，每个角色被指定给一个当事人，并由一个订单角色类型描述。通过在订单角色类型中存储这些可能的角色然后将它们关联到订单角色的方法，这个结构能处理任何数量的用于销售订单或购买订单的角色。可能的订单角色类型包括“下单当事人”、“付款客户”、“内部接收订单组织”、“下单客户”、“下单购买方”、“供应商”、“付款购买方”、“订单录入人员”、“订单销售人员”和“订单授权人员”。每个订单条目也可能有订单条目角色类型中的订单条目角色，这些类型包括“装运目标购买方”、“装运目标客户”、“安装客户联系员”和“安装员”。•每个订单有一个或多个订单联系机制，每个订单条目有一个或多个订单条目联系机制用于记录地址、电话、传真、电子邮件或者其他联系机制，用来确认、装运、付款、接收或安装这个订单。联系机制目的类型维护诸如“装运目标”、“付款”、“确认”、“下单”或“通过…接收”的值来描述联系机制中的角色。联系机制实体存储了与订单关联使用的实际地址、电话号码、传真号码、电子邮件地址或其他联系机制。4订单调整•订单的有些部分不反映特定产品或特征的订购。例如折扣、额外费、加工费、装运和处理费。•如果这些调整流器被视作订单条目的子类，那么在订单条目之间需要存在一个递归的关系，用于把这些调整流器与合适的其他订单条目关联起来。这种数据类型有些复杂，因为许多这样的调整可能会影响到订单和订单条目中的一个或同时影响两者。•出于这些原因，订单调整被作为独立的实体表示出来。子类是折扣调整、额外费调整、销售税、装运和处理费、手续费和杂项收费。折扣调整和额外费调整是存储对整个订单或每个订单条目的价格调整的子类。这些价格调整可以是金额或是百分比。订单调整•销售税查找•地理范围•产品类别•订单调整（杂项收费、折扣调整、额外费调整、销售税、装运和处理费、手续费）•订单调整类型•订单条目•订单订单调整•销售税提供了对整个订单或一个特殊的订单条目征收销售税的信息。装运和处理费会给订单或订单条目增加一个订单调整。手续存储诸如“订单处理费”涵盖安排订单的装运所需费用的“处理费”以及“管理费”。•杂项收费子类提供了一个机制，用于存储有关可能在订单中产生的任何其他收费的信息。一个例子是用“错误调整”来纠正先前的订单。订单调整类型实体实现这个的一个功能，可以把各种类型的调整分类到细目录。描述属性定义了与调整有关的可能值。•销售税查找表实体存储了销售税百分比，这个百分会随地理范围，诸如县、市或州变化，也可能随产品类别变化。例如，仪器与非腐烂的产品相比，有不同的税收内容。一些类型的产品是免税的，可通过把它们和“免税”产品类别关联来分类。4.1订单状态和订单条款•订单状态实体来了解订单和订单条目的当前状态，同时跟踪进度情况。订单状态类型维护可能的订单状态。订单条款实体跟踪与订单和订单条目相关的业务条件。条款类型实体维护可以使用的条款。订单状态和条款•订单条款•条款类型•订单条目•订单状态•订单状态类型•订单4.2订单状态•由于订单在不同的时间点可能处于不同的状态。订单状态的状态日期属性提供了对每一个订单状态的发生时间进行踊跃的手段。4.3订单条款•涉及到的当事人可能会对许多协定和条款达成一致。交付条款、退换或退款政策和未履行的惩罚都是一些例子。每一订单或订单条目会有一个或多个订单条款，每一条款由条款类型来分类。条款值属性只应用于订单条款的一部分，它的意义取决于条款的类型。5订单条目关联•有时，存在从一个订单条目到另一个订单条目的关系。图4-8中订单条目关联实体把销售订单条目和购买订单条目联系起来。•这种关联的一个例子发生在当销售订单条目依赖于购买订单条目的时候。例如，批发商可能会收到一个销售订单，但可能没有足够的库存来满足该订单上某个条目的要求。反过来，批发商会向他的一个供应商下一个购买订单（或向许多供应商下许多购买订单）来满足短缺的条目的要求。换句话说，该销售订单是“延期交付”的，由一个购买订单条目来处理。•一个购买订单中单个条目可被用来满足各销售订单中的多个条目。或者，因为增加的库存可以从许多不同的供应商处订购得到，所以，一个销售订单条目可以通过许多购买订单条目来满足。订单条目关联处理这个多对多关系。订单条目关联•订单条目关联•订单条目（销售订单条目、购买订单条目）•订单（销售订单、购买订单）订单条目关联•销售订单和购买订单相关联的另一种情况是销售订单需要相应的源自购买者的购买订单号，因为卖方想跟踪买方相应的购买订单标识，相应购买订单标识属性出现在销售订单条目实体中。这一属性定义在订单条目级上，而不订单标题上，因为销售订单的每一订单条目可能和不同的购买订单相关。在这种情况下，订单条目关联实体并不是用于把该购买订单和一个销售订单关联起来，因为卖方一般情况下对记录购买订单背后的全部细节不感兴趣—卖方通常只需要购买订单号。•在后一种情况中，一个销售订单条目通常不和多个购买订单关联。如果销售订单中的一个条目是因为两个或多个购买订单条目而下单的，则该销售订单条目可能会被分成几个独立的销售订单条目，以使其能跟踪与每一个购买订单相对应的条目的确切金额。6可选的订单模型•前面关于订购的数据模型和信息对于大多数企业来说都是非常通用的。后面将要阐述的数据模型可能适用或不适用于一些企业，这依赖于每一个具体企业的信息需求。已经给出的数据模型或许为一些企业描述了一个完备的订单数据模型。7需求•订单的产生是因为当事人需要一些东西。一些企业会跟踪这些需求，一些则不会。企业在跟踪自己的需求的同时也会跟踪客户的需求。客户需求的一个例子是捕获客户需求以帮助他们建立一个系统。内部需求的一个例子是购买某些办公用品。•企业可能对跟踪客户需求或内部需求感兴趣，或者对两者都感兴趣，这取决于企业的类型。在一些企业，例如专业服务组织，捕获客户需求是非常重要的。而另一些企业，例如邮购目录企业，不会跟踪客户的需求，而只跟踪它们内部的需求。需求•需求角色•需求角色类型•当事人•订单需求委托•订单条目•需求（客户需求、内部需求；产品需求、工作需求）•需求状态•需求状态类型•期望特征•产品特征•产品•设施需求•需求是组织对任何事物的需要。需求实体描述了一个需要，或是客户需求，或是内部需求。同样，每一需求或者是产品需求，或者是工作需求。产品需求可能和特定的产品和/或一些期望特征有关，因为需求会被表达为对产品的需求或是对具有一定类型特征的物品的需求。•需求可能由其他需求组织，因此形成递归的关系。•许多人员会以需求角色类型中的各种各样的需求角色和需求建立联系，例如“拥有者”、“发起者”、“管理者”、“授权者”或“实施者”。需求随时间的变化会有几个需求状态，例如“活跃的”、“挂起的”或“不活跃的”。每一个需求都需要在一定的设施下应用，例如一个特定的工厂、仓库、办公室或一座建筑物的房间。需求•通过关联实体订单需求委托，需求可以和一个或多个订单条目关联起来。订单需求委托实体维护哪一个销售订单条目满足了哪一个来自客户需求的需求条目的信息。它也维护哪一个购买订单条目被来自内部需求的需求条目满足的信息。•需求有一个描述属性，它宣言了该需求的需要。需求创建日期指写需求每一次建立的日期，在需求实体内的提出日期指定需求条目提出的日期。预计预算属性指明分配多少资金来满足这一需求。描述属性可以保存需求的完整解释和评论。数量属性决定需求中的条目数量，并且允许需求指定需求的几种产品或东西。例如，可能有雇用三个程序员的需求。理由属性解释这个需求存在的理由。7.1需求角色•类似于订单，需求也有许多人员涉及其中。7.2需求状态•需求同样有诸如“活跃的”、“挂起”或“不活跃的”状态。需求状态实体存储了需求的各种状态的历史和各个状态发生的日期。需求状态类型实体维护可能发生的状态类型。如果需求状态的历史是不重要的，企业只对当前状态感受兴趣，那么可以用一个可选的