✒️SAP SD Las modificaciones del sistema

MODIFICACIONES DEL SISTEMA

Control del registro maestro de cliente mediante grupo de cuentas

El maestro de clientes consta de:

- Los datos de ventas (segmento de ventas) que son datos básicos para Comercial y expedición.

- Los datos de sociedad (segmento de sociedad), son los datos básicos de Gestión Financiera.

- Los datos generales que se asignan directamente a los clientes. Por tanto, son válidos para diferentes sociedades, así como para las diferentes áreas de ventas. El número de cliente utilizado en Comercial es, en consecuencia, idéntico al número de cliente utilizado en Gestión Financiera.

(Gráfico 771)

Maestro de clientes - grupo de cuentas

El Grupo de cuentas es una clasificación incluida en los registros maestros de clientes.

Se informa asociado al cliente y hay varios grupos de cuentas, por ejemplo:

- 0001 Solicitante.

- 0002 Destinatario mercancías.

- 0003 Responsable de pago

- 0004 Destinatario de la factura

(Gráfico 772)

El grupo de cuentas controla:

- Los campos del registro que se establecen como obligatorias u opcionales (selección de estatus campo).

- El intervalo de números utilizado para el número de cuentas de cliente.

- Si este intervalo de números, es de asignación externa o interna de números.

- Si la cuenta es de tipo CP (cuenta pro diversos o también llamada eventual o esporádica).

- Qué esquema de determinación de mensajes utiliza.

El sistema brinda los grupos de cuentas propuestos, pero se pueden definir los propios.

Maestro de clientes - Selección de campos para grupos de datos (status campo)

El registro maestro, como se mencionó anteriormente, consta de datos para tres segmentos: general, sociedad y comercial.

(Gráfico 733)

Como se ve en el gráfico, cada segmento contiene los datos relacionados con su ámbito.

Se puede utilizar la selección de campos en cada uno de los grupos de cuentas, para determinar si las entradas de campos son opcionales u obligatorias. Los campos que no sean obligatorios se pueden ocultar.

Audio: Los estatus campo de los grupos de cuenta ayudan mucho para evitar errores en las transacciones que necesitan información de los datos maestros de clientes. Puesto que hace que al momento de crear los mismos, el usuario se encuentre con la obligación de informar estos datos. Si se desea que un campo sea obligatorio para todos los grupos de cuenta, conviene que esta obligatoriedad se indique a nivel de la transacción, donde también es posible configurar el propio status campo de la transacción.

Maestro de clientes - Selección de campos para grupos de cuentas

El sistema ya tiene predefinidos ciertos grupos de cuentas de forma estándar para las funciones de los interlocutores, como son:

- Solicitante (Grupo de cuentas 0001).

- Destinatario de mercancías (Grupo de cuentas 0002).

- Responsable de pago (Grupo de cuentas 0003).

- Destinatario de factura (Grupo de cuentas 0004).

(Gráfico 774)

Vemos en el gráfico los diferentes grupos de cuentas y los datos de información que podemos visualizar y configurar a nuestras necesidades.

Se seleccionan campos específicos para cada uno de estos grupos de cuentas. La selección de campos depende de las funciones dentro de la función obligatoria del interlocutor.

Maestro de clientes - Factores adicionales que influyen en la selección de campos

Además del grupo de cuentas, las operaciones o transacciones para crear, modificar y visualizar un registro maestro de clientes, también influyen en la selección del estatus de campo del maestro.

(Gráfico 775)

Los datos generales indican características generales del cliente.

Los datos de sociedad pueden ejercer de filtro para grupos de cuentas.

Los datos de comercial (SD) pueden ejercer de filtro para operaciones.

En SAP Easy Access existen transacciones específicas que pueden utilizarse para:

- Crear, modificar y visualizar desde la perspectiva comercial (VD01, VD02 y VD03).

- Crear, modificar y visualizar desde la perspectiva de gestión financiera (FD01, FD02 y FD03).

- Crear, modificar y visualizar desde todas las perspectivas (XD01, XD02 y XD03).

Cada una de estas transacciones puede tener distinto tratamiento en cuanto a mostrar que datos deben completarse.

Reglas de enlace para la selección de campos

La información de status de campos de los dos factores de influencia (grupo de cuenta y transacciones), se combinan en parejas al momento que se crea, trata/modifica o visualiza un registro maestro. Siempre se elige primero el estatus que posea máxima prioridad de esta combinación de influencia.

(Gráfico 776)

En el gráfico vemos como se emparejan para cada campo las configuraciones de visibilidad (visualizar u ocultar) y de obligatoriedad (obligatoria u opcional), que tiene el campo para el grupo de cuentas y para la operación o transacción.

La prioridad de los estatus es la siguiente (en este orden):

1- Ocultar.

2- Visualizar.

3- Obligatorio.

4- Opcional.

Debemos tener cuidado en la combinación resultante, porque si bien hay jerarquía de estatus, si asignamos en el grupo de cuentas que un campo es obligatorio y en la transacción que es oculto (o viceversa), esta brindará un mensaje de error por incongruencia.

Control de tablas

Durante las transacciones de creación, visualización o modificación de documentos de ventas, el layout de las columnas para la carga de los datos está determinados por el Control de tablas.

Este es un elemento de visualización que permite configurar la vista de tabla en función de los requisitos específicos de los clientes. Este elemento resulta especialmente práctico cuando la tabla contiene un buen número de campos.

(Gráfico 777)

Este control lo puede definir el usuario desde su propia vista de los datos:

- Modificando la secuencia de las columnas.

Variantes de las transacciones

El procesamiento de las transacciones puede simplificarse con las variantes de transacción o de pantallas, las cuelas pueden:

- Introducir valores predeterminados en campos.

- Ocultar y modificar el valor previsto para el status de entrada de los campos.

- Ocultar pantallas completas.

- Ocultando y comprimiendo pantallas u ocultando campos se facilita el trabajo en el sistema SAP y se obtiene una mejor visión global.

- Se crea una variante de transacción de las variantes de la pantalla.

- Se asigna una variante de transacción a una transacción. Cada transacción puede disponer de varias variantes.

- Solo se permiten las variantes de transacción para transacciones de diálogo.

- Si se ha utilizado una entrada de lotes (o un registro de entrada de lotes), el sistema no tiene en cuenta los valores de las variantes de transacción.

- Modificando el ancho de las columnas (incluso haciéndolas desaparecer).

- Grabando los parámetros como variante de la visualización.

- Definiendo una variante de visualización como configuración estándar.

De todas maneras, un administrador del sistema puede adicionalmente hacer desaparecer campos concretos para todo el sistema en el control de tablas.

La herramienta adicional GuiXT permite el diseño flexible de pantallas por separado. GuiXT utiliza un lenguaje de scripts que se ejecuta en frond-end.

Encontrará información más detallada en la página de inicio de los fabricantes de GuiXT.

Llamar a una variante de transacción utilizando la clase de documentos de ventas

En líneas generales, se llama a una variante de transacción utilizando una transacción de variante que puede incorporarse a un rol de usuario, por ejemplo.

Con las clases de documentos de ventas, una opción adicional sería asignar la variante de transacción en el customizing para la clase de documentos de ventas.

Las relaciones aparecen como resultado de esta característica especificada.

(Gráfico 779)

1.- Mediante la clase de documento de ventas, asignando una variante de transacción en el campo "Variante" mediante customizing. Por ejemplo, para la clase de documento de ventas "xy", se informa el campo Variante con ZDEMO.

2.- Para utilizara una transacción de variante como se describe en la nota 332930, es necesario asignar la entrada NO_VARIANT en el campo "variante" de la clase de documento que ha llamado.

Una Variante de transacción es una vista determinada de rol que se puede definir y asignar a una clase de documento de ventas cuando la misma es tratada.