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

OFBiz业务培训系列订单管理,hongs,1,PPT学习交流,目录,订单和订单条目、订单条目关联订单当事人和联系机制订单调整订单状态和订单条款需求请求报价协议、协议项目、协议条款、协议定价。协议到订单的关系,2,PPT学习交流,1标准订单模型,大多数组织机构的订购活动是使用标准数据模型来建模的,这种模型在许多关于数据模型的教材中都有介绍。下图给出了这个标准数据模型的图示。,3,PPT学习交流,标准订单模型,销售订单行项销售订单客户产品购买订单行项购买订单供应商,4,PPT学习交流,2订单和订单条目,订单实体分为销售订单和购买订单，涵盖了销售和购买订单。订单由订单条目组成，指明了订购的产品，从而说明了和产品的关系。在订单中名为订购日期的属性指明企业接收或是发出订单的日期。进入日期属性是订单进入企业系统的日期。订单实体为了容纳与销售订单或购买订单有关的特定属性或关系，分为销售订单实体和购买订单实体。订单条目描述了对特定产品或服务的订购。因此，每个订单条目用一个且只有一个产品来定义。订单条目有数量属性。对于货物，它描述了订购的货物数量。对于服务，它描述了应该付款的小时数、天数或其他度量数。对数量的度量单位由和产品关联的试题单位来决定。单价属性存储了条目的收费或服务的费用。预计交付日期是货特预计被装运到客户的日期或是服务预计履行的日期。装运说明属性存储了运送产品到目的地的说明，例如，“禁止外放”、“易碎小心轻放”或“交付时需要客户签名”。备注属性用于对订单条目的附加解释。条目描述属性提供了一种机制用于存储条目描述，这些条目是非标准的，不会在产品或产品特征实体中被维护。条目描述属性也能说明非产品特定的订单，诸如完成工作计划或是预定专业服务的时间的订单条目。订单条目也能和一个或多个工作计划有关。,5,PPT学习交流,订单和订单条目,订单条目（购买订单条目、销售订单条目）产品产品特征（产品质量、颜色、维、尺寸、品牌、软件特征、硬件特征、付款特征、其他特征）订单（购买订单、销售订单）,6,PPT学习交流,3订单当事人和联系机制,在订单中包括的主要当事人如下：下订单的当事人；接收订单的当事人；接收订单交付的当事人；为订单付款的当事人；安装和/或装配产品的当事人；在订单中涉及到的各种各样角色的人，诸如：录入订单的人、确保质量的人、管理订单的人等等。,7,PPT学习交流,销售订单当事人和联系机制,联系机制订单条目订单订单角色当事人角色当事人,8,PPT学习交流,3.1销售订单当事人和联系机制,每一销售订单和销售订单条目有许多当事人角色子类和与当事人角色有关的联系机制.一个销售订单可能由下单客户下单,被内部组织联络员接收,产生一个需求账单给付款客户.1、下单当事人和相关的联系机制：订单可能由个人或是组织下发,这取决于需要搭建系统的组织机构的业务需要.在邮购目录行业中,订单通常由个人下发。当事人关系实体可以识别出某些类型的当事人是否被允许为该企业下单，例如检查是否存在一种有效的经纪人关系。2、接收订单当事人和相关的联系机制：订单总是由当事人人来接收。3、装运目标当事人和联系机制：在一些情况下，订单由一个当事人下发，发送给另一当事人。4、付款当事例和联系机制：订单需要指明负责为订单付款的当事人和联系机制，联系机制人微言轻订单的账单运达场所（通常是发票送往哪里）。具有需求账单的销售订单到一个付款客户间的关系指明了负责为发票付款的当事人。从具有需求账单的销售订单到联系机制间的关系指明账单送往哪里和接下来在哪里支付。5、订单的人员角色：除了前面提到的主要订单关系之外，许多其他的当事人也涉及到订单处理中，例如交付订单的人员、处理订单的人员、批准订单的人员、协调安装的当事人和负责履行订单的当事人。,9,PPT学习交流,购买订单当事人和联系机制,联系机制订单条目订单订单角色当事人角色当事人,10,PPT学习交流,购买订单当事人和联系机制,这个数据模型和前面的模型非常类似。因为销售订单和购买订单描述了当事人间的约定，不管是在购买方还是销售方，每个当事人都需要跟踪订单的细节。唯一的区别是涉及到的角色名称不同。,11,PPT学习交流,通用订单角色和联系机制,订单条目角色订单条目角色类型当事人订单角色订单角色类型订单条目订单条目联系机制联系机制联系机制目标类型订单订单联系机制,12,PPT学习交流,通用订单角色和联系机制,每个订单可能涉及到一个或多个订单角色，每个角色被指定给一个当事人，并由一个订单角色类型描述。通过在订单角色类型中存储这些可能的角色然后将它们关联到订单角色的方法，这个结构能处理任何数量的用于销售订单或购买订单的角色。可能的订单角色类型包括“下单当事人”、“付款客户”、“内部接收订单组织”、“下单客户”、“下单购买方”、“供应商”、“付款购买方”、“订单录入人员”、“订单销售人员”和“订单授权人员”。每个订单条目也可能有订单条目角色类型中的订单条目角色，这些类型包括“装运目标购买方”、“装运目标客户”、“安装客户联系员”和“安装员”。每个订单有一个或多个订单联系机制，每个订单条目有一个或多个订单条目联系机制用于记录地址、电话、传真、电子邮件或者其他联系机制，用来确认、装运、付款、接收或安装这个订单。联系机制目的类型维护诸如“装运目标”、“付款”、“确认”、“下单”或“通过接收”的值来描述联系机制中的角色。联系机制实体存储了与订单关联使用的实际地址、电话号码、传真号码、电子邮件地址或其他联系机制。,13,PPT学习交流,4订单调整,订单的有些部分不反映特定产品或特征的订购。例如折扣、额外费、加工费、装运和处理费。如果这些调整流器被视作订单条目的子类，那么在订单条目之间需要存在一个递归的关系，用于把这些调整流器与合适的其他订单条目关联起来。这种数据类型有些复杂，因为许多这样的调整可能会影响到订单和订单条目中的一个或同时影响两者。出于这些原因，订单调整被作为独立的实体表示出来。子类是折扣调整、额外费调整、销售税、装运和处理费、手续费和杂项收费。折扣调整和额外费调整是存储对整个订单或每个订单条目的价格调整的子类。这些价格调整可以是金额或是百分比。,14,PPT学习交流,订单调整,销售税查找地理范围产品类别订单调整（杂项收费、折扣调整、额外费调整、销售税、装运和处理费、手续费）订单调整类型订单条目订单,15,PPT学习交流,订单调整,销售税提供了对整个订单或一个特殊的订单条目征收销售税的信息。装运和处理费会给订单或订单条目增加一个订单调整。手续存储诸如“订单处理费”涵盖安排订单的装运所需费用的“处理费”以及“管理费”。杂项收费子类提供了一个机制，用于存储有关可能在订单中产生的任何其他收费的信息。一个例子是用“错误调整”来纠正先前的订单。订单调整类型实体实现这个的一个功能，可以把各种类型的调整分类到细目录。描述属性定义了与调整有关的可能值。销售税查找表实体存储了销售税百分比，这个百分会随地理范围，诸如县、市或州变化，也可能随产品类别变化。例如，仪器与非腐烂的产品相比，有不同的税收内容。一些类型的产品是免税的，可通过把它们和“免税”产品类别关联来分类。,16,PPT学习交流,4.1订单状态和订单条款,订单状态实体来了解订单和订单条目的当前状态，同时跟踪进度情况。订单状态类型维护可能的订单状态。订单条款实体跟踪与订单和订单条目相关的业务条件。条款类型实体维护可以使用的条款。,17,PPT学习交流,订单状态和条款,订单条款条款类型订单条目订单状态订单状态类型订单,18,PPT学习交流,4.2订单状态,由于订单在不同的时间点可能处于不同的状态。订单状态的状态日期属性提供了对每一个订单状态的发生时间进行踊跃的手段。,19,PPT学习交流,4.3订单条款,涉及到的当事人可能会对许多协定和条款达成一致。交付条款、退换或退款政策和未履行的惩罚都是一些例子。每一订单或订单条目会有一个或多个订单条款，每一条款由条款类型来分类。条款值属性只应用于订单条款的一部分，它的意义取决于条款的类型。,20,PPT学习交流,5订单条目关联,有时，存在从一个订单条目到另一个订单条目的关系。图4-8中订单条目关联实体把销售订单条目和购买订单条目联系起来。这种关联的一个例子发生在当销售订单条目依赖于购买订单条目的时候。例如，批发商可能会收到一个销售订单，但可能没有足够的库存来满足该订单上某个条目的要求。反过来，批发商会向他的一个供应商下一个购买订单（或向许多供应商下许多购买订单）来满足短缺的条目的要求。换句话说，该销售订单是“延期交付”的，由一个购买订单条目来处理。一个购买订单中单个条目可被用来满足各销售订单中的多个条目。或者，因为增加的库存可以从许多不同的供应商处订购得到，所以，一个销售订单条目可以通过许多购买订单条目来满足。订单条目关联处理这个多对多关系。,21,PPT学习交流,订单条目关联,订单条目关联订单条目（销售订单条目、购买订单条目）订单（销售订单、购买订单）,22,PPT学习交流,订单条目关联,销售订单和购买订单相关联的另一种情况是销售订单需要相应的源自购买者的购买订单号，因为卖方想跟踪买方相应的购买订单标识，相应购买订单标识属性出现在销售订单条目实体中。这一属性定义在订单条目级上，而不订单标题上，因为销售订单的每一订单条目可能和不同的购买订单相关。在这种情况下，订单条目关联实体并不是用于把该购买订单和一个销售订单关联起来，因为卖方一般情况下对记录购买订单背后的全部细节不感兴趣卖方通常只需要购买订单号。在后一种情况中，一个销售订单条目通常不和多个购买订单关联。如果销售订单中的一个条目是因为两个或多个购买订单条目而下单的，则该销售订单条目可能会被分成几个独立的销售订单条目，以使其能跟踪与每一个购买订单相对应的条目的确切金额。,23,PPT学习交流,6可选的订单模型,前面关于订购的数据模型和信息对于大多数企业来说都是非常通用的。后面将要阐述的数据模型可能适用或不适用于一些企业，这依赖于每一个具体企业的信息需求。已经给出的数据模型或许为一些企业描述了一个完备的订单数据模型。,24,PPT学习交流,7需求,订单的产生是因为当事人需要一些东西。一些企业会跟踪这些需求，一些则不会。企业在跟踪自己的需求的同时也会跟踪客户的需求。客户需求的一个例子是捕获客户需求以帮助他们建立一个系统。内部需求的一个例子是购买某些办公用品。企业可能对跟踪客户需求或内部需求感兴趣，或者对两者都感兴趣，这取决于企业的类型。在一些企业，例如专业服务组织，捕获客户需求是非常重要的。而另一些企业，例如邮购目录企业，不会跟踪客户的需求，而只跟踪它们内部的需求。,25,PPT学习交流,需求,需求角色需求角色类型当事人订单需求委托订单条目需求（客户需求、内部需求；产品需求、工作需求）需求状态需求状态类型期望特征产品特征产品设施,26,PPT学习交流,需求,需求是组织对任何事物的需要。需求实体描述了一个需要，或是客户需求，或是内部需求。同样，每一需求或者是产品需求，或者是工作需求。产品需求可能和特定的产品和/或一些期望特征有关，因为需求会被表达为对产品的需求或是对具有一定类型特征的物品的需求。需求可能由其他需求组织，因此形成递归的关系。许多人员会以需求角色类型中的各种各样的需求角色和需求建立联系，例如“拥有者”、“发起者”、“管理者”、“授权者”或“实施者”。需求随时间的变化会有几个需求状态，例如“活跃的”、“挂起的”或“不活跃的”。每一个需求都需要在一定的设施下应用，例如一个特定的工厂、仓库、办公室或一座建筑物的房间。,27,PPT学习交流,需求,通过关联实体订单需求委托，需求可以和一个或多个订单条目关联起来。订单需求委托实体维护哪一个销售订单条目满足了哪一个来自客户需求的需求条目的信息。它也维护哪一个购买订单条目被来自内部需求的需求条目满足的信息。需求有一个描述属性，它宣言了该需求的需要。需求创建日期指写需求每一次建立的日期，在需求实体内的提出日期指定需求条目提出的日期。预计预算属性指明分配多少资金来满足这一需求。描述属性可以保存需求的完整解释和评论。数量属性决定需求中的条目数量，并且允许需求指定需求的几种产品或东西。例如，可能有雇用三个程序员的需求。理由属性解释这个需求存在的理由。,28,PPT学习交流,7.1需求角色,类似于订单，需求也有许多人员涉及其中。,29,PPT学习交流,7.2需求状态,需求同样有诸如“活跃的”、“挂起”或“不活跃的”状态。需求状态实体存储了需求的各种状态的历史和各个状态发生的日期。需求状态类型实体维护可能发生的状态类型。如果需求状态的历史是不重要的，企业只对当前状态感受兴趣，那么可以用一个可选的数据模型反映一个从需求到需求状态类型的多对一关系。,30,PPT学习交流,7.3产品需求,和产品的关系是任选的，而且只运用于产品需求。如到期望特征的关系所示，产品需求会为某些特征指明需求。期望特征中的任选标志属性表明，如果值是“是”，那么特征是期望的，而不是必备的。,31,PPT学习交流,7.4订单需求委托,获得产品的一个需求或要求自然会导致订单的出现。一个需求会引出许多订单条目。订单需求委托决定了从订单条目到需求分配多少条目。例如，假如有两个需求，每个都有需求1500支#2铅笔（总共需要3000支）的条目，那么一个2000支的订单条目可以部分满足这个需求。这样就有必要指明使用了多少订单条目来满足每个需求，订单需求委托中的数量属性用于这个目的。,32,PPT学习交流,8订购请求,有时，并不是根据需求立刻订购产品，而是还需要采用一个请求和接收报价的过程。请求是一种要求卖方投标、报价或响应需求的方法。请求可能被送到企业，或者从企业送出，征示供应商的响应。,33,PPT学习交流,请求,需求请求需求（客户需求、内部需求；产品需求、工作需求）请求条目请求请求角色响应当事人当事人联系机制,34,PPT学习交流,请求,图4-10展示了和请求相关的主要实体。请求有许多请求角色，其中的每个都属于一种请求角色类型，并且和当事人相关联。角色的例子包括“发起者”（发出请求的当事人）、“准备者”、“管理者”和“质保人”。响应当事人实体维护可能响应的当事人的信息。联系机制记录将会用于或者曾经用于发送请求给响应当事人的联系机制。每个请求可以由一个或多个请求条目组成。每个请求条目代表了可以结合到请求中的一个或多个需求条目。因为需求可能和多个请求条目有关，所以关联实体需求请求实现了这个多对多的关系。,35,PPT学习交流,8.1请求,存在几种类型的请求。请求实体具有一种子类型，它们都是各种请求中最普遍的形式。子类RFP表示“提案请求”，要求卖主对请求详情中指定的需要提出一个解决方案。子类RFQ表示“报价请求”，要求卖主对指定的产品投标。子类RFI表示“信息请求”，通常在RFP或RFQ前送出，以确定有关卖主的资格初步信息。常可以将这个作为一种机制，来筛选允许响应RFP或RFQ的卖主。请求实体维护着描述请求创建日期属性、描述买主响应请求的最后期限的要求请求日期属性和详述请示本质的描述属性。,36,PPT学习交流,8.2请求条目,请求具有一些条目用来描述请求中所需要的各种各样的东西。请求条目具有数量属性，这明这些条目需要多少数量。请求提出日期指明需要将条目送到请求组织的时间。最大金额属性描述了条目的价格上限，超过这个价格的话，企业甚至不会去考虑它。请求可能是为一个具体的产品，就如在一个RFQ中，或者可能是要求卖主为具体的问题提供解决方案。如果请求是为了产品，那么和产品的关系就容纳了这些类型的请求条目。如果请求是为了具体问题的提案，就如在一个RFP中那样，那么描述属性维护了对该问题的描述。,37,PPT学习交流,9报价定义,报价是针对一个请求的响应，它是竞标或提案的同义词。报价提供了和产品相关的价格和条款，用于满足请求的需求。,38,PPT学习交流,报价,订单条目报价条目报价条款条款类型报价报价角色报价角色类型当事人产品工作计划,39,PPT学习交流,报价,图4-11展示了和报价相关的数据模型。报价由一个当事人提出，交给另一个当事人。企业或者企业的一部分，可能是报价的接收方或发送方。其他和报价相关的角色存储在报价角色实体中，可允许的角色值维护在报价角色类型实体中。报价实体存储和报价有关的基本信息，由描述被报价的具体产品或工作计划的报价条目组成。各报价条目必须和请求条目相关联，因为报价条目被定义为是对请求条目的响应。此外，每个报价条目可以导出一个或多个订单条目，因为报价条目可能会被要求多次。同订单一样，每个报价或报价条目有相关联的条款，这样，就使得我们有必要建立两者分别到报价条款和条款类型的两个关系。,40,PPT学习交流,9.1报价角色,与请求一样，在报价中也明确地给出了两个非常重要的关系，即什么当事人提出报价和报价给什么当事人。如同订单、需求和请求具有其他各种角色一样，报价也有人员扮演不同的角色。报价角色的例子可以是“报价人”、“审查人”和“批准人”。,41,PPT学习交流,9.2报价,报价实体存储关于报价的标题信息。例如，提出日期维护着报价何时传达给有意的当事人。有效起始日期和有效终止日期维护着报价开始执行和报价到期的时间。描述属性描述了报价的性质。报价有一个提案的子类型，它通常更详实，包括了许多部分，例如要求陈述、提案描述、利润、成本说明、所需资源等等。另一个子类型是产品报价，它较为简单，只跟踪被报价的产品背后的条款和价格。可能还有其他的报价类型，例如竞标或申请，这取决于企业和它的术语。,42,PPT学习交流,9.3报价条目,报价条目实体包括了关系到具体产品的信息，因此和产品有关联。报价条目也和请求条目有关联。从这个模型中，可以得出结论：到产品的关系不是必要的，因为产品可以从一个报价条目涉及的产品导出。这可以通过在模型中从报价条目到请求条目再到产品进行遍历得到。然而，来自报价的产品可能和请求的产品不一样。报价条目和请求条目有多对一的关系。当一个请求发出扣，报价、竞标或提案应当只和来自一个组织的一个具体请求相对应，而不管它是口头的还是书面的。虽然这样，一个请求，例如一个RFP，会有多个报价和它有关，因为有许多供应商会响应。如果报价被接受，报价条目也可能和订单相关联。一个订单条目通常不会有多于一个的报价条目和它关联。报价条目可能是对一些订单进行定价的基础；因此，几个订单条目可能会与一个报价条目相关联。,43,PPT学习交流,9.4报价条款,同订单相似，报价和报价条目都可能具有与它们相关联的条款。从报价到报价条款的关系允许许多条款和报价相关联。通过和报价条款的关系，也有许多条款可以和报价条目相关联。条款类型指明了可以适用的可能条款。这个实体也可用于其他类型的事务，如订单。,44,PPT学习交流,10协议定义,协议是条款和条件的集合，管理着两个当事人（例如，一个客户和一个供应商）之间的关系。订单和协议之间的关键区别是订单是购买产品的一次性委托，而协议指明两个当事人怎样在以后从事商务行为。,45,PPT学习交流,定义,一个协议是记录商务活动或你和其它公司或个人签订的合同。通常例子包括付款条款(你允许客户30天付给你)或即时的付款折扣(如果你客户在某天前付款则提供在所在金融上减少).,46,PPT学习交流,用在哪方面,能用在下列方面：定义客户或供应商的支付条款定义销售佣金设置立刻支付折扣设置价格列表(待定：需要调查这个逻辑与产品管理中的价格规则如何重叠)定义滞纳金处罚定义优先货运承运人或将使用的代码,47,PPT学习交流,协议定义,协议协议类型协议角色当事人关系当事人角色当事人,48,PPT学习交流,协议定义,图4-12展示了和协议相联系的数据模型。协议分类成协议类型例如，产品协议、雇用协议或其他协议，这取决于企业的需求。协议类型允许对许多更为明确的协议类型进行维护。协议包括许多当事人的协议角色，诸如协议角色类型“卖方”、“买方”、“获许可的人”、“发许可的人”、“合同签约公司”和“雇主”，这些角色将依赖涉及的协议类型。协议和具体的当事人关系有关，例如一个客户关系相关联的销售协议。,49,PPT学习交流,11协议项目,协议定义了两个或多个当事人之间的正式契约，他们都对一定时间段的条款有委托。每个协议会有协议项目，或者是子协议或者是协议的一部分。这些部分可能是特殊的节或子句，允许协议被按节划分或引用。此外，协议可以具有一些部分，适用于一定的地域、一定类型的产品、或在协议中涉及的组织机构的某些特定部分。,50,PPT学习交流,协议项目,协议组织适应性协议产品适应性协议地理适应性产品地理范围附件协议项目（子协议；协议章节、协议定价程序、协议解释）协议（产品协议：销售协议、购买协议；雇用协议；其他协议）,51,PPT学习交流,协议项目,图4-13展示了一个数据模型，这个模型展示了协议项目需要的信息。每个协议项目描述了协议的组成，并有协议文本和可选的协议图像来描述图形组成部分。对于简单的协议，诸如当事人之间的一页协议，不要求存储协议项目，因为协议文本可能存储在协议实体的文本属性里。标准的条款可以附加在下一个图中将显示的协议中，该图中存储了协议的文本和条款。对于更为复杂的协议，会有许多的协议项目来描述协议的部分。协议项目有子类子协议、协议章节、协议定价程序和协议解释。子协议描述了在一个协议里的协议，诸如形成一个全面专业服务协议的一部分保密协议或用于一个组织不同部分的几个子协议。协议章节描述了协议的一部分，分割出来作为一个协议项目，如果需要，可以把它和特定的组织、产品和地域联系起来。协议定价程序描述了关于达成共识的产品价格的信息和基于不同标准的特征。协议解释是协议的一部分，和协议附在一起，通常在协议的始末都会引用。,52,PPT学习交流,协议项目,如同在协议项目的递归关系中展示的那样，每个协议项目会由其他协议项目组成。子协议可分成协议节，协议节可进一步分成协议子句，递归关系允许协议项目在需要的细节级数量上组成。协议或协议项目可收附加来修改，可在附件的附件文本属性中修改协议或协议项目的文本。附件实体维护着何时创建附件的附件创建日期，何时附件生效的附件有效日期。附件文本描述了附件。附件的一个例子是客户-卖主协议中终止日期的延长。在这种情况下，协议实体终止日期会更新，会加上一个附件来显示对可应用的协议项目的更改历史。每个协议会由一个或多个附件来修改。每个协议项目会明确为一定的地域、产品和/或组织。协议地理范围适用性、协议产品适用性和协议组织适用性允许协议项目为一定的地域、产品或组织定制。例如，对于企业内每个不同的分支机构，可能会有适用于它的特定协议部分。这种结构允许适用于每个分支机构的单独小节。同样地，协议的一定小节只能适用于一定的产品或地域。还有其他定义协议项目的因素，例如特定类型产品的适用性，因此可以加入其他的“适用性”实体，例如，在这里可加入协议产品目录适用性。,53,PPT学习交流,12协议条款,协议和协议项目都有条款与之相联。协议条款实体存储协议的有效条款和条款的有效日期。从条款类型实体中可引出不同的条款类型。协议条款实体提供了一种维护不同类型条款的结构，这些条款既可应用于协议（没有条目的较简单协议）又可适用于协议项目。条款和条件可包括法律条款、金融条款、动机、局限条款、更新条款、协议终止、补偿、非竞争和非他关系的条款。,54,PPT学习交流,协议条款,协议条款（法律条款、金融条款、动机、界限条款、其他协议条款）条款类型协议项目协议,55,PPT学习交流,13协议定价,协议项目实体与一个维护当事人之间的议定产品价格的实体相关联。价格会随着时间周期、