Odoo序列和工作流.docx

Odoo 序列和工作流 一序列 序号名称 序号的显示名称序号类型 序号的类型编 辑 序 列 前缀 生成序号的前缀，可以用一些系统变量后缀 生成序号的后缀，可以用一些系统变量数字位数 生成序号的数字位数（不含前缀和后缀），不足位时会在前面补 0 增量 每次序号增加的数字下一编号 系统将生成的下一个序号 二、工作流 一、工作流定义： ?xml version=1.0? terpdata record model=workflowid=workflow_id field name=nameworkflow.name/field field name=osvresource.model/field field name=on_createTrue|False/field /record /data/terp model：固定取值workflow id：任意值，唯一标识本工作流name:工作流的名称，任意定义 osv：本工作流关联的对象类型，是 OpenERP 模块中定义的某对象名，如采购单对象（purchase.order）。是本工作流处理的数据对象。 on_create：每当系统新产生一个 osv 中定义的对象的实例时候，是否对应的产生一个和该对象实例关联的工作流实例。默认是 True. 工作流和工作流实例：工作流定义了对某一类型的对象，如采购订单（PO）的处理流程。例如，PO 单的一般处理流程也许是：1）新建 PO，State=draft；2）审批 PO，审批的同时，a)系统自动产生收货单， 工仓库收货；b)系统自动产生凭据（Invoice），供财务确认付款；c)系统自动产生 PDF 的采购订单，并自动 EMail 给该 PO 单对应的供应商。但对于特定的某个 PO 对象，需要一个工作流实例，以记录本 PO 对象处在流程的哪个阶段，如 PO1 尚在 draft 状态，PO2 已经审批通过。 PO 单的审批，以及对应的 a)、b)、c)的动作，都可以在 OE 的工作流中定义解决，而不需要全编码在 PO 对象上。即工作流实现了流程处理相关的代码和被处理对象的代码相分离，降低了不同处理代码的耦合性， 增加了系统功能的柔软性。 二、活动（Activity）定义 record model=workflow.activityid=activity_id field name=wkf_idref=workflow_id/ field name=nameactivity.name/field field name=kinddummy|function|subflow|stopall/field field name=subflow_idsubflow_id/field field name=action(...)/field field name=action_id(...)/field field name=split_modeXOR|OR|AND/field field name=join_modeXOR|AND/field field name=signal_send(...)/field field name=flow_startTrue|False/field field name=flow_stopTrue|False/field /record model：固定取值 workflow.activity wkf_id：本 Activity 所属的工作流 id name:本 Activity 名称，任意值 kind：本Activity 类型，有Dummy,Function,Subflow,Stop All 四种。kind 说明，如果流程到达本节点， 系统应执行的动作类别。 Dummy 表示不执行任何动作，即 action 中定义的代码不会被执行。 Function 表示执行 action 中定义的 python 代码，且，执行 action_id 中定义的 server action。常见情况是，action 中定义一个 write 方法，修改流程关联的对象的状态。对于 Function 类型的节点，action 中定义的代码或者返回 False，或者返回一个客户端动作 id（A client action should be returned）。Subflow 类型表示触发“subflow_id”中指定的工作流。仔细的读者或许要问，工作流的执行总是和某个被处理的对象关联，是的，如果定义了 action，subflow 关联的对象 id 由 action 中定义的代码返回。如果没有定义 action，系统默认 subflow 关联的对象和本节点所属的工作流处理的对象 id 一致。stopall 类型表示，流程到此节点则结束，但结束前，系