jueves, 15 de septiembre de 2011

Soporte para folleto bancario 19

0 comentarios
 

Acabamos de desarrollar en KMKey soporte para la creación de folletos bancarios modelo 19 para presentación telemática, generando un fichero para entregar al banco para que gestione el cobro de recibos. La funcionalidad es bastante simple: con una nueva opción de menú Generar CSB19 tenemos una pantalla con las píldoras ingreso pendientes de cobro.

Antes de empezar debemos definir el emisor. Para ello crearemos una entrada de empresa en la pantalla de grupos que represente la nuestra, si es que no existe ya, y rellenaremos el campo de cuenta cliente que se usará para el ingreso de los recibos. Una vez creado, tendremos que añadir la propiedad 'csb_presentador_docid' en la raíz del site vía ZMI en la que escribiremos el docid del grupo.

Podemos generar el fichero bancario tantas veces como deseemos, por defecto sólo nos saldrán marcados aquellas líneas que no se hayan exportado aún, y en las que sí se haya realizado alguna exportación nos aparecerá la fecha de la misma. No saldrán las ya cobradas. Aquí también es importante que los clientes tengan definido en la ficha de grupo su cuenta corriente, en caso contrario la línea será ignorada en el proceso y no incluída en el fichero de salida.

Una vez pulsemos en Generar, se creará el fichero bancario a enviar al banco.

Próximamente se implementarán otros folletos bancarios.
Leer más...
martes, 13 de septiembre de 2011

Como personalizar el logo de KMKey

1 comentarios
 
Es frecuente que en nuestro KMKey queramos ver el logotipo corporativo de nuestra empresa o institución.  Para personalizarlo tenemos que acceder al ZMI (Zope Management Interface), para lo cual necesitaremos un usuario administrador y abrir en un navegador la dirección http://url_de_kmkey/manage

Nos aparecerán las internalidades de KMKey, algo parecido a esto:


En esta interficie tenemos que navegar hasta la carpeta portal_skins/custom y añadir allí un objeto del tipo Image, seleccionando una imagen de nuestro disco duro.  Recomendamos usar logos con una altura de entre 50px y 60px para no distorsionar la interficie de KMKey.   Debemos recordar el ID que le ponemos a nuestra imagen, por ejemplo logo_empresa.png.

Una vez tenemos la imagen dentro de nuestro ZMI, debemos volver a la raíz del mismo y, en el frame de la derecha, buscar la pestaña Properties.  Allí tendremos definidas, y si no lo están las podemos añadir, dos propiedades llamadas logo_path y logo_header_path   La primera corresponde al logo que se muestra en la pantalla de login, y el segundo al que se muestra una vez dentro de la aplicación.   Debemos completarlas con el valor del ID de la imagen que hemos subido, en nuestro ejemplo sería logo_empresa.png   Y con eso ya tenemos nuestro KMKey con logo personalizado
Leer más...

Sustitución de recursos

0 comentarios
 
En la nueva versión de KMKey disponemos ya de una utilidad para la sustitución automática de recursos, de forma que cuando un recurso, por el motivo que sea (baja, vacaciones, etc), no puede atender los servicios, se puede definir una sustitución por parte de un nuevo recurso durante un período de tiempo.   Así, con una sola acción, se borrarán todas las asignaciones de los recursos sustituidos, y se crearan asignaciones nuevas para el recurso sustitutor.  La nueva utilidad se encuentra disponible desde la acción Sustituir recurso en las pantallas de Planificar / Recursos y Planificar / Agenda

Leer más...
lunes, 12 de septiembre de 2011

Formación para Administradores: Los Patrones

0 comentarios
 
KMKey incorpora un concepto clave, llamado Patrón de trabajo, que podríamos definir como la representación informática de un procedimiento, término muy usado en la gestión de calidad.  En informática se asemejaría a un tipo de datos, con la diferencia de que los patrones son configurables visualmente por un administrador, y que además incorporan otras cosas como tratamiento de permisos, flujos de trabajo, o creación de subobjetos.

Siempre que creamos un expediente o proyecto en KMKey lo haremos en base a un Patrón de trabajo.  El patrón nos va a determinar, como mínimo:

  1. Qué campos componen la definición del expediente o proyecto 
  2. Qué Perfiles vamos a poder asignar a los usuarios de ese expediente o proyecto
  3. Qué estructura de tareas y subtareas, con plazos y esfuerzos, se va a generar asociado al expediente o proyecto
  4. Qué documentos pueden generarse a partir de plantillas en ese expediente o proyecto
  5. Qué conceptos contables van a poder usarse al entrar información económica del proyecto 

Para poder crear o editar patrones de trabajo, tenemos que ser usuarios administradores.  Si lo somos podemos visitar la opción Admin / Patrones  y observar alguno de ellos.   Si estando en un patrón visitamos la opción Campos nos aparecerá una pantalla parecida a ésta:



En ella vemos que podemos ir definiendo los campos que necesitamos para componer nuestro patrón o procedimiento.  La primera columna corresponde al identificador interno del campo, y es importante NO usar acentos ni espacios en blanco.  Se recomienda además usar minúsculas.   Obsérvese también que haciendo click en esta columna se puede definir una ayuda asociada al campo, cosa muy útil para procedimientos a usar por usuarios noveles.  La segunda columna corresponde a la etiqueta que van a visualizar los usuarios asociada al campo, y es un texto libre.  La tercera columna es el tipo de datos, seguida del tipo de widget que se quiere usar para su representación. Después viene el grupo de campos (se pueden definir agrupaciones en la parte final del mismo formulario), el ancho en pantalla, el valor por defecto y una marca que define si el campo es obligatorio.  Todo ello acaba generando una pantalla de definición como ésta:



Como widgets principales podemos destacar la Cadena (una linia de texto), el Texto (un bloque de texto), la Selección (donde podremos definir un conjunto de valores internos/externos posibles), la Fecha (que nos deja elegir sobre un calendario) y la Relación con Grupo (que nos deja relacionar el expediente con un cliente, por ejemplo).   Hay muchos más widgets disponibles desde las interficies avanzadas, cada uno con sus peculiaridades, pero sólo están disponibles para usuarios con perfil técnico por su mayor complejidad.

Si dejamos la pantalla de Campos y vamos a la pantalla Modificar patrón, veremos que después del título y descripción aparece una campo llamado XML de Creación de objetos. Este XML se usa principalmente para definir la estructura de tareas y subtareas, con plazos y esfuerzos previstos, asociada al patrón, aunque puede tener otros muchos usos.   Si usted esta familiarizado con la sintaxis XML, le recomendamos la lectura de la guía Definición del XML de creación de objetos  y Usos avanzados del XML de creación de objetos   De lo contrario no se preocupe, también disponemos de un Excel capaz de generar el XML básico para la definición de tareas

El siguiente campo corresponde a un XML de Objetos Generables.  Se refiere a plantillas OpenOffice contenidas dentro de nuestro propio KMKey que contienen instrucciones para combinarse con datos de nuestros expedientes y generar un documento cumplimentado o semi-cumplimentado.    Ejemplos de estos usos son un informe de incidencia, un documento factura o cualquier tipo de informe o documento asociado al patrón que pueda automatizarse.    Para la creación de estas plantillas recomendamos la lectura de la Guía para definición de listados  Para su uso desde un patrón, se entra en el campo XML algo parecido a:


document
default_title="registro_de_incidencia.doc"
formats="doc#@oo#@pdf"
default_format="pdf"
getDocid="403424947"
view_class="Products.KMKeyDefault.reportsview.SpanishReportsView"
view_context="context.getContent().getKMProject()"/


Donde se especifican formatos de salida, formato por defecto, nombre por defecto, y los más importante, el getDocId o identificador interno de la plantilla.

Nos queda únicamente definir las relaciones Patrón - Perfiles, que son varias:

  1. Campo Perfiles que pueden ser asignados en expedientes creados con este patrón.  Permite definir los perfiles que podrán se usados desde los expedientes
  2. Campo Perfiles bloqueados en objetos creados con este patrón.  Define los perfiles que se bloquean automáticamente al crear los expedientes con este patrón.  Típicamente tendrá marcados los valores Acceso Básico y Creadores de proyectos y contactos.
  3. Campo Los miembros de estos grupos tendrán acceso a todos los expedientes creados con este patrón.  Automatismo para asignar grupos de usuarios a todos los expedientes durante su creación.  Los grupos marcados serán asignados a cada expediente que se cree asociados al perfil que ellos mismo definen
  4. Pantalla de la opción Acceso al patrón.   Esta opción es especialmente importante porque controla qué usuarios podrán crear expedientes usando este patrón.  En la columna de la izquierda tenemos los perfiles bloqueados (de nuevo típicamente Acceso Básico Creadores de proyectos y contactos)  y en la columna de la derecha los grupos de usuarios explícitamente permitidos.  Para entender el funcionamiento de esta pantalla es necesario haber comprendido previamente el uso de permisos para lo cual recomendamos la Formación sobre permisos  NOTA: si crea patrones nuevos por defecto aparecerán todos los grupos bloqueados para evitar que sus usuarios los usen mientras se están definiendo.  Ajuste los permisos cuando puedan empezar a usarlo.
Leer más...

Formación para Administradores: Los Permisos

0 comentarios
 

En primer lugar, para gestionar los permisos es necesario comprender que KMKey tiene una estructura de árbol de objetos:  hay una raíz a la que llamamos aplicación, que contiene expedientes o proyectos que a su vez contienen tareas, y éstas contienen lo que llamamos píldoras de información (documentos, notas, horas trabajadas, etc).  Por otro lado, tenemos los Perfiles, que no son más que conjuntos de permisos.

La gestión de permisos lo que hace es otorgar un perfil a un usuario en un punto concreto del árbol, lo que le proporciona unos permisos desde ese punto hacia arriba.  Esa es la idea principal.  Todo lo que viene a continuación son matices sobre esta idea fundamental que no se debe perder de vista.   Para ilustrarla con un ejemplo, imaginemos que tenemos un perfil llamado "Jefe de Proyecto", que proporciona todos los permisos, y queremos que el usuario "juan" se el jefe de los proyectos "A" y "C", mientras "pepe" es el jefe del proyecto "B".  Si nos vamos a la opción Equipo / Permisos en cada uno de los proyectos y asignamos los respectivos usuarios a su perfil, éstos pasarán a tener control total sobre esos proyectos concretos, sin ni siquiera visualizar los proyectos de otros ("juan" no ve el proyecto "B", por ejemeplo, pero ve todo lo que sucede en "A" y "C")

Bueno, en realidad, además de otorgar un Perfil a un usuario también podemos dárselo a un grupo de usuarios, caso útil si un grupo de empleados trabajan siempre juntos, eso es lo que aparece en el primer cuadro de la pantalla Equipo / Permisos cuando estamos en un expediente o tarea.

Para crear nuevos Perfiles, podremos hacerlo desde la opción Equipo / Grupos / Añadir Grupo / Grupo de Permisos siempre y cuando seamos administradores del sitio.   Para crear usuarios haremos lo mismo desde la opción Equipo / Contactos / Añadir Contacto  Si somos administradores podremos proporcionarle un nombre de usuario y una clave, y desde la opción Equipo / Permisos (previa selección del punto del árbol en la estructura de navegación de la izquierda), podremos ir asignándole Perfiles.

Observaremos que los perfiles que podemos otorgar van variando según el punto del árbol, son distintos en la raíz que en los proyectos, incluso pueden ser distintos según el tipo de proyecto o expediente.   Eso es porque KMKey permite definir qué perfiles son de Aplicación (mediante un checkbox al crear), y qué perfiles son de Patrón (se asocian a cada patrón de trabajo, se hablará de ello en el post específico de patrones de trabajo)

Nos queda por resolver una paradoja.  Si creamos un Perfil de Aplicación con permiso de lectura, ¿ eso otorgará a los usuarios que sean asignados acceso a toda la información de KMKey ?  Pues sí, efectivamente.  ¿ Y cómo funciona el perfil Acceso Básico, que NO da acceso a todo el KMKey ?  Pues mediante un sistema que se llama Bloqueo de Perfiles, y que desautoriza un Perfil desde un punto determinado hacia arriba del árbol.   Podemos observar esta funcionalidad en la parte final de la pantalla Equipo / Permisos , donde aparece el cuadro titulado "Perfiles bloqueados desde".   Tambiés es posible (e imprescindible de hecho), automatizar este bloqueo definiendolo en los patrones de trabajo.  Es muy recomendable que todo patrón de trabajo bloquee al menos los Perfiles de Aplicación definidos por defecto (el Acceso Básico y el Creador de proyectos y contactos), de los contrario los expedientes creados con ese patrón serán visibles a todos los usuarios.

Ya para acabar, comentar la existencia un perfil un tanto especial, llamado Owner o Propietario  Este perfil existe y proporciona todos los permisos, y se asigna automáticamente al usuario que crea cada objeto.   Por ejemplo, si yo creo una nota en un expediente, seré Propietario de esa nota, cosa que me proporcionará el permiso para poder borrarla, por ejemplo, cosa que no podré hacer con la nota de mi vecino, a no ser que posea algún otro Perfil que me deje borrar cualquier cosa en ese expediente.  No contradice nada de lo anterior, pero es importante conocer su funcionamiento

Ya para terminar, algunas referencias a otras entradas relacionadas con la temática expuesta:


Leer más...