SLIDE Técnico openERP - Desarrollo de ciclos de negocio - Ting!
-
Upload
julio-mario-moreno-mejia -
Category
Documents
-
view
70 -
download
0
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
• Nodos
– Acción
– Sub-Workflows
• Transiciones
– Condiciones
• Rol
• Python
• Pulsación de botón
– Join & split
• AND,
• OR,
• XOR
Lógica de los Workflows
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)
• 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
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
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