visual ejemplos codigos vba ms-access

vba - ejemplos - Flujo de trabajo relacionado con varias tablas



codigos vba access (3)

Para solucionar el problema de los registros no vinculados, debe establecer sus campos maestros de enlace y campos secundarios de enlace en las propiedades de los subformularios. En la siguiente captura de pantalla, mi campo vinculado es SUBSCRIBER_ID, el tuyo sería ID de caso (o lo que sea el nombre real de var).

Editar: el interrogador ya hizo lo anterior, por lo que el paso está cubierto

Puede poner un cheque de VBA para identificaciones de caso nulas en su botón de Nueva llamada (o como se cree un nuevo registro de llamada / correo electrónico). Algo como esto:

If IsNull(Me.Case_ID) Then MsgBox "Before adding a call you need to create a Case ID, please do so first" Me.Undo Else [Whatever the button really does] End If

Dependiendo de dónde coloque el código, es posible que no necesite Me.Undo . Si está On Click para el botón, probablemente no lo haga. Si es antes de la actualización de la llamada / ID de correo electrónico, probablemente sí.

Con respecto al desplazamiento, en lugar de mostrar el cuadro completo de subformularios con pestañas, puede tener un botón para cada tipo de datos que muestre un formulario para esa información cuando se presione el botón. Por lo tanto, para las llamadas, debería mostrar algo parecido a lo que muestra en la parte inferior de su última captura de pantalla, sin las pestañas, en una ventana superpuesta. Desearía un botón Cerrar en el formulario emergente para volver al formulario principal.

En un rediseño de nuestro CRM, tenemos la necesidad de modularizar nuestro flujo de trabajo. Debido a las diversas actividades y campañas que procesamos, tengo la necesidad de crear una cartera maestra con una relación uno a varios para varios elementos del caso. Sin embargo, cada elemento del caso debe tener sus propios datos asociados.

El diseño actual que tengo involucra un conjunto de tablas:

  • Casos
  • Case_Calls
  • Case_Emails
  • etc ...

Tenemos alrededor de una docena de artículos diferentes en total.

Estoy tratando de encontrar una buena forma de organizar mi formulario para acomodar estos flujos de trabajo variables. El flujo de trabajo ideal podría implicar agregar múltiples elementos a un caso durante una interacción determinada, por lo que necesito una forma sensata de manejarlos en la misma forma.

Originalmente, todo fue text-templated y se agregó a un solo campo de "Texto largo". Esto hizo que sea muy difícil filtrar datos o ejecutar informes, por lo que no es muy útil para nosotros.

La siguiente iteración involucró un control de pestañas, con una pestaña diferente para cada elemento del caso. Sin embargo, esto causa problemas de comportamiento y no maneja con gracia la cantidad de tipos de elementos diferentes que estoy buscando; donde las pestañas adicionales causan una necesidad de desplazamiento horizontal que simplemente molesta a todos.

Entonces ahora estoy perdido. ¿Cómo se puede diseñar mejor para facilidad de uso?

Editar: Como se sugiere, aquí hay algunas capturas de pantalla de la iteración actual (rota):

Está roto en el sentido de que cada pestaña contiene un subformulario, pero no hay garantía de que se cree un Caso antes de que se cree el registro del subformulario. Tampoco hay una forma directa de aplicar un flujo de trabajo de solo creación de esta manera.


Tal vez deberías olvidarte por completo de tu antiguo sistema y pensar fresco.

su escenario actual que podría pensar:

Sus empleados están tomando llamadas o notas para un caso y actualmente están escribiendo en papel, Excel o su aplicación. Seguramente notan en algún lugar quién llamó y a qué hora se llamaba? ¡estos son tus puntos clave!

Como desarrollador, debe asegurarse de que los usuarios sigan el flujo de proceso correcto o que deba preparar diferentes escenarios.

En realidad, no habrá ningún correo electrónico con respecto a un "caso", si el registro del caso no existe. Al seguir esta regla, su aplicación no debe permitir el envío de correos electrónicos / tomar notas sin un registro de caso válido.

Si los detalles del caso no están disponibles en el momento en que se reciben las notas / correos electrónicos, debe crear el registro de "caso" con todos los datos disponibles que tenga. Por ejemplo, ¿ quién actuó? que fecha? Con estos datos, puede insertar el registro del caso y luego permitir que sus empleados continúen agregando notas y correos electrónicos.

asumamos:

  • Todos sus subformularios tienen valores válidos vinculados maestro-hijo
  • está abriendo su formulario de caso para agregar nuevos registros:

docmd.OpenForm "your_case_form",acNormal,,,acFormAdd

en su evento "form_load" form_load, puede verificar si el formulario está listo para ingresar nuevos detalles. algo como esto.

Private Sub Form_Load() if( Me.NewRecord) then me.txt_added_by.value = your_way_of_username me.txt_added_date.value = now() END IF End Sub

el código anterior ingresará el nombre de usuario y la marca de tiempo actual que automáticamente genera un registro de caso (suponiendo que su tabla de casos no tiene ningún campo "no nulo" y la ID es un número automático)

¡sus empleados pueden simplemente pasar a cualquier subformulario que activará automáticamente la acción de guardar para la tabla de casos y usted tiene el registro de su caso!

Antes de insertar en su subformulario, también puede verificar si el registro de padre / caso está disponible.

if (nz(me.parent!txt_case_id.value,0) =0) then ''case id not found.. ''you can advise the user to enter anything on the case section to create a record or you can use SQL to insert a record ''or you could cancel the insert, move/set focus to parent form. add datetime / username to create record end if

el punto es que debe asegurarse de crear un registro primario antes de permitir registros secundarios.


No vas a soslayar esto:

no hay garantía de que se cree un Caso antes de que se cree el registro de subformulario

Deben crear la fila del encabezado del caso antes de que puedan crear hijos relacionados. No importa si los subformularios relacionados se abren a través de una pestaña, botón o incluso una lista de tipos secundarios realmente no importa, son funcionalmente iguales.

Si realmente quieren crear hijos sin un caso, puedes crear una fila de casos de ''orfanato'' y pedirles que los agreguen allí, pero luego pedirán una forma de mover al niño del orfanato al caso que deberían haber elegido. en primer lugar.

Si este es su problema: creating a record in subform does not enforce a record in the main form. ¿Se puede deshabilitar u ocultar los subformularios hasta que se seleccione el registro de caso principal? ¿Bajo qué condiciones está obteniendo nuevas filas en formularios secundarios asignados al case 0 ? ¿Existe el Case 0 ? Si es así, eso está actuando como tu orfanato.