Tabla Zonas, arbolada?


([N1] OscarBarea) #1

Buenos días,
Quiero implementar una tabla para poder llevar el control de Agentes por Zonas.
Esta tabla debería tener formato jerárquico (España, comunidades, provincias, poblaciones y…)
El problema que le veo es que mi aplicación tiene dos campos importantes ( REG Y EMP) que son únicos. Con eso quiero decir que cada REG y EMP deben tener su propia estructura.
Pero el caso es que este tipo de tabla no lo permite
Como habéis resuelto este tema?, cual es la mejor opción?
Gracias
Oscar B


([N1] OscarBarea) #2

Hola,
Nadie tiene esta misma situación?
Saludos
Oscar B.


([N1] wikan) #3

Y, ¿qué es REG y EMP?

Puedes montarlo como tablas independientes si no quieres complicarte mucho, una tabla para comunidades, provincias, poblaciones y zonas.
Quizás una única tabla poniendo el tipo de región.


([N1] OscarBarea) #4

Los campos REG y EMP son únicos par cada Empresa, y la aplicación es multiempresa y Registro.
Quisiera una tabla arbolada de Zonas, para poder gestionar bien los Agentes comerciales.
Así un Agente con zona “Andalucía” cogerá todos los clientes que cuelguen de Andalucía.
Una tabla arbolada soluciona esta tesitura, no?


([N1] wikan) #5

No se si la arbolada te soluciona o te empeora.

Yo lo que veo a priori es:

  • Tabla AGENTES, con maestro zona
  • Tabla CLIENTES, con maestro zona
    Todas ellas con REG y EMP para tener el sistema multiempresa.

Con un procesos puedes cargar todos los clientes de la zona x que será la misma zona que el agente.

Ahora, como quieras controlar la zonas es otro tema. Ya que si es multi-empresa. Puede que cada empresa quiera gestionar de una manera las zonas. A lo mejor ya no es Andalucía, si no Sevilla, Cádiz, Norte, Sur, etc.

Ahora bien, si quieres llevar un control de poblaciones puedes tener varias tablas, PAIS, PROVINCIA, COMUNIDAD, LOCALIDAD y a la localidad le asignas una zona. Dicho eso, cada empresa puede asignar una zona distinta a cada localidad. Por lo que…tendría que ser una tabla independiente por empresa.
REG, EMP, LOCALIDAD, ZONA y mostrarlo en el formulario de alguna manera.

Yo creo que entrada podrías irte a la primera opción, una tabla nueva ZONAS. Que cada empresa lo gestione sus zonas.

Disculpa el rollito que solte :wink:


([N1] OscarBarea) #6

Gracias Wikan,
Pero el problema radica en que de una Zona pueden colgar muchas zubzonas, de aquí la tabla arbolada.
Andalucía tiene todas sus provincias y poblaciones. Cataluña, lo mismo, y así sucesivamente.
Si tengo un Jefe de Ventas de Andalucía, cogerá todos los clientes que estén en esta Zona, incluyendo todas sus provincias y poblaciones.


([N1] wikan) #7

El problema de la arbolada es la multiempresa.
Si son empresas totalmente distintas, que no ven los datos una de otras, vas a tener un lío con los códigos de la arbolada.
Si son del mismo grupo y son compartidas entonces te vale perfectamente una tabla arbolada.


([N1] OscarBarea) #8

Y si obligo que los 3 primeros caracteres de la tabla arbolada sea un identificativo único que solo lo vea una empresa?
A través de indices, supongo que podré visualizar solo los registros que pertenezcan a la Empresa, no?
Gracias


([N4] Infortic) #9

Hola, perdón por el tocho por adelantado.

Sí, puede ser arbolada, hay muchas formas de atajar lo que comentas, aunque pienso que arbolada puede ser un poco lío.

En el caso de hacerla arbolada te digo cómo lo haría yo (que puede ser una buena o mala opción).

Yo no dejaría que el usuario meta el ID del registro, sino que lo calcularía.

Por ejemplo crearía en la tabla de ZONAS (arbolada) un campo enlace a maestro llamado PADRE (a la tabla de ZONAS) que enlaza al nodo del árbol del que cuelga ese registro, y que todos cuelguen de un nodo inicial que sea el código de empresa. Además otro campo CODIGO que será el código de la zona y otro campo EMPRESA para poder filtrar por ahí.

El campo ID le puedes poner contenido inicial #PADRE.ID + “-” +#CODIGO o algo así para que se generen todos los registros de la misma forma.

Así puedes tener:

001 EMPRESA
001-ALI ALICANTE
001-ALI-03600 ELDA
001-ALI-03610 PETRER
001-VAL VALENCIA

De forma arbolada.

Para dar una nueva alta habría que hacer que el usuario seleccione de donde debe de colgar el registro. Esta forma es más compleja pero evitas que el usuario meta codigos que no quedan “colgando” de donde deberían.

Luego por medio de índices puedes hacer lo que comentas, filtrando por empresa.

La diferencia fundamental es a la hora de implementar búsquedas.

Por ejemplo, tienes una búsqueda de clientes, y quieres saber todos los clientes de Alicante. Ya no puedes usar en la búsqueda un componente normal donde especificas el código de zona 001-ALI, porque los clientes no tienen ese código sino 001-ALI-03600 que es un nivel por abajo. Para solucionarlo el componente de búsqueda debe de ser “Entre límites”

Limite inicial: COD_ZONA
Limite final: COD_ZONA + “ZZZZZZZZZZZZZZZZZZ”

Para que coja todas las zonas que sean 001-ALI o que cuelguen de ella.

Un saludo.


([N1] OscarBarea) #10

Muchas gracias Infortic,
El planteamiento es bueno y es el que implementaré.
Lo que no me queda muy claro es el enlace a maestro sobre la misma Tabla ZONAS, para que sirve?, podría hacer que la propia empresa tuviera un campo con el “Identificativo único” y que se pusiera como contenido inicial. De igual forma, podría validar el campo y mirar si los primeros caracteres coinciden con el de la Empresa.
Saludos


([N4] Infortic) #11

No es necesario, lo uso sólo para el contenido inicial de #ID, también puedes no ponerlo y dejar que el usuario meta el código comprobando la empresa, pero puedes tener “problemas” al dejar que el usuario meta todo el “churro” del ID.

Por ejemplo, se crea una zona con código 001-BA que es barcelona y otro usuario crea otro codigo que es 001-BAD que es badalona, pues bien, 001-BAD colgaría de 001-BA en lugar de estar al mismo nivel.

Si el usuario sólo mete el valor código y de donde cuelga, el ID se calcula de forma automática con el contenido inicial y siempre tiene el mismo formato, además analizar si el campo CODIGO está bien construido será más sencillo que analizar el ID completo, puedes obligar a que siempre tenga el mismo nº de caracteres y cada nivel se construya siempre igual.

Es una idea, por supuesto no es necesaria, comprobar los primeros caracteres es más que suficiente.


([N1] OscarBarea) #12

Gracias Infortic,
Razón tienes, trataré de trabajar la inserción de datos facilitando la propia estructura jerárquica.
Saludos