Multiempresa...¿Es esto posible?


([N4] mdelgado) #1

Hola a todos,

Tengo una aplicación multiempresa y multiejercicio. Os pongo en situación:

Un usuario entra al sistema y le aparece un formulario en el que seleccionar la empresa y ejercicio. Luego, se pone a trabajar y, por ejemplo, abre un formulario con las facturas de la empresa en la que está trabajando. En algún momento, decide ver facturas de otra empresa y, sin cerrar el formulario con las facturas, vuelve a abrir el formulario de selección de empresa y cambia a otra. En ese momento, tiene activada una empresa, pero la información de facturas corresponde a la empresa anterior. ¿CÓMOS SOLUCIONAR ESTO?, ¿OS HA PASADO?


([N4] eic) #2

Hola.

Te puede dar alguna idea lo que se muestra en este tutor:

http://velneo.es/tutor-multiges/

Saludos,

Fran Varona


([N1] Pepeto) #3

Puedes intentar lo siguiente:
- Al cambiar de empresa, disparar una señal.
- Y en todas las rejillas donde aparezcan datos multiempresa, tendras que capturar la señal y refrescar el contenido de la rejilla.

un saludo
Jose Luis
http://www.ascsl.com


([N4] mdelgado) #4

Muchas gracias Fran y muchas gracias Pepeto


([N1] mchll001.yahoo) #5

En realidad deberías instanciar cada empresa, con eso el acceso a la información de cada empresa estaría en rutas distintas y no tendrías problema para consultar simultaneamente el mismo informe.

Michelle R.


([N1] fjvila) #6

Eterno dilema para la multiempresa... ¿Una instancia por empresa o todas las empresas en una misma instancia?
Depende de lo que se decida antes de comenzar el desarrollo se deberá crear una estructura u otra.
¿Cúal es la opción correcta?.... esto da para un post en el blog...


([N4] mdelgado) #7

Bueno, mi problema no tiene que ver con cómo implementar la multiempresa, sino que se trata de un problema de difícil solución.

Fran Varona, con su respuesta, me ha permitido descargar e instalar una solución interesante, pero.......esta solución parte de dos cajas, una de aplicación y otra de datos. Desde la caja de aplicación se tiene acceso al Autoexec. El problema es cuando tengo (comoe s el caso) herencias de cajas. De las cajas más abajo y, desde las rejilals de estas, not engo acceso al Autoexect y no puedo controlar (menor dicho, no sé) la actualización de datos del ejercicio seleccionado. Se apcetan ideas.

GRacias a todos


([N2] overall) #8

Hola a todos,
Si al usuario le das permisos para que puede trabajar en multiempresa y multiejercicio, que problema hay en que pueda visualizar varias facturas o documentos y que cada uno de ellos sea de distinto ejercicio? cada documento debe apuntar a la tabla que controla los parámetros del propio ejercicio, como fechas que lo comprende, si está cerrado, etc... la información la tenemos controlada. Que mejor que estar en la ficha de un cliente y poder ver todo su histórico sin tener que cambiar de ejercicio.
Dado el gran numero de pestañas que podemos tener abiertas en las aplicaciones desarrolladas con v7, se hace muy complicado el control que menciona Miguel. Hecho a faltar poder ejecutar nuestras aplicaciones como si de una web se tratara, si queremos abrimos contenido en una pestaña nueva, de lo contrario cargamos el contenido en la misma pestaña, sería una forma elegante y muy funcional de navegar por nuestra web, quise decir app.
Saludos
Overall
Luis Palomo
overall@overall-bcn.com
www.overall-bcn.com


([N1] juan_figueroa.telefonica) #9

Desde mi ignorancia relativa de V7 y mi desconocimiento de de la gestión multiempresa, parece lógico utilizar instancias distintas para cada empresa ahora que disponemos de esa posibilidad. ¿O es que hay que gestionar datos comunes y/o resulta imprescindible tener todos los datos mezclados y, en consecuencia, y discriminados por empresa, con lo engorroso que resultará para la programación? ¿No será ya suficiente engorro el multiejercicio?


([N1] Pepeto) #10

@juan_figueroa

Si bien es cierto lo que dices, ya es suficiente engorro el Multiejercicio, Multialmacén, Multitlq, ...
La verdad es que complicarlo un poquito mas y hacerlo Multiempresa, no es mucho mas complicado.
Ademas, al final la decision final siempre depende del cliente, y si el desarrollo esta correctamente analizado , se podran compartir datos, y siempre se pueden crear instancias diferentes para mantenerlo separado, incluso aunque el proyecto sea multiempresa.

un saludo
José Luis
http://www.ascsl.com


([N4] mperez) #11

http://mpoliver.wordpress.com/2011/09/06/conceptos-saas-multitenancy-en-velneo-v7-que-es-diferentes-posibilidades-y-cual-elegir/

Igual os sirve este comentario


([N1] ebarbeito) #12

Buen post mperez,

Para mí el dilema sigue reduciéndose a analizar el problema en sí, independientemente de qué tipo de despliegue quieras (monoinsancia, multiinstancia, local, en red, SaaS) la decisión de implementar un requisito en "modo mono" o "multi" sigue atendiendo a una necesidad funcional y sigue formando parte de una lógica de negocio que el la aplicación/solución debe dar respuesta.

Resumiendo el rollo:
- El proyecto ya tiene previsto una solución en modo multiempresa: a desarrollarlo completamente (tanto en datos como en interfaz). Y si no está previsto pero te das cuenta de que la multiempresa posiblemente pueda ser una característica a implementar, si es algo que se te hace evidente entonces sé previsor y minimiza riesgos: a desarrollarlo al menos parcialmente (solo datos, que tu BD esté preparada para desplegar interfaz multiempresa o lo que sea multiCualquierCosa muy evidente pero no necesario en principio).
- El proyecto funcionalmente es monoempresa / monoloquesea pero será desplegado en nube (privada o pública). La palabra nube es sinónimo de multitenancy, y es aquí donde la multiinstancia de Velneo 7 se vuelve casi obligatoria porque así es una buena solución a un problema que es más de infraestructura que funcional.

Por eso digo que el dilema sigue reduciéndose a qué tipo de problema atender, si funcional/modelo de negocio o de infraestructura/escalabilidad

Un saludo


([N4] mdelgado) #13

Buenas a todos,

Creo que no me he sabido expresar, ya que no tengo problema en cómo implementar el multiempresa en mi solución(Multiempresa, multiejercició, multidelegación,etc.). El problema es de usabilidad en la App final. Mi solución tiene 7 cajas de aplicación. Por ejemplo, una de las casas es Almacén (en ella guardo todo lo relativo al mismo, incluido artículos, familias, etc). Por encima de estas 7 cajas tengo una que sirve de unión de todas, en la que tengo el Autoexect (Hereda las 7). Hasta aquí no hay problema. Lo que ocurre es que si, por ejemplo, tengo un formulario en la caja de almacén mostrando los albaranes de la empresa en curso y, sin cerrar el formulario, activo una nueva empresa, no tengo forma de saber cuando se produce esta activación ya quue no se tiene acceos completo al árbol de objeto. Visualmente, tendre una nueva empresa activada y los albaranes seguirán mostrando los de la empresa anterior....no se si me explico


([N1] Pepeto) #14

Te explicaste perfectamente, y de echo, las respuestas de Fran Varona y la mia te indican el metodo de hacerlo.

Lo que pasa, es que despues , el hilo es ha convertido en un pequeño debate sobre la necesidad o no de realizar una aplicacion multiempresa, y como se puede ver, hay diversidad de opiniones.

En lo que se refiere a tu planteamiento, realiza las pruebas con el tutor que te indica Fran Varona, que tiene la misma funcionalidad que yo queria reseñar, el uso de Señales para actualizar todas las rejillas, despues de cambiar de empresa.

un saludo
José Luis
http://www.ascsl.com


([N4] mdelgado) #15

Hola Pepeto,

Gracias de nuevo por tu aportación. La solución aportada por Fran Varona (gracias Fran!!!), sólo es posible implementarla en la caja donde está el Autoexec, ya que desde el resto de cajas no se tiene acceso al Autoexec y esto impide lanzar un evento cuando cambia el desplegable de ejercicion (Item:Cambio seleccion). Por este motivo, en una rejilla que no esté dentro de la misma caja en la que esté el Autoexec no es posible saber cuando se cambia de ejercicio de ninguna manera (al menos, yo no la conozco). Esto proboca el efecto indeseado de estar mostrando una rejilla de albaranes de 2010 y si el usuario cambia al ejercicio 2012, no poder controlando, quedando seleccionado el ejercicio 2012 pero mostrando albaranes de 2010 hasta que el usuario lance una nueva búsqueda.