SLIDE Técnico openERP - Desarrollo de ciclos de negocio - Ting!

33
TING! CICLOS DE NEGOCIO FORMACIÓN TÉCNICA MADRID 19-23 JULIO 2010 JULIO 2010 V2.0 © ting! Tecnologías Inteligentes de Software S.L.

Transcript of SLIDE Técnico openERP - Desarrollo de ciclos de negocio - Ting!

TING! – CICLOS DE NEGOCIOFORMACIÓN TÉCNICA MADRID 19-23 JULIO 2010

JULIO 2010V2.0

© ting! – Tecnologías Inteligentes de Software S.L.

I. HERENCIA

I. DEPENDENCIA ENTRE MÓDULOS

II. HERENCIA DE LOS MODELOS

III. HERENCIA DE LAS VISTAS

IV. MODIFICACIÓN DEL MÓDULO BASE: CAMBIOS EN EL FORMULARIO DE EMPRESA Y CONTACTO

II. ESTADOS Y FLUJOS DE TRABAJO (WORKFLOW)

III. CONTROLADOR (LÓGICA) Y ASISTENTES

I. LÓGICA DE LA APLICACIÓN: MÉTODOS PREDEFINIDOS: SEARCH, READ, BROWSE, CREATE, WRITE, UNLINK, ...

II. HERENCIA DE MÉTODOS: SUPER()

III. PROGRAMACIÓN DE ASISTENTES: ESTADOS, TIPOS DE ESTADOS, FORMULARIOS, TRANSICIONES

IV. ACCIONES DE SERVIDOR

V. TABLEROS

I. POR DEFECTO OPENERP.

II. CREACIÓN DE UNO A MEDIDA.

VI. EJERCICIO PRÁCTICO

índice

I. FLUJOS DE TRABAJO (WORKFLOW)

II. WIZARDS

III. ACCIONES DE SERVIDOR

IV. TABLEROS

índice

I. FLUJOS DE TRABAJO (WORKFLOW)

Workflows

• Gráficos de la lógica de negocio :

Lógica de los Workflows

• Nodos

– Acción

– Sub-Workflows

• Transiciones

– Condiciones

• Rol

• Python

• Pulsación de botón

– Join & split

• AND,

• OR,

• XOR

Lógica de los Workflows

Lógica de los Workflows

Ejemplo de Workflow

• Seguir uno existente

– mrp_repairs

Definiciones de la WfMC (Workflow Management Coalition)

• Workflow: el grafo

• Actividad: un nodo del grafo

• Transición: una arista entre dos nodos del grafo

• Instancia: una instancia de un workflow para un documento

particular

• Workitem: un nodo en ejecución, puede haber varios por

instancia

Workflows: terminología

• Definir el workflow

– name: nombre del workflow

– osv: nombre del objeto

– on_create: si debe instanciarse un workflow con la

creación del objeto

• Definir (un listado de) nodos

• Definir (un listado de) transiciones

Definiendo un workflow

Campos de nodos/actividades

– wkf_id

– flow_start

– flow_stop

– kind• dummy (no hace nada)

• function (llama a un método de un objeto)

• subflow (llama a un subworkflow)

• Stopall (en cuanto llega a este nodo el workflow finaliza)

– action (= nombre del método)• si kind es del tipo “function” o “subflow”

– subflow_id• si kind = “subflow”

• <field name="subflow_id"

search="[('name','=','account.invoice.basic')]"/>

– split mode (ver siguiente diapositiva)

– join mode

Actividades (1)

Actividades (2)

• Join Mode– XOR

• Si el join mode está definido como xor este nodo del workflow se activará en la primera

transición que llegue a él.

– AND• En cambio si está definido como and el nodo solamente se activará cuando se completen

todas las transiciones que llegan hasta ese nodo

• Split Mode– XOR

• Si el split mode está definido como XOR se enviaría el flujo solamente a la siguiente transición

válida a la que apunte

– OR• Envía el flujo a todas las transiciones válidas (0 o varias) de manera secuencial.

– AND• Envía el flujo a todas las transiciones válidas a la vez.

Actividades (3)

Transiciones

Campos:

•act_from: id de la actividad de origen

•act_to: id de la actividad destino

•condition: expresión en python

•signal: nombre de un botón

•role_id: rol necesario para ejecutar la transición

Expresiones:

•sintáxis en python, se pueden usar los campos del

objeto

•Ejemplo:

•zip == 1400

•phone == mobile

WIZARDS

II. WIZARDS

Entorno de desarrollo

Principios

Definicion

•Clase

•Campos

•Formularios

•Metodos

Registrando wizards

• Un wizard es una succesión de pasos. Un paso está

compuesto por varias acciones:

1. Enviar un formulario al cliente con algunos

botones

2. Recibir el formulario con los datos y los botones

pulsados por el cliente

3. Ejecutar alguna acción

4. Enviar una nueva acción al cliente (formulario,

imprimir, ...)

Wizard : Principio

o

Ejemplo de wizard

Definición : class

class

wizard_class(wizard.interface):

states = {

'init': {

'actions': [],

'result': ...

'state_name': {

'actions':

[_method_name],

'result': ...

}

}

wizard_class('wizard.name')

Definición : class

class part_sms(wizard.interface):

states = {

'init': {

'actions': [_get_value],'result': {'type': 'form',

'arch':sms_send_form, 'fields':

sms_send_fields,

'state':[('send','Send SMS'),

('end','Cancel')]},

'send': {

'actions': [_sms_send],

'result': {'type': 'state',

'state':'end'}}

}

part_sms('res.partner.sms_send')

Class

ActionsAcciones que se pueden ejecutar en los distintos pasos

Result: tipos posiblesform -> arch, fields, state

Ejemple:

'result': {

'type': 'form','arch': sms_send_form,

'fields': sms_send_fields,

'state': [('send','Send SMS'), ('end','Cancel')]

},state -> state

print -> report, state

Definición : campos

Campos

sms_send_fields = {

'app_id': {'string':'API ID', 'type':'char', 'required':True},

'user': {'string':'Login', 'type':'char', 'required':True},

'password': {'string':'Password', 'type':'char', 'required':True},'text': {'string':'SMS Message', 'type':'text', 'required':True}

}

Definición : Formularios

Formularios

sms_send_form = '''<?xml version="1.0"?>

<form string="SMS">

<separator string="Bulk SMS send" colspan="4"/>

<field name="app_id"/>

<newline/><field name="user"/>

<field name="password"/>

<newline/>

<field name="text" colspan="3"/></form>'''

Definición : Metodos de acción

Metodos de acción

Signatura :

def _nombre_método(self, uid, data):

Uid

Data = diccionario

- data['ids']- data['form']

Retorno :return {'field_name': value, ...}

Definición : Añadir Botón de ejecución

Debemos crear también un archivo xml para indicar a openERP

desde donde queremos acceder a ese wizard

<wizard id="res_partner_send_sms_wizard" model="res.partner" name="res.partner.sms_send" string="Send SMS"/>

• Las acciones del servidor son una funcionalidad bastante potente de

OpenERP. Permiten, llegado un momento desencadenar un

determinado tipo de evento programado de antemano.

• Es muy útil, dado que permite automatizar acciones del flujo de trabajo

propio del cliente donde se ha implementado.

• Ejemplos:

– el envío automático de emails cuando ocurre algo como la confirmación de una venta o

una factura

– la impresión de un determinado documento cuando llega a cierto estado el registro del

objeto al que pertenece (confirmar factura imprime en papel la factura)

– Ejecutar un determinado wizard, por ejemplo, el de JIT en fabricación cada vez que se

confirma una orden.

Acciones de servidor

• Las acciones del servidor son una funcionalidad bastante potente de

OpenERP. Permiten, llegado un momento desencadenar un

determinado tipo de evento programado de antemano.

• Es muy útil, dado que permite automatizar acciones del flujo de trabajo

propio del cliente donde se ha implementado.

• Ejemplos:

– el envío automático de emails cuando ocurre algo como la confirmación de una venta o

una factura

– la impresión de un determinado documento cuando llega a cierto estado el registro del

objeto al que pertenece (confirmar factura imprime en papel la factura)

– Ejecutar un determinado wizard, por ejemplo, el de JIT en fabricación cada vez que se

confirma una orden.

– Registro en el historial de los registros de un objeto, por ejemplo, todas las acciones que

afectan a un cliente, se pueden registrar en su pestaña historial.

Acciones de servidor

• Las acciones del servidor son una funcionalidad bastante potente de

OpenERP. Permiten, llegado un momento desencadenar un

determinado tipo de evento programado de antemano.

• Es muy útil, dado que permite automatizar acciones del flujo de trabajo

propio del cliente donde se ha implementado.

• Ejemplos:

– el envío automático de emails cuando ocurre algo como la confirmación de una venta o

una factura

– la impresión de un determinado documento cuando llega a cierto estado el registro del

objeto al que pertenece (confirmar factura imprime en papel la factura)

– Ejecutar un determinado wizard, por ejemplo, el de JIT en fabricación cada vez que se

confirma una orden.

– Registro en el historial de los registros de un objeto, por ejemplo, todas las acciones que

afectan a un cliente, se pueden registrar en su pestaña historial.

• Para definirlas (y ver las que están definidas)

– Administración -> Personalización -> Acciones -> Acciones servidor

Acciones de servidor

• Las acciones del servidor son una funcionalidad bastante potente de

OpenERP. Permiten, llegado un momento desencadenar un

determinado tipo de evento programado de antemano.

• Es muy útil, dado que permite automatizar acciones del flujo de trabajo

propio del cliente donde se ha implementado.

• Ejemplos:

– el envío automático de emails cuando ocurre algo como la confirmación de una venta o

una factura

– la impresión de un determinado documento cuando llega a cierto estado el registro del

objeto al que pertenece (confirmar factura imprime en papel la factura)

– Ejecutar un determinado wizard, por ejemplo, el de JIT en fabricación cada vez que se

confirma una orden.

– Registro en el historial de los registros de un objeto, por ejemplo, todas las acciones que

afectan a un cliente, se pueden registrar en su pestaña historial.

• Para definirlas (y ver las que están definidas)

– Administración -> Personalización -> Acciones -> Acciones servidor

Acciones de servidor

• Allí nos encontramos con la siguiente información:

– Nombre de acción: Nombre descriptivo de la acción.

– Objeto: El objeto/modelo sobre el que disparar la acción de servidor. Ejemplo: Pedido de

Venta.

– Tipo de acción: en la siguiente diapositiva se listarán todas las acciones posibles dentro de

OpenERP. La instalación de ciertos módulos puede agregar acciones posibles a realizar.

– Secuencia: Si tipo de acción es de tipo “Multi Acciones”, se ejecutan varias acciones a las

cuales se les indica, mediante este campo, el orden para hacerlo.

– Condición: Por defecto viene inicializado a true (entonces no tiene en cuenta la

condición), pero permite introducir una única línea de código python que actua como

condición que se debe validar antes de ejecutar la acción.

– Configuración según el tipo de acción: cada tipo de acción seleccionado despliega su

propia configuración en función de sus características. Es aquí donde se define

específicamente la acción en sí.

Acciones de servidor

• Allí nos encontramos con la siguiente información:

– Nombre de acción: Nombre descriptivo de la acción.

– Objeto: El objeto/modelo sobre el que disparar la acción de servidor. Ejemplo: Pedido de

Venta.

– Tipo de acción: en la siguiente diapositiva se listarán todas las acciones posibles dentro de

OpenERP. La instalación de ciertos módulos puede agregar acciones posibles a realizar.

– Secuencia: Si tipo de acción es de tipo “Multi Acciones”, se ejecutan varias acciones a las

cuales se les indica, mediante este campo, el orden para hacerlo.

– Condición: Por defecto viene inicializado a true (entonces no tiene en cuenta la

condición), pero permite introducir una única línea de código python que actua como

condición que se debe validar antes de ejecutar la acción.

– Configuración según el tipo de acción: cada tipo de acción seleccionado despliega su

propia configuración en función de sus características. Es aquí donde se define

específicamente la acción en sí.

Acciones de servidor

• El primer paso es definir el tipo de acción, dentro de los siguientes tipos:

– Acción cliente: se ejecuta del lado del cliente, y permite lanzar un wizard o un informe

– Iteración: Basada en una expresión bucle de python, permite repetir acciones de servidor.

Se suelen usar en objetos con campos one2many en los que se quiere llevar a cabo una

acción de servidor sobre los objetos referenciados en el one2many (pedidos de venta y

lineas de venta

– Código Python: Para ejecutar código python de varias líneas. El valor devuelto es el valor

de la variable action = {}. Esto tiene sentido sólo si se desea que una específica ventana

(formulario) emerja en un contexto específico. En la mayoría de las ocasiones no es

necesario un valor de retorno. Nota: El código es ejecutado utilizando la función exec de

python, el cual se ejecuta en el espacio de nombres del diccionario con variables:

object,time,cr,uid,ids

– Trigger: Cualquier transición del flujo de trabajo puede ser desencadenado con éste tipo

de acción. Permite:

• Flujo sobre: El objeto OpenERP sobre el que se desea disparar el flujo de trabajo. Flujo para ser ejecutado en este modelo.

• Disparar sobre: Seleccionar el objeto/ID del modelo sobre el cual se ejecutará el flujo. Por ejemplo seleccionar el ID de

factura si se desea disparar un cambio en la factura.

Acciones de servidor

• El primer paso es definir el tipo de acción, dentro de los siguientes tipos:

– Acción de email: Configurar una dirección de correo electrónico, asunto y mensaje.

Requiere configurar el servidor SMTP integrado en Open ERP. Opcionalmente se puede

hacer uso de Power email, una arquitectura de email genérica para Open ERP que ofrece

mayor funcionalidad y automatización de correos (no requiere acciones de servidor).

– Crear objeto: Se utiliza para crear un nuevo registro en cualquier modelo cuando se

desencadena una acción de servidor. Permite hacer uso de la función “historial”

mencionada anteriormente. Con “Mapeo de Campos” se da valor a los campos del

registro. A continuación se muestran capturas de pantallas con un ejemplo de creación

de eventos para un pedido de venta:

– Escribir objeto: Similar a Crear objeto a excepción de que es utilizado para modificar un

registro existente identificado por write_id. Si se actualiza un registro previamente creado

con Crear Objeto, el mismo campo para create id puede utilizarse para write id.

– Multi acción: Para crear múltiples acciones de servidor y ejecutarlas de una en una

siguiendo un orden de secuencia. Es una de las opciones más interesantes, aunque son

acciones de tipo servidor, sólo una de tipo cliente puede ejecutarse.

Acciones de servidor