Manual del programador
Última actualización
¿Te fue útil?
Última actualización
¿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.
Se trata de un documento dirigido a desarrolladores que desean utilizar un sistema diseñado para aprovechar todas las bondades de la plataforma Velneo, facilitando una forma de programación probada y fiable que acelerará tu productividad al evitar tener que pensar en muchos aspectos del día a día de un programador.
Explicación de cómo se gestiona la ayuda en vídeo dentro de la plantilla.
Explica las opciones de configuración:
Configuración general de la interfaz de la aplicación.
Opción de menú configuración de aplicación.
Nombre.
Barra de estado.
Temas → Flujo de carga: Empresa → Configuración de aplicación → AUTOEXEC (CSS).
Icono.
Configuración general de supervisor de la aplicación.
Log transaccional. → Tabla LOG_TRN_W.
Log de sesión. → Tabla LUC_W (disco) a partir de LOG_SES_W (memoria).
Control de usuarios concurrentes (minutos para mantener activa, minutos para caducar).
Nº máximo de usuarios concurrentes → A nivel de aplicación → También se puede configurar a nivel de empresa.
Usuarios conectados → Expulsar.
Configuración general de datos de la aplicación.
Datos de ejemplo generados.
Migración en curso.
Control de migración de versiones ejecutado → Proceso CTL_CHG_VER.
FTP para la descarga de los ficheros JSON.
Botón descarga.
Botón importar.
Configuración general de optimización de la aplicación.
Tablas a cachear en memoria.
Nº registros a mostrar en carga inicial de documentos de compras y ventas.
Explica cómo están programadas las tablas de Empresas y Divisiones.
Empresas y divisiones para el supervisor y el usuario final.
Empresas y divisiones para el programador.
Divisiones.
Usuarios con acceso permitido.
Supervisor.
Configuración.
Tablas que usan empresa, división o son comunes.
Consideraciones generales.
¿Qué casos de uso tengo trabajando en una sola instancia?
Si quiero que cada empresa tenga sus propios maestros.
Si una tabla maestra tiene campo empresa ¿podría tener registros específicos para una empresa y otros que no tengan asignada empresa los pudiese usar en todas las empresas?
Explica cómo está programado el módulo de personalización de rejillas y formularios de la plantilla.
Opción de menú en configuración.
Objetos personalizables: rejilla y formulario.
Tipos:
Ocultar controles.
Desactivar.
Añadir subformulario.
Sustituir subformulario.
Quitar subformulario.
Ejecutar script.
Controles.
Scripts.
Permisos.
Explicación detallada de la tabla de Contactos.
¿Por qué una tabla para todos y no cada tipo en una tabla independiente?
Esquema de tablas con contactos, direcciones, medios de contacto y relaciones → Esquema ENT.
Objetos de interfaz de un contacto.
La subindexación.
Contabilidad.
Explicación detallada de la tabla de movimientos de almacén, que se utiliza para las líneas de albaranes, facturas, inventario, regularizaciones y traslados.
Es un resumen de las existencias por cada empresa-artículo-almacén. Explicación de cómo está programado dicho módulo.
Acumula información de diferentes orígenes.
Campos calculados.
Recálculo.
Explica todos los manejadores de eventos y procesos que se lanzan durante la primera ejecución de Velneo vERP.
Pre-ini - Configuración inicial (CFG_INI): Este proceso se encarga de ejecutar otros procesos adicionales que permiten realizar diferentes tareas.
Control Usuario concurrente (LUC_W_CAD): Encargado de detectar las sesiones caducadas, y al encontrarlas, las expulsa eliminandolas de la tabla.
Generación de datos de ejemplo (GEN_DAT_EJE): Se encarga de crear por primera vez, algunos registros de tablas principales o maestras:
Serie (SER_M)
Tipo documento (DOC_TIP_M)
Forma de pago (FPG_M)
Idioma (IDI_M)
Moneda (MON_M)
País (PAI_M)
Contactos (ENT_M)
Almacén (ALM_M)
Tipo de relacion (REL_TIP_M)
Empresa (EMP_M)
Familia (FAM_M)
Artículo (ART_M)
Grupo de usuario (USR_GRP_M)
Conceptos automáticos (CNC_C)
Usuarios (USR_M):
Si no existe crea el primero y lo asocia al grupo creado.
Generación datos de tablas principales (GEN_DAT_TAB): destinado a realizar la descarga y posterior importación en 3er plano, de los ficheros que contienen los datos iniciales de otras tablas. Internamente ejecuta los procesos:
DES_DAT_JSON: Proceso que descarga del FTP de Velneo.
IMP_JSO: Proceso que importa los JSON descargados.
PRM_DIC_W_GEN_TAB: Proceso que genera los permisos por defecto.
Pre-ini - Control cambio de version (CTL_CHG_VER): proceso encargado de evaluar de manera secuencial los cambios de versión desde la v19.0 hasta la v26.1 y realiza los ajustes que cada versión requiera. Después de ello realiza la regeneración de todos los índices complejos que existan en el proyecto.
Pre-ini - Proceso arranque (AUTOEXEC): este proceso se encarga de leer todas las configuraciones y valores iniciales para que el vERP se inicie con los datos de sesión necesarios, como lo son identificar el usuarios, los grupos, los permisos, el CSS aplicar, entre otros.
Pos-ini - Configurar barra de menú (CFG_BAR_MEN): proceso en JS el cual genera, de manera dinámica, la barra de menú que se mostrará al usuario, en base a su perfil.
Pos-ini - Cambiar titulo de aplicacion (CHG_TIT_APP): proceso en JS encargado de modificar el título a mostrar en la cabecera del vClient según lo configurado.
Pos-ini - Abrir formulario de inicio (FRM_INI_TAB): Acción que al ser disparada, muestra en la pantalla central, una pestaña que contiene el formulario principal de la solución.
Pos-ini - Contabilizar deuda Vencida (VTO_COB_C_CON_VTO_2P): proceso en 2do plano, encargado de contabilizar todos los vencimientos a cobrar pendientes.
Pos-ini - Cargar opciones de menu en 2do plano (CAR_OPC_MEN): proceso que carga en memoria los registros de las opciones de menú.
Adicional - Formulario de menú general (MEN_APP) - Timer: además de volver a controlar el log de usuarios concurrentes, también el formulario es encargado de mostrar el menú dinámico en base a los grupos de usuarios que pertenezca el usuario logueado.
Explica cómo están pogramados los menús.
Tipos de menú:
Básicos: sin búsquedas.
Tablas muy sencillas como ejercicios.
Maestro: con búsqueda por trozos y desactivados
Maestros.
Documentos: con búsqueda por trozos, desactivados y otros filtros.
Documentos de compras y ventas.
Complejos: con búsquedas desde-hasta estados.
Ficha de almacén.
Extracto contable.
Todos comparten un mismo diseño, sus partes son:
Pestaña.
Título.
Criterios de búsqueda.
Vista de datos.
Toolbar.
Multi selección (en algunos casos).
Programación del formulario (con o sin origen) que hace de menú.
Propiedades.
Diseño (layouts).
Controles de edición.
Búsqueda (objeto).
Panel de búsqueda avanzada.
Ayuda.
La vista de datos.
Conexiones y manejadores de evento.
Variables locales.
Qué hay que cambiar cuando se genera un nuevo menú con copiar/pegar como...
Explica los distintos métodos de los que dispone Velneo vERP para la importación de datos.
Importación de texto plano (csv, text, etc): método simple de importación, donde nosotros conocemos la estructura del fichero, y por ende, sabemos cómo leerlo e interpretarlo para realizar la importación.
Importación dinámica (vERP): método implementado en vERP el cual en base al directorio seleccionado, lee todos los ficheros con extensión CSV y cumpliendo reglas estrictas en la generación del fichero, se realiza la importación de todos los ficheros que encuentre.
Importación y exportación JSON (vERP): métodos disponibles en todos los maestros principales del vERP, el cual permite generar un fichero en el cacherun con extensión JSON, el cual contiene todo el contenido disponible en la rejilla donde se ejecute.
Importador SQL (Manual - Excel): es un método utilizado mayormente cuando queremos realizar procesos de importación de ficheros xls o xlsx, consiste en utilizar el driver DataBaseEngine de Microsoft, para tratar las hojas de cálculo como una base de datos, y poder realizar lecturas con los comandos de BD de Velneo.
Importador SQL (Automático - Plataforma): es un complemento integrado en la plataforma de Velneo, especificamente en el vDevelop, el cual permite no solo importar la estructura de la base de datos, sino también sus valores o contenido.
Importador Dinámico (Ecosistema): complemento disponible del ecosistema, mediante esta funcionalidad, podremos automatizar los procesos repetitivos de importación de registros desde ficheros externos, permitiendo configurar de forma dinámica la asignación de campos y sus contenidos a campos de tablas de Velneo.
Explica las distintas formas que dispone Velneo vERP para cambiar la interfaz en ejecución.
La primera forma de cambiar la interfaz es aplicando los estilos: sistema, windows, mac, fusion.
En Web se usa CSS3 y Sass.
Qt tiene las Qt Style Sheets con una funcionalidad limitada respecto a CSS3.
Las hojas de estilo de Qt usa el box model.
Tipos de selectores.
Objetos y controles.
CSS -> Qt QSS:
Las hojas de estilo se aplican en cascada.
Admiten includes.
¿Una CSS con todo o muchas CSS, una para cada control?
Usar valores constantes es engorroso, aprendamos del mundo web. Usemos variables.
Las CSS se pueden exportar e importar entre servidores.
Temas.
Equivalente al uso de Sass en web.
Las CSS deben estar preparadas.
Es mucho más fácil aplicar temas.
Los temas se pueden exportar e importar entre servidores.
Configuración de temas
Por empresa, para saber cuando estás en una otro empresa.
General para toda la aplicación.
Por defecto AUTOEXEC.
Tema compacto para pantalla de menor resolución.
Se puede aplicar una CSS en el PRE_INI de cualquier objeto.
Si tienes una versión de vERP personalizada directamente en sus proyectos de datos o aplicación, en este vídeo te mostramos como puedes actualizarlo a una nueva versión de vERP siguiendo unos sencillos pasos:
Instalar la nueva versión en el otro vServer.
Abrir en vDevelop la nueva versión de vERP.
Abrir en otro vDevelop la versión de vERP anterior personalizada.
Eliminar los objetos de los proyectos de datos y aplicación de la nueva versión que estén personalizados.
Exportar los directorios de scripts personalizados de la versión anterior.
Importar los directorios de scripts personalizados en la nueva versión.
Copiar las carpetas personalizadas de los proyectos de datos y aplicación de la versión anterior a la nueva.
La importancia de la base de datos en una aplicación.
Tipos de tablas.
Tipos de campos.
Tipos de índices.
Los contenidos iniciales.
Actualizaciones vs Eventos de tabla o triggers.
Variables globales.
Características especiales de la base de datos Velneo.
Listas y fichas.
Los planos de ejecución y el Cloud.
Bloqueo blando vs Bloqueo duro.
Búsquedas.
Índice complejos.
Transacciones y optimizaciones.
Configuración a nivel de empresa.
Diccionario de permisos.
Contadores basados en punteros al último registro.
Tabla de contactos vs Tablas de clientes, proveedores, ...
Movimientos de almacén vs tablas de líneas.
Totales en cabecera vs Tabla plural de totales.
Acumulados y saldos en contabilidad y almacén.
Formas de pago porcentuales.
Personalizaciones.
Datos de arranque.
Fork:
¿Qué es?
¿Qué no es un fork en Velneo?
¿Cómo hacer un fork?
Mejora en Velneo 27 -> singulares de plural.
¿Cuándo hacer un fork?
Personalización por herencia:
¿Qué es?
¿Qué puedo personalizar el tiempo de ejecución?
Personalizar usando puntos de inserción.
Personalizar usando reemplazo de objetos.
Personalizar usando tablas de extensión.
Muestra cómo, partiendo de la plantilla de código abierto Velneo vERP, podemos personalizarla para convertirla en nuestra aplicación utilizando diferentes técnicas de programación.
Explica cómo todas las aplicaciones programadas con la plataforma de desarrollo Velneo, sin necesidad de programar nada disponen de la API Rest de Velneo vERP para consumir sus datos y funcionalidades.
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.
.
.
.
.
.
.
.
.
(vídeo)
(vídeo)
(vídeo)
