Manual del programador
¿Te fue útil?
¿Te fue útil?
Por simplicidad: es mucho más sencillo instanciar, heredar, comprender y localizar los objetos.
Además, todos los objetos están organizados en carpetas por módulos o funcionalidad. Esto facilita la posibilidad de separar una parte del proyecto en otro distinto, ya que podríamos copiar las carpetas específicas teniendo luego que copiar aquellas partes comunes que están integradas como pueden ser las tablas maestras y las diferentes configuraciones de vERP.
Están organizados por tipo de objeto, asimismo, dentro de la carpeta están organizados por módulo, y las listas de objetos se ordenan alfabéticamente.
En este criterio se aplican algunas excepciones que son: existe una carpeta específica para
Las tablas de configuración
Las tablas de maestros
Además, las búsquedas y las constantes están junto al proceso que las usa.
En primer lugar están organizados por módulos y sub-módulos, y dentro de esas carpetas por menús.
Los objetos están encarpetados siempre en dos carpetas distintas
1) Objetos de interfaz (color púrpura), por este orden:
Formularios.
Multivistas.
Rejillas.
Dentro de ese orden, los objetos están ordenados alfabéticamente.
Se añadirá además una carpeta con los objetos que se usen en botón menú de alguno de los formularios.
2) Objetos de ejecución (amarillo)
Búsquedas.
Localizadores.
Procesos.
2) Acciones, toolbars y menús (color verde).
Las nomenclaturas alcanzan a todos los ámbitos de la programación ya que es conveniente tener reglas para nombrar de forma clara y precisa desde una carpeta del disco donde almacenaremos nuestro solución hasta la variable local más insignificante.
Una buena nomenclatura proporciona grandes beneficios:
Facilita la comprensión clara del concepto.
Evita ambigüedades.
Facilita la organización.
Facilita la localización: los identificadores se ven completos en propiedades, además cuando son compuestos, se ven acortados también.
Facilita el mantenimiento.
Permite la comprensión de otros desarrolladores.
Reduce el tamaño de los identificadores, por lo tanto se ve reducido el tamaño global del código.
Las tablas siempre terminan con una letra que las identifica con el módulo al que pertenecen, por tanto, lo mismo sus objetos, así se sabe fielmente qué es nombre de objeto y qué es nombre de la tabla origen.
Siempre se usan prefijos para identificar los objetos, así:
El prefijo de un objeto con origen tabla, es la propia tabla.
El prefijo nunca es el tipo de objeto, es decir una búsqueda no empieza por BUS
Cuando un objeto usa a otros el id. contiene tras el prefijo la segunda parte que lo describe. Por ejemplo los subformularios.
Se recomienda siempre el uso de layouts en todos los formularios.
Los márgenes del layout general del formulario son:
Izquierdo: 0
Derecho: 20
Superior: 20
Inferior: 20
Espaciado: 20
Normalmente existe uno para el título de formulario (con el id. LAY_TIT), otro para detalle (con el id. LAY_DET) y otro para el pie de botones (con el id. LAY_BTN).
Los márgenes de estos layouts son:
Izquierdo: 10
Derecho: -1
Superior: -1
Inferior: -1
Espaciado: 10
Siempre que exista necesidad de un layout para agrupar unos controles concretos, éste se identificará con el nombre del campo o campos que agrupa. Y en dicho caso los márgenes serán:
Izquierdo: 10
Derecho: -1
Superior: -1
Inferior: -1
Espaciado: -1
Los controles de edición de un campo, sea cual sea el tipo de campo, siempre tienen como identificador el mismo que el campo. En caso de que tengan una etiqueta de texto, ésta será igual que el campo con el prefijo TXT delante.
Esto hace que sean sencillos de identificar el control durante la edición del objeto y además cuando está utilizando la herramienta de personalización de formulario o rejilla, el localizarlos para ocultarlos o mostrarlos es muy sencillo.
Las imágenes deberán estar optimizadas para ocupar el espacio mínimo imprescindible.
Se recomienda usar una paleta de colores lo más reducida posible, sin pérdida de calidad.
Para usar un fondo de imagen, si es color sólido debe ser pequeña y ampliará todo el área.
Este tipo de recomendaciones le ayudarán a desplegar su aplicación en cloud con éxito.
Heredando vERP.
Puedes crear una solución nueva, con un proyecto de aplicación solamente o añadiendo también un proyecto de datos. En el mismo asistente de creación de la solución, podrás escoger los proyectos a heredar.
Gracias a que vERP está en un sólo proyecto de datos y otro de aplicación, simplemente heredando éstos, tendrás acceso a todos los módulos de la solución.
Importante: siempre cree sus proyectos nuevos con alias para poder utilizar la herramienta de personalización de objetos, pues es una propiedad imprescindible para este fin.
Sí.
Puedes crear tantos niveles de herencia como necesites, pero siempre buscando un equilibrio entre dividir en funcionalidades, y no perder la agilidad que da tener todo localizado en un proyecto.
Ten en cuenta que los proyectos sólo pueden utilizar sus propios objetos y los de los proyectos que hereden, nunca se podrán usar objetos entre proyectos “hermanos”. No obstante, siempre existe la posibilidad de mover un objeto a un proyecto que esté heredado, pasando a ser visible por todos los que estén heredando ese último.
Te recomendamos que copies al menos el marco Autoexec. Éste contiene:
Icono de la aplicación
Formulario principal
Menú principal
Dock izquierdo
Manejador de evento pre-ini
Manejador de evento post-ini
Cuando copias el marco de vERP a tu proyecto de aplicación, por defecto sigue usando los mismos objetos, pero puedes crear objetos nuevos y llamarlos desde el marco nuevo, logrando así un mayor detalle de personalización. No obstante, ten en cuenta que los procesos que son llamados en los manejadores de evento son necesarios para la carga de variables y configuraciones para el funcionamiento normal de la aplicación.
Si además deseas personalizar gráficamente tu aplicación, copia estos tres objetos:
Marco AUTOEXEC
Icono APP_ICO
Formulario INI_ERP
Copiando los tres a la vez y pegándolos en el nuevo proyecto de aplicación, ya el marco usará los objetos. Después desde el nuevo proyecto podrán ser modificados según cada caso.
Se han creado acciones de tipo Inserción para ser utilizadas en los proyectos que hereden vERP_2_app. Cuando se crea una acción nueva en un proyecto que hereda vERP, se deberá crear además un sub-objeto inserción, que llama a su vez a la acción que está en el núcleo de vERP, siempre y cuando tenga el mismo origen, ya sea de tabla o no.
Están creadas en todas las toolbars de rejillas.
La personalización de objetos siempre se puede usar añadiendo nuevos subformularios a las pestañas, modificando acciones que se lanzan etc.
Por otro lado, si ya tiene desarrollos realizados utilizando la herencia inversa con los puntos de inserción proporcionados en el núcleo de vERP, podrá seguir utilizando este sistema sin realizar cambios.
Otro caso en que el deberá utilizar puntos de inserción es en el caso de un formulario insertado que tenga una extensión de ficha y desea que aparezca siempre la opción en la pestaña de gestionar el alta y baja del registro extendido.
Con la herramienta de personalización se puede añadir una pestaña a un separador para un grupo de usuarios en exclusiva.
Pero si lo que se pide es que sea condicionada en función de un campo del registro, en el formulario personalizado que se quiere insertar, añadir la conexión de evento PRE_INI Pre-inicializando, y en el manejador de ese evento PRE_INI se hacen las comprobaciones y en caso de que no cumplirse, utilizar el comando Set retorno = NO.
En dicho caso lo que deberá hacer es sustituir el objeto completo.
Deberá programar el nuevo objeto en su propio proyecto de aplicación de su solución, fuera de vERP
A continuación, deberá sustituir el uso de ese formulario por el nuevo mediante la personalización de objetos.
Si se trata de un formulario que es lanzado desde una opción de menú, deberá sustituir la opción de menú completa y los objetos que ésta use. Podrá copiar todos esos objetos (normalmente se localizarán en la misma carpeta) y a continuación pegarlos en el proyecto personalizado.
Cuando se necesita ampliar campos a una tabla de vERP pero sin realizar modificaciones sobre dicha tabla directamente. De esta forma cuando aparezca una nueva versión o revisión de vERP podremos actualizarla sin perder los cambios realizados ya que estos permanecerán en la tabla de extensión.
En definitiva, ampliamos las información y funcionalidad de vERP respetando su código fuente y sin necesidad de realizar cambios en nuestro código ante la aparición de nuevas versiones.
Desde vDevelop, deberá tener creado el proyecto de aplicación de su propia solución, que herede vERP. En el menú ❖ Objetos la opción ➜ Nuevo objeto ➜ Tabla le permitirá lanzar el asistente de creación de tablas
Existen dos posibilidades:
El origen del formulario es la tabla padre y se crea un subobjeto “Extensión de ficha” en modo campo puntero a la tabla de extensión (se usa el campo automático que crea Velneo en la tabla padre) o en el modo proceso con un proceso de origen de ficha de la tabla padre y destino ficha de la tabla de extensión.
El origen del formulario es la tabla de extensión y se crear un subobjeto “Extensión de ficha” en modo campo puntero a la tabla padre (se usa el campo ID) o en el modo proceso con un proceso de origen de ficha de la tabla de extensión y destino ficha de la tabla padre.
Ambos casos funcionan bien siempre que configuremos correctamente las propiedades de alta, baja y modificación de ficha principal.
Para el caso A los valores más habituales son 10 (no se marca el previo), 5 (Sí se marca el previo) y 10 (No se marca el previo).
Para el caso B los valores más habituales son 11 (Sí se marca el previo), 4 (No se marca el previo), 11 (Sí se marca el previo).
En caso de usar el modo proceso es responsabilidad del programador crear en dicho proceso la ficha de la extensión de ficha del formulario, ya que de esta forma cuando se muestra el formulario ya existe el registro y se puede editar.
Actualmente, si queremos usar menú de botón en los campos puntero a maestro de registro de la “extensión de ficha” del formulario, tendremos que usar la opción B para que funcionen correctamente las acciones de menú de localizar, crear o editar maestro. La opción A no está operativa actualmente y se encuentra registrada como un bug a resolver en futuras versiones.
El hecho de que la tabla sea arbolada le da la posibilidad de generar tantas divisiones y sub-divisiones como sea necesario en la empresa “real”.
Puede crear divisiones de Grupo-Empresa-Delegación-Departamento-División e incluso teniendo una empresa por usuario, dando acceso independiente a cada usuario. Aún así, si un usuario tiene acceso a una rama superior de la empresa, podrá ver todas las sub-ramas de la misma, porque cada documento está grabado en la rama desde la que fue creado.
Veamos un ejemplo:
El acceso a cada empresa se da por usuario, de modo que un usuario puede tener acceso a una rama de las inferiores y sólo verá los documentos de esa, o si tiene acceso a una rama superior podrá ver los de esa empresa y las sub-ramas de la misma.
Las búsquedas de documentos por el índice de empresa, se realizan entre límites, siendo el límite inicial la empresa a la que ha accedido inicialmente (se pide en la entrada a vERP), y para el límite final es concatenado con “ZZZZZZ” para así englobar las subramas.
Cuando en la instalación existe configurada más de una empresa, es posible que desee realizar el cambio de empresa a gestionar pero sin salir de la aplicación.
Desde el menú ❖ Supervisor ➜ Utilidades ➜ Seleccionar empresa de trabajo.
La acción que lanza esta opción es EMP_M_SEL, si se desea se puede insertar en otro punto si el usuario no es supervisor y no tiene acceso a la opción de la barra de menú.
Todos los permisos en vERP se gestionan en base al diccionario de permisos que contiene simplemente una etiqueta y una descripción.
Este diccionario de permisos es pre-cargado en la aplicación. Podrá verlo desde el menú ❖ Supervisor ➜ Diccionario permisos.
El sistema de permisos integrado en vERP persigue estos objetivos:
Abstracto para que pueda ser utilizado en una gran variedad de funcionalidades.
Flexible para facilitar la integración de permisos de las aplicaciones que heredan vERP.
Sencillo de implementar por parte del programador.
Sencillo de utilizar por parte del usuario. Que sólo sean necesarios definir las excepciones para que requiera la menor configuración posible de permisos
Accesible desde el menú ❖ Supervisor ➜ Grupo de usuarios.
Los permisos se gestionan a nivel de grupos de usuario, no a nivel de usuario individual. Un usuario puede pertenecer a múltiples grupos de usuarios y asumirá los permisos de todos sus grupos.
El diccionario de permisos es muy sencillo de definir. Tan sólo requiere una etiqueta y una descripción. Es importante tener en cuenta que lo mejor es definir la etiqueta en base al criterio de excepción.
Por ejemplo, si todos los usuarios van a tener acceso al menú de países, y sólo a unos determinados usuarios no queremos darles acceso al mismo, lo lógico es definir la etiqueta con el valor de la excepción, es decir, verp.menu.pai.no De esta forma conseguimos que la configuración de los permisos en los grupos de usuario sea realmente sencilla.
Además hay que tener en cuenta que se pueden crear tantos grupos de usuario como nos interese y cada usuario puede pertenecer a múltiples grupos de usuario, siendo sus permisos la suma de todos los permisos (de autorización o de negación de autorización) asignados a los grupos de usuarios que tenga asignados.
El diccionario de permisos es muy sencillo de definir. Tan sólo requiere una etiqueta y una descripción.
Es importante tener en cuenta que lo mejor es definir la etiqueta en base al criterio de excepción.
Por ejemplo, si todos los usuarios van a tener acceso al menú de países, y sólo a unos determinados usuarios no queremos darles acceso al mismo, lo lógico es definir la etiqueta con el valor de la excepción, es decir, verp.menu.pai.no
De esta forma conseguimos que la configuración de los permisos en los grupos de usuario sea realmente sencilla.
Además hay que tener en cuenta que se pueden crear tantos grupos de usuario como nos interese y cada usuario puede pertenecer a múltiples grupos de usuario, siendo sus permisos la suma de todos los permisos (de autorización o de negación de autorización) asignados a los grupos de usuarios que tenga asignados.
El objeto que más uso tendrá en el nuevo sistema de permisos es la función PRM_USR que se utiliza. La función incluye documentación de los parámetros de entrada y de los posibles valores de retorno.
Si por ejemplo existe en el diccionario la etiqueta verp.mant.auditoria.no y ejecutamos la función fun:PRM_USR@Usuarios.dat("verp.mant.auditoria.no")
Si alguno de los grupos del usuario tiene asignado el permiso nos devolverá un “1”
Si ninguno de los grupos del usuario tiene asignado el permiso nos devolverá un “0”
Si por ejemplo existe en el diccionario la etiqueta vconta.cta.clt:430,431,435 y ejecutamos la función fun:PRM_USR@Usuarios.dat("vconta.cta.clt:")
Si alguno de los grupos del usuario tiene asignado el permiso nos devolverá “430,431,435”
Si ninguno de los grupos del usuario tiene asignado el permiso nos devolverá un “0”
En la barra de menú ❖ Supervisor ➜ Diccionario de permisos, es posible importar y exportar el diccionario de permisos mediante ficheros planos para enviar a otros servidores u otras instancias.
En la barra de menú ❖ Supervisor ➜ CSS.
Ahí están los registros de CSS que se aplican por defecto en vERP. Podrá cambiar y personalizar el aspecto de su aplicación cambiando ahí el Script correspondiente, lo que sí deberá mantener de forma fija la etiqueta creada por defecto, que es AUTOEXEC o MEN_APP_ERP.
Si es un formulario personalizado que está en su propio proyecto deberá utilizar el comando “Interfaz: establecer hoja de estilo CSS” en el manejador de evento que se lance con señal post-inicializado.
La fórmula texto de la hoja de estilo CSS puede ser indicada de forma fija en el manejador de evento o bien mediante una etiqueta de texto de uno de los registros de la tabla CSS_W que están accesibles desde el menú ❖ Supervisor ➜ CSS.
Si se trata de aplicar una CSS en un formulario del núcleo, puede aplicar una personalización de script para los formularios del núcleo sin modificarlos.
El acceso a las distintas opciones de la barra de menú se puede controlar mediante el Diccionario de permisos.
En el menú ❖ Supervisor ➜ Grupos de usuarios, puede crear un grupo al que va a restringir el acceso a las distintas opciones que puede localizar buscando por las etiquetas “barra menú” en la utilidad de “Permisos sin asignar” del grupo.
En el menú ❖ Supervisor ➜ Opciones de menú están pre-configuradas las opciones del menú del dock izquierdo y en cada una de ellas el objeto a ejecutar, que es un proceso del proyecto:
En la primera pestaña se configura el nombre e icono de la opción de menú.
En la segunda pestaña se configura el objeto a ejecutar, de qué proyecto es, el tipo de objeto (acción, proceso o menú) y a continuación podrá localizar los objetos entre los disponibles del proyecto que se cargarán si todo está configurado. Es imprescindible para esto que el proyecto tenga Alias configurado.
En la tercera pestaña se configuran los permisos de acceso a dicha opción del menú. Si marcar el check de “Todos los grupos de usuarios”, podrá escoger debajo si lo desea algún objeto a excluir. Si no marca el check, seleccione en la rejilla los grupos concretos que pueden acceder.
Se guardan en la tabla PRS_MEN_W.
Se han añadido las opciones de personalización en todas las rejillas y formularios. Esta opción le permitirá configurar totalmente dichos objetos:
Ocultar o desactivar controles en formularios
Ocultar columnas en rejillas
Ocultar, añadir o sustituir un subformulario, ya sea del proyecto actual o de uno heredado
Ejecutar un script
Todo ello podrá hacerlo de forma general para todos los usuarios, o por usuario (inclusión o excepción), además de forma sencilla e intuitiva. Próximamente se podrá hacer por grupos de usuario.
Veamos a continuación algunos ejemplos en imágenes, de lo sencillo que es configurar y el potencial de la herramienta:
En la imagen se muestra un ejemplo de personalización de ocultar controles en formulario de artículos (en este caso se oculta la referencia, tanto el edit como la etiqueta de título del campo).
En la imagen se muestra un ejemplo de personalización de ocultar columnas de rejilla`.
En la imagen se muestra un ejemplo de personalización de sustitución de subformulario por uno de un proyecto que hereda vERP.
Realmente las posibilidades son tantas como casos se vaya encontrando al instalar vERP en sus clientes finales, podrá simplificar la configuración de sus proyectos, personalizar al máximo todos los formularios de su aplicación, sus permisos de acceso a distintas opciones o campos, etc.
Se puede hacer prácticamente de todo…
El código javascript de la personalización se ejecuta en el manejador de evento pos-ini de los formularios. Se puede añadir sub-formularios, sustituir pestañas, css, etc.
Se guardan en la tabla PRS_OBJ_W.
Se guardan en la tabla INF_DEF_W.
En ejecución puede acceder desde el menú ❖ Supervisor ➜ Definición de informes.
Podrá crear nuevos informes desde el menú ➜ Definición de informes siguiendo los mismos pasos que en la aplicación vReport.
A continuación, para realizar las llamadas directas a los mismos, deberá realizarlo desde un proyecto de aplicación propio que herede vERP:
1º Cree un proceso que cargue la definición de informe por la etiqueta (identificador) de informe nuevo que ha creado.
Desde el proyecto de aplicación propio que hereda vERP_2_app, deberá crear un proceso con origen ficha, igual al manejador BTN_OPC_PRT que encontrará en un formulario de documento, por ejemplo VTA_PRE_G. Ahí existe un comando "Informe externo: imprimir…" que deberá sustituir por el comando “Informe externo: exportar a fichero” indicando el parámetro pdf en el tipo de fichero.
A continuación deberá crear una acción que llame a ese proceso. Esa acción tendrá como sub-objeto la inserción VTA_PRE_G_OPC_INS_FIN. Este tipo de inserción lo podrá encontrar en todos los documentos.
Solo podemos crear de extensión contra tablas padre que sean del tipo maestro normal con clave numérica o maestro normal con clave arbolada. No debemos crear nunca tablas de extensión contra tablas de tipo submaestro ni histórico, aunque el editor lo permita.
Puede obtener más información de este tipo de tablas consultando el .
2º Cree una acción que llame al proceso anterior y que tenga como sub-objeto una en vERP_2_app.
