Introducir un campo dos veces en un formulario

A mi lo primero que se me ocurre es crear un atributo personalizado en la
entidad llamada que sea una copia del que quieres mostrar en 2 pestañas
distintas. Añadir el nuevo atributo en lugar en el que querías mostrar por
segunda vez el original. Y luego mediante el evento onsave asegurarse de que
tanto el atributo original como el personalizado tengan el mismo valor.

De todas formas es una solución un poco "chapuza". Creo que deberías
plantearte otras alternativas antes de tirar por aquí. Por ejemplo, agrupar
los campos que quieras utilizar en ambas visualizaciones en una sola pestaña
y los específicos en pestañas separadas. O añadir una entidad personalizada
con los nuevos datos, y con una relación jerárquica con llamada,
estableciendo los roles de seguridad para que sólo los usuarios de la unidad
de negocio que quieras puedan acceder a la nueva entidad.

Además hay otro problema, utilizar el DHTML para ocultar pestañas, u otros
métodos del DHTML que no vienen especificados en el SDK, son métodos de
personalización no soportados y podrían darte problemas en el futuro.Y otro
problema más. Aunque consigas ocultar la pestaña en el formulario, los
usuarios podrán ver todos los campos a la hora de imprimir y de hacer
búsquedas avanzadas lo cual podría quedar un poco "cutre". Y te quedaría por
solucionar el tema de obtener los datos del usuario mediante alguna llamada a
la plataforma desde el evento onload. No se, lo veo un poco "enrevesado".

En el caso de que sigas por la solución de las pestañas algunos consejos:

Comentarte que es posible ocultar pestañas por ejemplo,
window.document.all.tab1Tab.style.display='none' en el onload del formulario
de la llamada ocultaria la pestaña de notas.

Manual de JScript:
http://msdn.microsoft.com/library/d...rary/enus/
script56/html/js56jsoriJScript.asp

Manual de DHTML:
http://msdn.microsoft.com/library/d..._entry.asp

Y por supuesto consulta el apartado de scripting de cliente en la guía del
SDK.

Bueno a ver si a alguien se le ocurre otra solución, de todas formas estaría
bien que postearas la solución que utilices al final y los detalles de como
lo coseguiste.

Saludos, y perdón por enrollarme tanto.

Marco Amoedo
PlainConcepts.com


"Félix Durán" escribió:

Hola,

Estaba pensando en adaptar el formulario principal de la llamada telefónica
de forma que cuando un usuario pertenece a una unidad de negocio determinada
se muestre la pestaña de Llamada telefónica con los campos nuevos y la
distribución de campos que quiero crear, mientras que para el resto
aparecería la pestaña normal (la que viene por defecto en el CRM) sin
customizar.

En el formulario principal puedo añadir pestañas y supongo que en el on load
del formulario puedo ocultarlas o mostrarlas según me convenga, pero no se
como puedo repetir campos.

Es decir lo que quiero es poder ver un campo en más de una pestaña, pero no
parece posible porque una vez que se sitúa un campo en una pestaña desaparece
de la lista de campos

¿Hay alguna solución?

Gracias y saludos.
Félix Durán

Para mi ha sido esclarecedor, nada de rollo.

Gracias Marco.

Félix Durán


"Marco Amoedo" escribió:

A mi lo primero que se me ocurre es crear un atributo personalizado en la
entidad llamada que sea una copia del que quieres mostrar en 2 pestañas
distintas. Añadir el nuevo atributo en lugar en el que querías mostrar por
segunda vez el original. Y luego mediante el evento onsave asegurarse de que
tanto el atributo original como el personalizado tengan el mismo valor.

De todas formas es una solución un poco "chapuza". Creo que deberías
plantearte otras alternativas antes de tirar por aquí. Por ejemplo, agrupar
los campos que quieras utilizar en ambas visualizaciones en una sola pestaña
y los específicos en pestañas separadas. O añadir una entidad personalizada
con los nuevos datos, y con una relación jerárquica con llamada,
estableciendo los roles de seguridad para que sólo los usuarios de la unidad
de negocio que quieras puedan acceder a la nueva entidad.

Además hay otro problema, utilizar el DHTML para ocultar pestañas, u otros
métodos del DHTML que no vienen especificados en el SDK, son métodos de
personalización no soportados y podrían darte problemas en el futuro.Y otro
problema más. Aunque consigas ocultar la pestaña en el formulario, los
usuarios podrán ver todos los campos a la hora de imprimir y de hacer
búsquedas avanzadas lo cual podría quedar un poco "cutre". Y te quedaría por
solucionar el tema de obtener los datos del usuario mediante alguna llamada a
la plataforma desde el evento onload. No se, lo veo un poco "enrevesado".

En el caso de que sigas por la solución de las pestañas algunos consejos:

Comentarte que es posible ocultar pestañas por ejemplo,
window.document.all.tab1Tab.style.display='none' en el onload del formulario
de la llamada ocultaria la pestaña de notas.

Manual de JScript:
http://msdn.microsoft.com/library/d...rary/enus/
script56/html/js56jsoriJScript.asp

Manual de DHTML:
http://msdn.microsoft.com/library/d..._entry.asp

Y por supuesto consulta el apartado de scripting de cliente en la guía del
SDK.

Bueno a ver si a alguien se le ocurre otra solución, de todas formas estaría
bien que postearas la solución que utilices al final y los detalles de como
lo coseguiste.

Saludos, y perdón por enrollarme tanto.

Marco Amoedo
PlainConcepts.com


"Félix Durán" escribió:

> Hola,
>
> Estaba pensando en adaptar el formulario principal de la llamada telefónica
> de forma que cuando un usuario pertenece a una unidad de negocio determinada
> se muestre la pestaña de Llamada telefónica con los campos nuevos y la
> distribución de campos que quiero crear, mientras que para el resto
> aparecería la pestaña normal (la que viene por defecto en el CRM) sin
> customizar.
>
> En el formulario principal puedo añadir pestañas y supongo que en el on load
> del formulario puedo ocultarlas o mostrarlas según me convenga, pero no se
> como puedo repetir campos.
>
> Es decir lo que quiero es poder ver un campo en más de una pestaña, pero no
> parece posible porque una vez que se sitúa un campo en una pestaña desaparece
> de la lista de campos
>
> ¿Hay alguna solución?
>
> Gracias y saludos.
> Félix Durán

Lo dicho antes, gracias, pero ahora me surgen algunas cuestiones:

Hablas siempre desde el punto de vista del usuario que trabaja con el
formulario de llamada, es decir, se está creando una llamada desde el
Internet Explorer.

El problema es que las llamadas no se generan desde el IE, sino que se
generan desde una campaña, por ejemplo, a un a lista de marketing.

Supongo que con un workflow podría solucionar el relleno de campos de una
entidad personalizada, pero, ¿cómo soluciono la visualización de los datos en
función de la unidad de negocio?.

Si desde una campaña genero llamadas donde cada una de ellas tiene asociada
una entidad, una agente abrirá la llamada que le ha sido asignada y tendrá
que ver la entidad asociada, lo que nos lleva a la consulta de la unidad de
negocio.

Supongo que una solución más válida sería crear un nuevo tipo de actividad y
que este nuevo tipo fuera seleccionable como la actividad a realizar en una
campaña, igual que selecciono una llamada para la campaña y se generan
llamadas para las listas de marketing asignadas a la campaña.

Ahora, ¿es esto factible?.
Félix Durán

Hola Felix,

Hay un problema del que no me había dado cuenta (que cabeza la mía!). A las
actividades no le puedes añadir nuevas relaciones, por lo tanto no le podrías
añadir una entidad personalizada como hija de una llamada. Aun así, en el
caso de que pudieses, para que sólo usuarios de una determinada Unidad de
Negocio pudiesen verla sólo tendrías que ajustar los roles de seguridad de la
unidad de negocio en cuestión.

Otra cosa, mediante las acciones de flujo predefinidas no puedes crear
entidades que no sean notas o actividades. Con lo que tendríamos otro
problema a la hora de añadir una entidad personalizada a las llamadas. Habría
que crear algún assembly para hacer esto.

Y otro problemilla más, no puedes añadir nuevas actividades mediante
entidades personalizadas. Puedes añadir la entidad pero no tendrás la
posibilidad de que el CRM la trate como una actividad, con lo que nada de
generarla desde las campañas ni de que aparezca en la lista de actividades
del usuario.

Bien, a bote pronto se me ocurren tres soluciones. Seguir tirando por el
método no soportado de ocultar pestañas (en el form onload) y duplicar
campos. Utilizando una regla de flujo para que cuando crees la llamada (ya
sea desde una campaña o directamente) que copie los datos a los campos
personalizados, y en el onsave del formulario incluir una sincronización de
datos entre campos.

Otra solución, creo que más elegante aunque más costosa, añadir una entidad
personalizada que represente este nuevo tipo de llamadas que quieres, con una
relación jerárquica con el usuario. Así los usuarios pueden acceder desde su
área de trabajo a este tipo de llamada nuevo. Y para generalas incluir un
flujo de trabajo manual en la campaña que las genere mediante una llamada a
un assembly pásandole los parametros que se necesiten. Esta solución estaría
soportada, pero tiene un inconveniente bastante grande, no hay seguimiento de
este nuevo tipo de "actividad" desde la campaña.

Y la más sencilla (con lo que seguramente la mejor), utilizar la entidad
llamada tal cual, añadiendo los campos extras que necesitas (en una nueva
sección por ejemplo) y un campo que indique el tipo de llamada (normal o
"extra"). En el onload del formulario comprobar el tipo, si es normal
deshabilitas los campos extra (método soportado), y si es extra los
habilitas. Además puedes no incluir el campo de tipo de llamada en el
formulario o deshabilitarlo para que el usuario no tenga posibilidad de
cambiarlo. Y por último añadir una regla de flujo en el create de la llamada,
para que en caso de pertenecer el usuario al que se le asigna la llamada a la
unidad de negocio que quieres, fije el tipo de llamada a "extra" y así se
puedan utilizar esos campos adicionales. La principal ventaja de este método,
es que está totalmente soportado y que no pierdes ninguna funcionalidad
relacionada con las actividades. El inconveniente es que los usuarios que no
sean de esa unidad de negocio van a ver los campos adicionales aunque no los
puedan tocar.

Bueno, seguramente hay bastantes soluciones más. A mi ahora se me ocurren
estas, y personalmente intentaría utilizar la última por que creo que es la
menos afectaría al comportamiento de la aplicación. Ya me contarás que te
parecen, a ver si a alguien se le ocurren más que es un tema bastante
interesante.

Saludos
Marco Amoedo
PlainConcepts.com


"Félix Durán" escribió:

Lo dicho antes, gracias, pero ahora me surgen algunas cuestiones:

Hablas siempre desde el punto de vista del usuario que trabaja con el
formulario de llamada, es decir, se está creando una llamada desde el
Internet Explorer.

El problema es que las llamadas no se generan desde el IE, sino que se
generan desde una campaña, por ejemplo, a un a lista de marketing.

Supongo que con un workflow podría solucionar el relleno de campos de una
entidad personalizada, pero, ¿cómo soluciono la visualización de los datos en
función de la unidad de negocio?.

Si desde una campaña genero llamadas donde cada una de ellas tiene asociada
una entidad, una agente abrirá la llamada que le ha sido asignada y tendrá
que ver la entidad asociada, lo que nos lleva a la consulta de la unidad de
negocio.

Supongo que una solución más válida sería crear un nuevo tipo de actividad y
que este nuevo tipo fuera seleccionable como la actividad a realizar en una
campaña, igual que selecciono una llamada para la campaña y se generan
llamadas para las listas de marketing asignadas a la campaña.

Ahora, ¿es esto factible?.
Félix Durán

Otra vez gracias.

Estás siendo de gran ayuda, dada mi actual ignorancia del sistema.

Voy a contar un poco más:

Los campos que necesito introducir en la llamada son los que indican de que
modo evoluciona la llamada (cuelga, contrata, no está interesado, me llama de
todo, ...) y que me deben servir para crear de forma automática los follow up
(no tengo versión en español de momento y no se como se dice exactamente),
para descalificar el contacto (Lead) o para generar directamente una orden
y/o factura.

Obviamente este proceso es excluisvo de un proceso de call center que no
debe ser seguido, al menos de momento, por el resto de llamadas.

Lo que pretendo es que el operador no tenga que ser experto en el manejo de
CRM, sino que siga el flujo de la llamada y se vaya encontrando con con
sucesivas llamadas según el resultado de la llamada actual. El punto final,
sería la contratación del producto o la descalificación del llamado.

Lo que pretendo, sobre todo, es que los follow up se creen asignados al
mismo operador, pero con los datos rellenos. Además, cuando se llega a
contratar, el lead (¿prospección?) tiene que evolucionar a una cuenta y a un
contacto que quiero que se haga de forma automática. Por fin, si contrata,
como mínimo tendré que abrir de forma automática un formulario para recoger
los datos del usuario y poder generar la factura.

Todos estos procesos de generación de follow-up's y de creación de cuantas y
contactos quiero que sean automáticos. He pensado ponerlos en Workflows. Me
quedan dudas de como generar las oportunidades/ordenes/facturas de forma
directa, ya que es posible que tenga que abrir formularios para capturar más
datos.

Es un poco lioso, pero es lo que me gustaría hacer.

Félix Durán


"Marco Amoedo" escribió:

Hola Felix,

Hay un problema del que no me había dado cuenta (que cabeza la mía!). A las
actividades no le puedes añadir nuevas relaciones, por lo tanto no le podrías
añadir una entidad personalizada como hija de una llamada. Aun así, en el
caso de que pudieses, para que sólo usuarios de una determinada Unidad de
Negocio pudiesen verla sólo tendrías que ajustar los roles de seguridad de la
unidad de negocio en cuestión.

Otra cosa, mediante las acciones de flujo predefinidas no puedes crear
entidades que no sean notas o actividades. Con lo que tendríamos otro
problema a la hora de añadir una entidad personalizada a las llamadas. Habría
que crear algún assembly para hacer esto.

Y otro problemilla más, no puedes añadir nuevas actividades mediante
entidades personalizadas. Puedes añadir la entidad pero no tendrás la
posibilidad de que el CRM la trate como una actividad, con lo que nada de
generarla desde las campañas ni de que aparezca en la lista de actividades
del usuario.

Bien, a bote pronto se me ocurren tres soluciones. Seguir tirando por el
método no soportado de ocultar pestañas (en el form onload) y duplicar
campos. Utilizando una regla de flujo para que cuando crees la llamada (ya
sea desde una campaña o directamente) que copie los datos a los campos
personalizados, y en el onsave del formulario incluir una sincronización de
datos entre campos.

Otra solución, creo que más elegante aunque más costosa, añadir una entidad
personalizada que represente este nuevo tipo de llamadas que quieres, con una
relación jerárquica con el usuario. Así los usuarios pueden acceder desde su
área de trabajo a este tipo de llamada nuevo. Y para generalas incluir un
flujo de trabajo manual en la campaña que las genere mediante una llamada a
un assembly pásandole los parametros que se necesiten. Esta solución estaría
soportada, pero tiene un inconveniente bastante grande, no hay seguimiento de
este nuevo tipo de "actividad" desde la campaña.

Y la más sencilla (con lo que seguramente la mejor), utilizar la entidad
llamada tal cual, añadiendo los campos extras que necesitas (en una nueva
sección por ejemplo) y un campo que indique el tipo de llamada (normal o
"extra"). En el onload del formulario comprobar el tipo, si es normal
deshabilitas los campos extra (método soportado), y si es extra los
habilitas. Además puedes no incluir el campo de tipo de llamada en el
formulario o deshabilitarlo para que el usuario no tenga posibilidad de
cambiarlo. Y por último añadir una regla de flujo en el create de la llamada,
para que en caso de pertenecer el usuario al que se le asigna la llamada a la
unidad de negocio que quieres, fije el tipo de llamada a "extra" y así se
puedan utilizar esos campos adicionales. La principal ventaja de este método,
es que está totalmente soportado y que no pierdes ninguna funcionalidad
relacionada con las actividades. El inconveniente es que los usuarios que no
sean de esa unidad de negocio van a ver los campos adicionales aunque no los
puedan tocar.

Bueno, seguramente hay bastantes soluciones más. A mi ahora se me ocurren
estas, y personalmente intentaría utilizar la última por que creo que es la
menos afectaría al comportamiento de la aplicación. Ya me contarás que te
parecen, a ver si a alguien se le ocurren más que es un tema bastante
interesante.

Saludos
Marco Amoedo
PlainConcepts.com


"Félix Durán" escribió:

> Lo dicho antes, gracias, pero ahora me surgen algunas cuestiones:
>
> Hablas siempre desde el punto de vista del usuario que trabaja con el
> formulario de llamada, es decir, se está creando una llamada desde el
> Internet Explorer.
>
> El problema es que las llamadas no se generan desde el IE, sino que se
> generan desde una campaña, por ejemplo, a un a lista de marketing.
>
> Supongo que con un workflow podría solucionar el relleno de campos de una
> entidad personalizada, pero, ¿cómo soluciono la visualización de los datos en
> función de la unidad de negocio?.
>
> Si desde una campaña genero llamadas donde cada una de ellas tiene asociada
> una entidad, una agente abrirá la llamada que le ha sido asignada y tendrá
> que ver la entidad asociada, lo que nos lleva a la consulta de la unidad de
> negocio.
>
> Supongo que una solución más válida sería crear un nuevo tipo de actividad y
> que este nuevo tipo fuera seleccionable como la actividad a realizar en una
> campaña, igual que selecciono una llamada para la campaña y se generan
> llamadas para las listas de marketing asignadas a la campaña.
>
> Ahora, ¿es esto factible?.
> Félix Durán
>
>