Select language:
Inicio del área de contenido!--a11y-->

Documentación proceso de fondo Integración de tablas nuevas en el maestro de materiales 

Utilización

Pueden incluirse tablas nuevas en la actualización del maestro materiales sin modificar los programas para el maestro de materiales.

El procedimiento para incluir campos nuevos en tablas existentes se describe en la nota 44410.

Esta documentación se basa principalmente en las posibilidades de que dispone el usuario para definir la cantidad y el aspecto de las pantallas principales y secundarias.

Condiciones previas

Debería estar familiarizado con las características principales del maestro de materiales.

Debe haber configurado el diseño de las pantallas con las parametrizaciones del Customizing en Logística general ® Maestro de materiales ® Configuración del maestro de materiales. Puede definir las secuencias de pantallas que incluyen una secuencia de las pantallas principales y secundarias. Cada secuencia de pantallas representa un formato de visualización para el maestro de materiales.

Nota

Es recomendable no modificar la secuencia de pantallas estándar para algunas tablas nuevas; es preferible modificar una copia de una secuencia adecuada de pantallas estándar y crear una secuencia de pantallas separada.

Integración

Las condiciones que difieren para integrar tablas nuevas en el maestro de materiales son las siguientes:

·  Integración parcial

Debe ser posible actualizar los datos desde el maestro de materiales. El usuario debe poder reconocer, por la clase de integración, que en este caso se trata de un objeto separado; el usuario no debe esperar las mismas características para los datos integrados que para los datos maestros de material (como la selección de campos y el tratamiento de modelos). La integración debería conllevar una sola simplificación de actualización para el usuario.

·  Integración completa

El usuario no debe reconocer que se trata de una tabla del maestro de materiales. Por lo tanto, la integración es invisible al usuario y la única diferencia técnica es la conexión (como una tabla separada del maestro de materiales). Por consiguiente, todas las funciones de actualización que están disponibles para los datos maestros de material también están disponibles para los datos integrados.

En principio, se selecciona la integración parcial para datos que no tienen que actualizarse urgentemente para cada material, para los datos adicionales y para datos que no tienen que visualizarse urgentemente como parte del maestro de materiales, por ejemplo las versiones de producción de un material.

La integración completa se selecciona para datos que tienen que actualizarse para todos los materiales o una gran cantidad de ellos, para los datos que se visualizan en tablas normales del maestro de materiales (sin datos adicionales) y para datos que parecen iguales que otros datos maestros de material, por ejemplo para grupos de necesidades de un material (sólo disponible en el entorno de comercio minorista).

Implementación

Debido a las diferentes condiciones de integración, también hay diferentes vías de implementación:

·  Implementación para la integración parcial.

Para la integración parcial, sólo puede actualizarse una tabla nueva en la misma pantalla (pantalla secundaria). La pantalla en la que se actualizan los datos nuevos tiene su propio status GUI y, por lo tanto, es distinta de las pantallas del maestro de materiales tanto en las funciones de la barra de menús como en los pulsadores disponibles. En concreto, no puede pasar directamente de esta pantalla a otras pantallas del maestro de materiales y no puede definir la pantalla como pantalla principal propia o como una subpantalla en una pantalla principal ya existente. Además, es posible que no todas las funciones de actualización para los datos integrados estén disponibles.
La pantalla secundaria se abre mediante el menú Detalles o con un pulsador.

·  Implementación para la integración completa.

Para la integración completa, puede implementar la actualización de las tablas nuevas del mismo modo que para las tablas del maestro de materiales:

¡  Subpantalla (subscreen) en una pantalla principal existente o pantalla adicional.
Pantalla principal propia.

-  Pantalla adicional que sólo puede seleccionarse con el menú Detalles.

-  Pantalla adicional que se abre seleccionando un pulsador (y puede seleccionarse con el menú Detalles).
El mismo status GUI se utiliza para las pantallas del maestro de materiales.

La integración parcial es más simple que la integración completa. Además, hay algunas limitaciones para la integración completa:

Nota

La ampliación del maestro de materiales debería ser sustantiva. No se trata de registrar uno o dos campos en una subpantalla existente.

Esta documentación describe únicamente la integración de tablas de material nuevas desde el punto de vista de la actualización de datos de material. La utilización y el tratamiento de los datos registrados de esta forma en procesos operativos requieren un concepto separado.

El control de selección de campos en el maestro de materiales no se puede ampliar para tablas adicionales. Debe implementarse una selección de campos separada.

El usuario puede decidir si para el tratamiento de modelos debe proponerse el campo desde el material modelo. Este campo se actualiza mediante una transacción del Customizing que se guarda en la tabla T130F. El tratamiento de modelos también tiene que implementarse aquí.

Campos clave en tablas nuevas
Las tablas nuevas suelen tener una clave que no concuerda con la clave de una tabla de material existente (de lo contrario, la integración funcionaría registrando campos nuevos en una tabla existente del maestro de materiales).
Si debe actualizar las claves para los registros de datos en pantallas separadas, lo que significa que tiene que pasar a los diferentes registros de datos modificando el nivel de organización, por norma general podrá realizar únicamente la integración parcial. La integración completa de nuevos campos clave no se soporta en la actualización del maestro de materiales.

El registro de un nuevo status de actualización no es posible debido a la integración de objetos nuevos en el maestro de materiales. Los objetos nuevos deben añadirse a un status de material existente.

 

Integración completa

A continuación se describe el procedimiento para la integración completa, y sólo se hace referencia a la integración parcial si es relevante.

El método BAdI BADI_MATERIAL_OD está disponible para la integración de objetos nuevos, desde los cuales se puede acceder a los módulos de funciones específicos de la aplicación para los objetos integrados. Los métodos BAdI preparan los datos necesarios que el módulo de aplicaciones requiere en cada situación. Esto significa que la integración puede realizarse de manera que los datos integrados no tengan que reconocerse en el maestro de materiales. La lógica global y los datos asociados se encuentran en los módulos de funciones específicos de la aplicación.

Para la integración parcial sólo se necesita parte de los métodos BAdI existentes. Algunos métodos BAdI sólo son relevantes para la integración en el entorno de comercio (con la terminación _RT) y otros para el maestro de materiales en el entorno industrial y comercial.

Como ejemplo de integración, se llevan a cabo aquéllos que pertenecen a grupos de necesidades integrados en comercio (grupo de funciones WRPP). Estos datos se actualizan en el nivel de material (todos los grupos de necesidades para un material se actualizan en una pantalla). Como ejemplo de integración de datos en el nivel de material/centro se utilizan los parámetros de control de reaprovisionamiento implementados en comercio (grupo de funciones WRPL), mientras que los datos de centros en el maestro de materiales deben explicar el problema de los centros de referencia incluso durante la integración (en comparación con el punto para tratamiento de modelos). Los subscreen para ambas tablas de base de datos (WRPP y WRPL) se encuentran en el grupo de funciones WRPD.

 

Creación de un marco

El desarrollo de la pantalla es análogo a la inclusión de nuevos campos en las tablas existentes de un grupo de funciones separado. Los includes relevantes para el maestro de materiales están incluidos en este grupo de funciones (inclusión en el programa de control, no una copia), para que las rutinas necesarias para la obtención de datos puedan ejecutarse desde la pantalla. Para los grupos de necesidades, la clase de desarrollo es WRPL y el grupo de funciones es WRPD.

El grupo de funciones también debe incluir un módulo de función especial para la inicialización. Con este módulo de funciones, los parámetros de control centrales se leen en cada entrada para el grupo de funciones. El módulo tiene el prefijo fijo INIT_, seguido por el nombre del grupo de funciones. Véase INIT_WRPL. El módulo no tiene parámetros y consiste sólo en una línea.

perform init_baustein.

La rutina FORM está definida en un include estándar en el maestro de materiales.

A partir del release 3.1, la creación del grupo de funciones puede realizarse con la ayuda del programa COPYMGD1 (un parámetro controla si se debe crear un grupo de funciones para un maestro de materiales del ramo o de comercio). El programa de control, el módulo de funciones e incluso una pantalla modelo se crean automáticamente de este modo.

Lógica de pantalla

Dentro del grupo de funciones pueden desarrollarse normalmente pantallas con lógica PBO y PAI. No hay que prestar especial atención a una numeración determinada. Para el desarrollo hay que tener en cuenta los siguientes puntos:

General

-  Cada pantalla debe definirse como una subpantalla. Véase el atributo de dynpro de 1000/WRPD. Puede crear varias subpantallas dentro del grupo de funciones (por ejemplo, para campos de cabecera y campos de datos).

-  Los módulos que se hallan en la lógica de procesos para la pantalla estándar, o también en las pantallas modelo, deben utilizarse como modelos en lo que concierne a las características.  Si tiene que crear pantallas de cabecera nuevas (pantalla con campos clave), debería hacerlo modificando una copia de una pantalla existente. Los módulos ofrecen sugerencias sobre las características que deben o pueden existir en la pantalla. Algunos de los módulos incluidos también deben estar disponibles en la subpantalla (véase más adelante). El usuario desarrolla módulos correspondientes para terceros para una aplicación individual. Más adelante se describe detalladamente la lógica de procesos para los módulos.

-  Si visualiza campos con el texto correspondiente en las pantallas nuevas (como grupos de artículos y las descripciones correspondientes), es para asegurar que, al suprimir el campo de datos (por ejemplo, en la selección de campos), se suprima también el texto correspondiente. Si describe un grupo de modificación 1 para ambos campos relacionados, con Fn y Tn, n = 01, 02, 03, etc., el módulo estándar FAUSW_BEZEICHNUNGEN ejecutará automáticamente esta tarea.
Para un ejemplo, véase la pantalla 2000/WRPD.

-  Un material está formateado para una actividad determinada en la actualización del maestro de materiales: el material se crea de nuevo (se amplía en el maestro de materiales del ramo) o se modifica, o bien se visualizan sus datos sin posibilidad de modificarlos. El tipo de actividad se deriva de la combinación de los dos campos T130M-AKTYP y NEUFLAG (véase INCLUDE MMGXV01 para obtener la definición de los diferentes tipos de actividad). Está definido globalmente dentro del grupo de funciones.

En el maestro de materiales del ramo hay una diferencia entre los tipos de actividad H = añadir y V = modificar (se puede modificar un material – MM02 – o añadir o crear pantallas nuevas – MM01). En el maestro de materiales de comercio, hay una diferencia entre los tipos de actividad N = crear material nuevo y C = actualizar material (se puede crear un material de nuevo – MM41 – o se puede actualizar, es decir, modificar o ampliar – MM42). Para que la misma lógica del programa también se pueda utilizar para el maestro de materiales de comercio (el tipo de actividad se pregunta en momentos diferentes), el tipo de actividad se ajusta en H, en los casos N y C, en el maestro de materiales de comercio después del proceso de la pantalla inicial (no se puede ver si se ha modificado o añadido en el maestro de materiales de comercio; LMGMWFO0, OKCODE_BILD_RETAIL). Si para un nivel de organización determinado debe decidir si se trata de modificar o de añadir, debe decidirse mediante la tabla interna PTAB_FULL y el correspondiente RCODE.

Acceso de lectura, grabación de datos en memoria intermedia y transporte de datos

Los datos sólo deberían leerse de la base de datos una vez por transacción para una clave determinada; si se desea llamarlos de nuevo es preferible utilizar la memoria intermedia. El acceso de lectura debe guardarse en módulos de acceso individual. El acceso para la rutina de lectura debe incluirse en el método BAdI READ_OTHER_MATERIAL_DATA.

Puede pasar a los módulos de funciones para los grupos de necesidades o a los parámetros de reaprovisionamiento para la creación de módulos de acceso (grupo de funciones WRPPB para acceder a la tabla WRPP, grupo de funciones WRPLB para acceder a la tabla WRPL). Los módulos para ambos grupos de funciones se crean según los modelos para módulos de acceso del maestro de materiales (hay un grupo de funciones para cada tabla que contiene todos los módulos de acceso).

La propiedad del maestro de materiales que permite personalizarlo a cada cliente se basa en principio en el concepto de grabar los datos en memoria intermedia y de transportar datos entre subpantallas que pueden pertenecer a programas diferentes. Este concepto puede describirse sucintamente del modo siguiente:

·  La autorización se verifica antes de leer de la base de datos.

·  La base de datos lee los datos de una vez (fijando los bloqueos necesarios en este momento) y los graba en memoria intermedia para cada tabla en un grupo de funciones individual.

·  Para el PBO de un contenedor de pantallas, los datos relevantes para la pantalla se leen de la memoria intermedia para cada grupo de funciones y se fijan en una memoria intermedia (área de trabajo) (estructuras U).
p. ej.
MARA_GET_BILD, MARM_GET_BILD

·  Para el PBO de una subpantalla, los datos relevantes para la subpantalla se leen de la memoria intermedia, de modo que los datos pueden visualizarse en la pantalla.
p. ej.
MARA_GET_SUB, MARM_GET_SUB

·  Los datos se modifican de acuerdo con las entradas realizadas por el usuario y, a continuación, el programa las verifica. Los datos verificados se devuelven a la memoria intermedia para cada subpantalla.
p. ej.
MARA_SET_SUB, MARM_SET_SUB

·  Si se han ejecutado todas las subpantallas de una pantalla y se ha verificado la consistencia de los datos, los datos del área de trabajo se devuelven a la memoria intermedia.
p. ej.
MARA_SET_BILD, MARM_SET_BILD

·  El status de la base de datos se conserva básicamente en la memoria intermedia (status I). El último status consistente antes de la siguiente modificación consistente también se guarda en la memoria intermedia (status L). Al iniciar la transacción, el status L coincide con el status I. Estos status suelen utilizarse para verificaciones y el status de la base de datos también es necesario para determinar si se han producido las modificaciones.

Por razones de características consistentes, el mismo concepto para las tablas a integrar se debe seleccionar respecto de la grabación de datos en memoria intermedia y del transporte de datos. En el método BAdI GET_OTHER_MATERIAL_DATA_BILD, se llama para los nuevos datos el módulo de funciones correspondiente para capturar pantallas, que prepara los datos para la pantalla del área de trabajo. Los datos verificados se devuelven a la memoria intermedia desde el área de trabajo en el método BAdI SET_OTHER_MATERIAL_DATA_BILD.

Los módulos de funciones XXXX_GET_SUB y XXXX_SET_SUB sólo se llaman para subpantallas que deben incluirse de nuevo. La llamada requiere la disponibilidad y la declaración de las tablas correspondientes.

Verificación de datos

Los datos deberían verificarse en PAI. Si las rutinas de verificación devuelven una falta de consistencia en los datos, no salga de la pantalla. El usuario debe corregir sus entradas. Si utiliza mensajes E para emitir mensajes de error, el sistema asegura que no pueda salir de la pantalla hasta que no se haya corregido el error.

Sin embargo, cuando se utilizan subpantallas, no siempre es bueno emitir mensajes E para errores. Emita mensajes de error como mensajes S, mejor que mensajes de error reales (mensajes E), si los campos de diferentes subpantallas pueden quedar afectados por una corrección o si se trata de una pantalla step loop. El usuario todavía puede modificar todos los campos y no queda restringido al campo retirado por un mensaje E. Para evitar que salga de la pantalla de todas formas, la variable global BILDFLAG debe estar fijada en X en caso de errores.  De esta forma no es posible pasar a otra pantalla. Tan pronto como el sistema acepte los datos, debe dejarse el campo BILDFLAG en blanco.

Esto también puede suceder con mensajes de advertencia (no todos los campos afectados están en una subpantalla). En este caso, también debe emitir el mensaje como un mensaje S, pero además la lógica de aviso que suele proporcionar el sistema (se puede confirmar un aviso, lo que le permite salir de la pantalla) debe estar programada del modo correspondiente. (Utilice un indicador para asegurar que el aviso sólo se produce una vez si no se modifica la entrada. Tenga en cuenta que el aviso debe emitirse otra vez si entretanto se modifican los datos.)

Ejemplo

Compare el procedimiento en el grupo de funciones MGD1, módulo PAI MARC-DISMM-FXHOR.

 

Las verificaciones deberían implementarse siempre como módulos de funciones, porque vuelven a llamarse después de grabar en la lógica de contabilización. Al crear módulos de verificación para verificar entradas, recuerde que:

·  Un módulo de verificación debe crear mensajes para errores y avisos.

·  Si hay un error, debe salirse del módulo con un mensaje emergente.

Códigos de función

En PAI, las acciones del usuario se verifican mediante un código de función. Estos códigos de función se direccionan en el programa real, utilizando constantes con una definición global. La convención para fijar nombres constantes es FCODE_<nombre del código de función>. La definición de estas constantes se realiza en un fichero include separado (véase WRPP_FCODES).
Para asegurar la univocidad del código de función, debería comprender el nombre de su propio grupo de funciones y un nombre clave de función definida por el usuario.

 

El código de función es un elemento de la estructura RMMZU y se puede llamar como RMMZU-OKCODE.

 

Si la nueva subpantalla contiene una pantalla step loop con sus propios códigos de función para el desplazamiento (nota: los códigos de función para el desplazamiento deben ser unívocos, igual que cualquier otro código de función), la aplicación debe anular la variable BILDFLAG después de haber procesado el código de función, de lo contrario se saltará a la pantalla siguiente.

 

Módulos PBO

Los módulos siguientes son estándar en la lógica PBO de una subpantalla.

·  MÓDULO INIT_SUB

Inicialización: debe estar siempre presente.

·  MÓDULO GET_DATEN_SUB

La captura de los datos maestros de material desde las memorias intermedias (área de trabajo): debe estar siempre presente.

·  MÓDULO FELDAUSWAHL

Selección de campos para campos del maestro de materiales (T130F).

·  MÓDULO SONDERFAUS

Selección especial de campos del maestro de materiales.

·  MÓDULO SONDERFAUSW_IN_FGRUPPEN

Selección especial de campos con un grupo de campos especial.

·  MÓDULO FAUSW_BEZEICHNUNGEN

Selección de campos para descripciones (si se suprime un campo de datos, se debe suprimir la descripción). 

·  MÓDULO BILDSTATUS

Establece el status de la pantalla.

·  MÓDULO FELDHISTORIE

Gestión de modificaciones (desactivado).

·  MÓDULO ZUREF_VORSCHLAGEN_B
(ramo) 

Tratamiento por defecto para campos del maestro de materiales en la solución sectorial.

·  MÓDULO REFDATEN_VORSCHLAGEN

Tratamiento por defecto para campos del maestro de materiales en la solución sectorial.

·  MÓDULO ZUREF_VORSCHLAGEN_A
(ramo)

Tratamiento por defecto para campos del maestro de materiales en la solución sectorial.

·  MÓDULO BEZEICHNUNGEN_LESEN

Lee descripciones de campos de datos.

·  MÓDULO BEZEICHNUNGEN_LESEN_RT
(sólo comercio)

Tratamiento por defecto para campos del maestro de materiales en la solución comercial.

·  MÓDULO SET_DATEN_SUB

Devolución de datos maestros de material a la memoria intermedia (área de trabajo).

 Los módulos para el aprovisionamiento de datos y la devolución de datos a la memoria intermedia (GET_DATEN_SUB, SET_DATEN_SUB) deben estar siempre presentes. También proporcionan el transporte de datos de material entre diferentes grupos de funciones.


La llamada del módulo GET_DATEN_SUBimplica que todos los datos maestros de material que están registrados actualmente están disponibles.  Por ejemplo, se puede acceder a todos los datos básicos utilizando MARA-<Feldname>. Si hay que utilizar el status actual de la combinación de clave existente para un material, estos datos deben utilizarse siempre (tal vez los datos de las "últimas" memorias intermedias no tienen el status actual). Sin embargo, si se necesitan los datos de material para un nivel de organización distinto al actual (RMMG1), estos datos no pueden especificarse con los módulos de funciones existentes para el maestro de materiales (véase grupos de funciones en el paquete MAG o MGW, como MG21 para acceder a la tabla MARA). Si hay que visualizar los datos maestros de material para unas claves distintas a la actual, tenga en cuenta que deben verificarse las autorizaciones correspondientes (esto sólo es relevante para el maestro de materiales del ramo, no para el maestro de materiales de comercio). Por ejemplo, si quiere visualizar datos maestros de material para un centro distinto al actual, primero debe verificar la autorización para este centro.

 

Tratamiento de modelos

Los módulos para el tratamiento de modelos sólo están en cada subpantalla del ramo. Para comercio, el módulo sólo aparece en subpantallas de cabecera (subpantallas con campos clave), porque la lógica de modelo funciona una vez por pantalla, no por subpantalla. Para tablas específicas del cliente, también debe programarse una lógica predeterminada, basada en la lógica del maestro de materiales del ramo o en la lógica diferente del maestro de materiales de comercio. La lógica predeterminada para la tabla a integrar debería integrarse como un módulo de funciones, porque en este caso se crea un valor fijo incluso si la subpantalla no se procesa y, en este caso, esta lógica debe ejecutarse en la lógica de contabilización.

En el tratamiento por defecto para tablas nuevas, tenga en cuenta que el valor fijo para una tabla (o la tabla y el status de actualización) sólo se ejecuta una vez al crear los datos por primera vez. No debe sobrescribir modificaciones hechas por el usuario.

Para cada campo, puede controlar si el campo se copia desde el modelo (T130F-KZREF). Si este control se necesita para campos nuevos o integrados que se deben insertar, hay que proporcionar el control correspondiente (véase lista negativa).

Para el maestro de materiales de comercio, llame el módulo de funciones para la lógica predeterminada de objetos integrados en el método BAdI MATERIAL_REFERENCE_OTHER_DATA_RT.
Ejemplo: véase el módulo por defecto para los grupos de necesidades WRPP_GET_REFERENCE y para parámetros de control de reaprovisionamiento WRPL_GET_REFERENCE.

En el método BAdI MATERIAL_PREPARE_POSTING_OD pueden realizarse verificaciones relevantes antes de la contabilización y pueden añadirse todos los datos por defecto a (por ejemplo, si la pantalla no se procesó explícitamente y, por lo tanto, no se crearon datos por defecto).
Ejemplo: WRPP_PREPARE_POSTING y WRPL_PREPARE_POSTING.

Módulos PAI

Los módulos siguientes son estándar en la lógica PAI de una subpantalla.

·  MÓDULO GET_DATEN_SUB

Aprovisionamiento de datos maestros de material desde memorias intermedias (área de trabajo).

·  MÓDULO SET_DATEN_SUB

Devolución de datos maestros de material a la memoria intermedia (área de trabajo).

Para cada campo de la pantalla debe haber una instrucción de campo, porque de lo contrario no se realizaría ningún transporte de datos (nota: las instrucciones de campo deben realizarse después de llamar GET_DATEN_SUB. Es posible que tenga que insertar rutinas de verificación para verificar entradas en PAI.

 

Herencia de datos (actualización en masa) y tratamiento de desviaciones

En el maestro de materiales de comercio (no en el maestro de materiales del ramo) hay una actualización en masa en la que los datos de un material pueden actualizarse simultáneamente para varios niveles de organización (como centros). También hay materiales genéricos con variantes subordinadas, y los datos actualizados al nivel del material genérico se heredan automáticamente a todas las variantes. Los datos de un nivel superior sólo se heredan a niveles subordinados relacionados si el nivel subordinado no se actualiza de otro modo.

Para registrar desviaciones se actualizan "punteros de desviación" (tabla MABW). Estos punteros muestran si existe una desviación para un modelo y están escritos para todas las clases de nivel de organización (véase la tabla MABW).
Ejemplo: los datos de ventas de una variante (nivel de cadena de distribución) se han actualizado de una forma distinta a la del material genérico. Se escribe un puntero de desviación para la variante y la cadena de distribución. Los datos también se heredan si hay una desviación, pero sólo para los campos que no se han actualizado de otra forma.

Las desviaciones se pueden visualizar utilizando un pulsador (para una pantalla específica y, por lo tanto, un nivel de organización).

La funcionalidad de la actualización en masa también debe estar soportada para objetos nuevos en el registro maestro de comercio. Para ello, debe crearse un módulo de funciones apropiado, al que se trasladen los campos clave actuales y que verifique a continuación si se deben heredar los datos (por ejemplo de un material genérico a una variante) y si se deben adaptar los datos dependientes en la memoria intermedia (los datos actuales se pueden tomar de la memoria intermedia). El módulo de funciones debe llamarse en el método BAdI MATERIAL_REFCHANGE_OTHER_DATA.

Ejemplo

WRPP_REFCHANGE y WRPL_REFCHANGE.

Los datos importados recientemente por un cambio de validez (y que, por lo tanto, no estaban en la memoria intermedia en el momento de heredar los datos) también deben volver a importarse y adaptarse a cualquier modificación. Ejemplo: los datos de centros dependientes se adaptan a los datos del centro modelo. Sólo se adaptan los centros que tienen datos en la memoria intermedia, todos los demás no se adaptan hasta la contabilización. Si se han importado datos para un centro que no estaba en la memoria intermedia, los datos para este centro se deben adaptar al centro modelo. El módulo de funciones correspondiente debe ejecutar esta lógica para crear el valor propuesto (diferencia entre generar un valor propuesto y heredar datos).


Ejemplo

WRPP_GET_REFERENCE y WRPL_GET_REFERENCE

 

Si el nivel en el que se actualizan los datos nuevos pertenece a un nivel existente en el que se escriben las desviaciones, los datos nuevos deben integrarse en la lógica del puntero de desviación. Para ello, debe implementarse un módulo de funciones que se llama en el método BAdI MATERIAL_GET_DIFFERENCES_OD_RT y que indica si hay una desviación para los datos que se acaban de actualizar (memoria intermedia) y, en caso afirmativo, en qué nivel.


Ejemplo

WRPP_GET_DIFFERENCES, WRPL_GET_DIFFERENCES

 

Para visualizar razones de desviación, también se necesita un módulo de funciones que se llama en el método BAdI MATERIAL_DIFFMAINT_ORGLEVS_OD y que devuelve los campos en los que hay una desviación.

Ejemplo

WRPP_GET_DIFFMAINT_ORGLEVSy WRPL_GET_DIFFMAINT_ORGLEVS.

Si el nivel en el que se actualizan los datos nuevos no pertenece a un nivel existente en el que se escriben las desviaciones, la aplicación debe escribir y visualizar su propio puntero de desviación.

Lógica de contabilización

Se requieren tres funciones para contabilizar datos:

·  Un módulo de funciones para verificar si los datos se han modificado en la transacción. Este módulo no sólo se ejecuta al realizar la contabilización, sino también para decidir si debe mostrarse una consulta de seguridad (en cuanto se hayan procesado todas las pantallas). El módulo de funciones se llama en el método BAdI CHANGE_CHECK_OTHER_MAT_DATA.
Ejemplo: WRPP_CHANGE_CHECK_1.

·  Un módulo de funciones para determinar de forma detallada qué modificaciones de la base de datos se deben actualizar (inserciones, actualizaciones, borrados). El módulo de funciones se llama en el método BAdI CHANGE_CHECK_OTHER_MAT_DATA (en este caso, el indicador P_CHANGE_CHECK_2 = X está fijado).
Ejemplo: WRPP_CHANGE_CHECK_2.
Primero se llama el módulo de funciones SET_IWRPP_TWRPP, que establece el status lógico de la base de datos (status I) y el status real de la base de datos (status O). (Esto es indispensable para que CHANGE_CHECK funcione correctamente.)

·  Un módulo de funciones para actualizar físicamente los datos. Esta función sólo se llama si el método BAdI CHANGE_CHECK_OTHER_MAT_DATA ha registrado una modificación. El módulo de funciones contabiliza los datos modificados IN UPDATE TASK. El módulo de funciones se llama en el método BAdI MATERIAL_POST_OTHER_DATA.
Ejemplo: WRPP_START_POSTING llama el módulo de funciones WRPP_POST IN UPDATE TASK.

 

Los módulos de funciones pueden leer los datos necesarios desde las memorias intermedias del grupo de funciones.

Nota

En cuanto las funciones para actualizar el status de la base de datos se hayan ejecutado en el maestro de materiales de comercio (por ejemplo, SET_IMARA_TMARA), ya no pueden cargarse más datos a la memoria intermedia del maestro de materiales, porque la verificación de cambios lo interpretaría incorrectamente como si debieran crearse. La memoria intermedia del maestro de materiales no debe modificarse en el módulo de verificación ni en el módulo de actualización (al importar datos nuevos no se proporciona el status lógico de la base de datos y los registros se interpretan como si debieran crearse).

Customizing

Tiene las opciones siguientes para integrar el registro maestro de materiales en la interfase de usuario de actualización.

·  Subpantalla (subscreen) en una pantalla principal existente o pantalla adicional.

·  Pantalla principal propia.

·  Pantalla adicional que sólo puede seleccionarse con el menú Detalles.

·  Pantalla adicional que puede abrirse con un pulsador.

Las parametrizaciones necesarias del Customizing para integrar subpantallas nuevas en el maestro de materiales se definen en la transacción OMT3.

Si quiere incluir subpantallas nuevas en una pantalla principal o adicional existente, verifique si hay espacio. Pase a la representación individual de la pantalla: si aparece una subpantalla con el número 0001 (dummy), se puede sustituir por una subpantalla nueva en el grupo de funciones relevante. Si no hay ninguna subpantalla libre en la pantalla, debe verificar si se puede modificar el dynpro contenedor (el dynpro contenedor contiene un número determinado de reservas-espacio para insertar subpantallas). Los dynpro contenedores para maestros de materiales del ramo están en el grupo de funciones MGMM, y los del maestro de materiales de comercio están en el grupo de funciones MGMW.

La decisión de incluir una pantalla nueva como una pantalla principal o adicional se toma al crear una pantalla nueva, cuando se fija el tipo de pantalla. Si es una pantalla principal, se puede definir la secuencia de pantallas principales. Si es una pantalla adicional, puede decidir si llamarla seleccionando un pulsador o el menú Detalles. En principio, el menú Detalles sólo debería contener funciones relevantes para todas las pantallas. Todas las demás deberían implementarse como pulsadores.

Si se llama desde el menú Detalles, se asigna automáticamente el código de función ZUXX a la pantalla adicional. Igual que para la pantalla principal, se puede definir la secuencia en la que las pantallas adicionales aparecen en el menú.
Si se llama desde un pulsador, el código de función debe asignarse a la pantalla adicional. El pulsador debe colocarse en alguna pantalla nueva o existente, dentro del mismo grupo de funciones, como un campo nuevo.  Los códigos de función del pulsador deben comenzar con PB y ser unívocos. PB9* está reservado para pulsadores de cliente. El nombre del pulsador debería incluir el string PUSH.

Para cada pantalla adicional, debería crear una rutina OKCODE, independientemente de si la pantalla se llama como una pantalla adicional en la secuencia o mediante un pulsador. La rutina OKCODE debe implementarse en el mismo grupo de funciones. Para llamar la rutina OKCODE, utilice el método BAdI SET_PROGRAM_FOR_OKCODE_ROUTN para que el control de proceso del maestro de materiales conozca el nombre de su propio programa.

La rutina OKCODE está asignada a la pantalla adicional en OMT3. Para una integración completa, la rutina OKCODE sólo incluye la verificación de si los datos integrados se pueden actualizar (véase más adelante).

Atención

El usuario puede modificar la parametrización estándar (pantalla adicional o pulsador) en cualquier momento utilizando OMT3 (es posible que tenga que definir su propio pulsador en una subpantalla específica del cliente y asignar el código de función de pulsador a la pantalla adicional). La rutina OKCODE asignada a la pantalla adicional asegura siempre que la verificación necesaria se ejecute al llamar la pantalla adicional. Si el usuario no quiere ver determinados pulsadores en la actualización, debe borrar las subpantallas (con el pulsador) desde la secuencia de pantallas o crear sus propias subpantallas sin pulsadores.

Las opciones de control del usuario significan que no debe programar en los códigos de función de pantallas adicionales o pulsadores.

Excepcionalmente, se puede llamar una pantalla adicional tanto desde un pulsador como desde el menú (valores de consumo, por ejemplo).

 

Para verificar si se pueden actualizar los datos integrados debe crearse un módulo de verificación. Este módulo se utiliza en varios lugares:

·  Dentro del módulo para la selección de campos, para decidir si suprimir los datos nuevos.

·  Al seleccionar el pulsador, para decidir si suprimir el pulsador.
Si el pulsador sólo es visible cuando una tabla determinada del maestro de materiales es relevante para la pantalla, el nombre del pulsador debería empezar con el nombre de la tabla (por ejemplo, MARC_QM_PUSH). A continuación, el pulsador se suprime automáticamente cuando la tabla no es relevante.

·  Al seleccionar una opción de menú, para decidir si poner la opción de menú en gris. Se llama en el método BAdI PF_STATUS_SETZEN.

·  En la rutina OKCODE de la pantalla adicional.

Integración parcial

Con la integración parcial sólo puede actualizar una tabla nueva en su propia pantalla secundaria. Puede abrir la pantalla secundaria desde el menú Detalles o seleccionando un pulsador.

A diferencia de la integración completa, estas pantallas secundarias no se asignan a las subpantallas utilizando OMT3. La pantalla que aparece cuando se llama la pantalla secundaria es unapantalla fija, cuya visualización no puede modificarse. La pantalla tiene su propio status GUI, que es diferente al status GUI de las pantallas del maestro de materiales. Por consiguiente, no es posible pasar directamente a otras pantallas del maestro de materiales desde esta pantalla.

La implementación de estas pantallas secundarias está, técnicamente hablando, completamente encapsulada. La pantalla se llama mediante la rutina OKCODE que se asigna a la pantalla.

Creación de un marco

Para la integración parcial, igual que para la integración completa, las pantallas necesarias y las funciones correspondientes se desarrollan en un grupo de funciones separado. Sin embargo, no hay ninguna condición especial para este grupo de funciones, a diferencia de la integración completa.

Lógica de pantalla

Recomendamos atenerse lo máximo posible al procedimiento y a la funcionalidad del maestro de materiales, a pesar de la encapsulación incluida en la integración parcial.

Los puntos principales para la lógica de pantalla se describen a continuación de forma resumida:

·  Puede utilizar sus propias rutinas para recuperar y grabar datos en memoria intermedia. Sin embargo, debe mantenerse en los puntos del concepto descrito anteriormente, como leer los datos sólo una vez desde la base de datos y hacerlo después desde las memorias intermedias.

·  Si hay que acceder a tablas del maestro de materiales, utilice los módulos de funciones del maestro de materiales (véanse los grupos de funciones en el paquete MGA o MGW, como MG21 para acceder a la tabla MARA). Si hay que visualizar datos, tendrá que tener en cuenta las autorizaciones relevantes.

·  También es recomendable utilizar sus propios módulos de funciones para verificar datos.

·  No hay ninguna condición para códigos de función de pantallas secundarias.

·  La aplicación determina si se requiere una selección de campos.

·  La aplicación también determina si se requiere el tratamiento de modelos.

·  La aplicación también debe determinar si es necesario heredar datos (actualización en masa) y, por lo tanto, tratar desviaciones.

Lógica de contabilización

El mismo principio de la integración completa también es válido para la lógica de contabilización. Sólo necesita su propio módulo de funciones para la contabilización si ésta no se inicia mediante "Efectuar en commit". Sin embargo, en este caso recomendamos que busque la modificación utilizando su propio módulo de funciones (CHANGE_CHECK).

Customizing

Lo anterior también es válido para las opciones OMT3. Sin embargo, con la integración parcial sólo puede implementar una integración como su propia pantalla secundaria.

 

Transferencia de datos / distribución de datos

Para transferir y distribuir los datos de material nuevos se utiliza ALE y los IDOCs relevantes (a partir R/3 4.0A, utilizando BAPIs). La aplicación debe crear los IDOCs necesarios y las funciones para crear, contabilizar y enviar manualmente los IDOCs. La aplicación también tiene que tratar las parametrizaciones necesarias del Customizing ALE (punteros de modificación, etc.).

La serialización de clases de mensaje mediante ALE garantiza que la contabilización se realice en la secuencia correcta en el sistema destino (primero el material y después los objetos dependientes). Hay que definir parametrizaciones del Customizing al respecto.

Para enviar manualmente los datos de material, necesita un módulo de funciones al que se pueda transferir una lista de materiales. Este módulo de funciones debe haber creado los IDOCs relevantes. Este módulo de funciones debe integrarse en el método BAdI MG_IDOC_CREATE_FULL_MAT (para el ramo) o MG_IDOC_CREATE_FULL_ART (para comercio) y se llama cuando debe enviarse un material completo.

 

Reorganización o suspensión y archivo, peticiones de borrado

La reorganización o la suspensión de datos integrados utiliza los módulos de funciones relevantes en los programas de reorganización del maestro de materiales. Para ello, necesita los módulos de funciones siguientes para las tablas que quiere integrar:

·  Un módulo de verificación para verificar si los datos relevantes todavía existen para el material y/o si estos datos se pueden reorganizar (quizás querrá verificar si hay peticiones de borrado). Este módulo de funciones se llama mediante la reorganización de material (ramo) o suspensión (comercio). El material sólo se puede reorganizar si no existen más datos dependientes para el material. Este módulo es opcional y sólo se requiere si necesita una verificación de esta clase para el objeto.

·  Un módulo para archivar los datos integrados.

·  Un módulo para borrar físicamente los datos.

Puede utilizar métodos de BAdI BADI_MM_MATNR para ello. Para más información, véase la documentación sobre el BAdI.

Si necesita sus propias peticiones de borrado en el nivel de datos integrado, debe proporcionar una función para fijar peticiones de borrado. Las peticiones de borrado al nivel de material se heredan a los objetos dependientes. Si necesita sus propias peticiones de borrado, debe asegurarse de que el objeto nuevo esté integrado en esta lógica de heredar peticiones de borrado o de que la verificación para peticiones de borrado del objeto integrado consulte las peticiones de borrado que son superiores en la jerarquía.

Normalmente, las peticiones de borrado para el material son suficientes.

 

Escritura y visualización de documentos de modificación

Para documentar modificaciones en los datos, los documentos de modificación se actualizan cada vez que se modifican los campos individuales en una tabla. Para ello, debe crearse un objeto de documento de modificación para la tabla. La creación de documento de modificación se realiza mediante el módulo de contabilización específico de la aplicación, llamando la rutina FORM creada por el sistema.

Para visualizar documentos de modificación, debe desarrollar un informe especial.

 

 

 

 

 

 

 

Fin del área de contenido