Saltar al contenido principal

Ejemplos

Sugerencia

Estos ejemplos le mostrarán el proceso para configurar Extraction Packages. Hemos "extendido" el ejercicio para ofrecer una introducción más clara. La interfaz y los colores han sido adaptados en versiones más recientes. Por lo tanto, el aspecto que se muestra en las capturas de pantalla puede ser ligeramente diferente al de su versión.

Ejemplo 1 - Package simple

¿Qué datos queremos conocer o extraer?

  • Extracción de todas las posiciones ya contabilizadas
  • De todos los Company Codes productivos

¿Qué necesitamos para esta extracción o de dónde obtenemos estos datos?

  • Tabla con Company Codes
  • Tabla con posiciones ya contabilizadas del diccionario FI
  • Filtro en el indicador de si el Company Code es productivo

¿Qué elementos del package necesitamos?

Comencemos integrando T001 (tabla SAP de Company Codes) como tabla. Luego seleccionamos todos los campos. También utilizamos la tabla BSAK para extraer los items saldados; esta también se incluye como tabla. Como solo queremos los Company Codes que ya están en uso productivo, creamos un filtro, que en este ejemplo llamamos Is_Prod. Finalmente, creamos un repositorio en el que se guardan estos Company Codes después del primer paso (extracción de todos los Company Codes productivos) para poder realizar la siguiente extracción; en este ejemplo llamamos al repositorio BuKrs (el equivalente alemán de CCode).

Después de estos pasos, tenemos los siguientes elementos a la izquierda:
nexus_ps_example_1

Filtro

En el siguiente paso, configuramos el filtro. Especificamos en este filtro que el campo XPROD en la T001 debe estar activo, es decir, debe contener el valor X; ingresamos el Tipo Fixed Value. Como se trata de un carácter, el DataType es String y la Condition es Equal, pues buscamos exactamente el valor X. Ahora ingresamos el valor X y en las relaciones con la tabla especificamos que este filtro se aplica sobre la tabla T001 en el campo XPROD.

El área de detalle en la parte derecha ahora se ve así (al seleccionar el filtro en la izquierda):
nexus_ps_example_2

Repositorio

Ahora filtramos todas las entradas de la tabla T001 cuyos Company Codes están activos (XPROD = X). Necesitamos almacenar temporalmente estos datos para su uso posterior. Hacemos esto en el repositorio BuKrs. Insertamos en el repositorio los campos que debe contener, de dónde provienen estos contenidos y para qué otras tablas se utilizan estos valores.

Por ello, primero insertamos un campo CCode; si llamáramos a este campo BUKRS, se activaría el auto-mapeo para las tablas fuente y destino. Sin embargo, en este ejemplo lo haremos manualmente primero. Luego especificamos que la tabla fuente es T001; de ahí obtenemos los datos que almacenamos en este repositorio. Por último, indicamos que la tabla objetivo es BSAK. Los valores de este repositorio se seguirán utilizando en esta tabla.

Verá un ⚙️ junto al nombre de cada tabla a la derecha. Este símbolo ⚙️ significa Custom Mapping, lo que indica que debe Link el campo de la respectiva tabla con el campo del repositorio.

Finalmente, la vista detallada del repositorio se ve así:
nexus_ps_example_3

Al hacer clic en ⚙️ se abre una ventana con la opción de vincular los valores manualmente.

Tablas

Ahora echemos un vistazo al área de detalle de las tablas T001 y BSAK:
nexus_ps_example_4

Aquí en T001 puede ver los campos seleccionados; los dos primeros son las claves primarias y el tercero es el indicador de si el Company Code está en uso productivo. El filtro se aplica al campo XPROD y los Company Codes filtrados van al repositorio objetivo BuKrs.

La situación es algo diferente en el área de detalle de BSAK. Aquí, los datos se filtran dependiendo de la dependencia de los datos provenientes del repositorio BuKrs:
nexus_ps_example_5

Resultado

Al final, la Vista de Elementos en el centro se ve de la siguiente manera:
nexus_ps_example_6

La breve explicación para esto es: El filtro llamado Is_Prod filtra las entradas de la T001. Estas entradas filtradas van al repositorio BuKrs, que se utiliza para filtrar las entradas de BSAK. Al final, usted recibirá una lista de las posiciones contabilizadas de BSAK que están asignadas a un Company Code productivo.


Ejemplo 2 - Package avanzado

¿Qué datos queremos conocer o extraer?

  • Buscar todas las órdenes de compra (PO) de la tabla EKKO
  • Extrayendo todas las POs con documentos de factura abiertos o ya pagados
  • De uno o varios ejercicios fiscales
  • De proveedores alemanes

¿Qué necesitamos para esta extracción o de dónde obtenemos estos datos?

  • Tablas:
    • Vendor Master Data
    • Contabilidad: índice secundario para proveedores (items liquidados)
    • Contabilidad: índice secundario para proveedores (items abiertos)
    • Segmento de documento contable
    • Cabecera de documento de compras
  • Filtros:
    • Proveedores de Alemania
    • Ejercicio fiscal
  • Repositorios (los añadimos durante la creación del Package):
    • ...

¿Qué elementos del package necesitamos?

Comencemos con las tablas necesarias:

  • LFA1: Vendor Master Data
  • BSAK: Contabilidad - índice secundario para proveedores (items liquidados)
  • BSIK: Contabilidad - índice secundario para proveedores (items abiertos)
  • BSEG: Segmento de documento contable
  • EKKO: Cabecera de documento de compras

A continuación, crearemos los filtros y los denominaremos de la siguiente manera:

  • LFA1_DE: filtro para proveedores alemanes
  • GJAHR: ejercicio fiscal

Ahora, la lista de elementos a la izquierda debería verse así:
nexus_ps_example_7

Filtro LFA1_DE

Configuremos el filtro LFA1_DE y especifiquemos en qué tablas y campos deseamos filtrar.

Establecemos un Fixed Value, ya que buscamos proveedores de un país específico (que no cambia). La Condition se establece en Equal, ya que buscamos el valor exacto. El DataType es string porque el valor son caracteres. Como Value colocamos DE, la clave de país para Alemania. Por último, añadimos la relación de tabla a LFA1 y al campo LAND1, ya que deseamos filtrar allí.

Ahora el filtro LFA1_DE debería verse así:
nexus_ps_example_8

Filtro GJAHR

Ahora configuramos el segundo filtro para el ejercicio fiscal. Como tenemos un tipo de filtro específico denominado Fiscal Year, podemos utilizarlo. En este caso no es necesario introducir el ejercicio fiscal deseado en el propio package, sino más adelante en la Task. También aquí establecemos dos relaciones de tabla. Una para BSAK y otra para BSIK, ambas con el campo GJAHR.

Ahora el filtro GJAHR debería verse así:
nexus_ps_example_9

Repositorio LFA1_Kred_DE

Ya que hemos creado exitosamente las tablas y filtros, vamos a centrarnos ahora en los repositorios que se necesitan para guardar los resultados intermedios con los que podremos seguir trabajando.

Creamos el repositorio LFA1_Kred_DE para almacenar temporalmente los resultados al filtrar la tabla LFA1 con el filtro LFA1_DE. Definimos la siguiente configuración para el repositorio:

  • Campos
    • LIFNR: número de proveedor de los proveedores alemanes
  • Tablas objetivo
    • BSIK: asignación automática de los campos vía LIFNR
    • BSAK: asignación automática de los campos vía LIFNR

Ya tenemos nuestro primer repositorio, que contiene todos los números de proveedor de los proveedores alemanes. Debería verse así:
nexus_ps_example_10

Repositorio Belnr

Ahora creamos otro repositorio y lo llamamos Belnr; aquí queremos almacenar los números de documento encontrados en las tablas BSAK y BSIK. Obtenemos los números de documento filtrando estas tablas por los números de proveedor recién encontrados (y almacenados en el repositorio LFA1_Kred_DE) y con el/los ejercicio(s) fiscal(es) ingresado(s) en la Task.

Pero ahora debemos tener cuidado. Guardar aquí solo los números de documento significaría que posiblemente no recibiríamos todos los números de documento o tendríamos numerosas entradas duplicadas. Ello se debe a que el número de documento puede repetirse entre diferentes Company Codes y ejercicios fiscales. Para evitar esto, no solo guardamos el número de documento en el repositorio, sino también el ejercicio fiscal y el Company Code.

Como obtenemos esta información de las tablas BSAK y BSIK, indicamos estas dos como nuestras tablas fuente. Con el Custom Mapping podemos comprobar si los campos están correctamente mapeados.

Así, tenemos ahora los números de documento de los proveedores alemanes del/los ejercicio(s) fiscal(es) deseados en nuestro repositorio Belnr. Debería verse así:
nexus_ps_example_11

Tabla BSEG

Ahora buscamos las POs en la tabla BSEG. Esto significa que la BSEG se filtra como una dependencia de nuestro repositorio Belnr. Debido a la diferencia en la escritura del campo del Company Code, también aquí debe realizarse de nuevo el Custom Mapping:
nexus_ps_example_12

Repositorio EBELN

Ahora escribimos los datos obtenidos de BSEG en este repositorio final, que llamamos EBELN. Como los números de PO son únicos en nuestro ejemplo, aquí solo necesitamos un campo, que también se llama EBELN.

Especificamos que los datos almacenados aquí provienen de la tabla BSEG (por lo tanto, como tabla fuente):
nexus_ps_example_13

Y como ahora hemos prestado atención a la escritura correcta entre mayúsculas y minúsculas, el mapeo automático vuelve a aplicarse.

Tabla EKKO

Al final, queremos filtrar la tabla EKKO con las POs encontradas en BSEG para obtener toda la información adicional de la cabecera de orden. Por eso ahora incluimos la EKKO. Como aquí deseamos extraer toda la información disponible, seleccionamos todos los campos con el botón All. Esta tabla se filtra nuevamente en función de la dependencia del repositorio anterior EBELN:
nexus_ps_example_14

Resultado

¡Y voilà! Al final, tenemos todos los datos relevantes de la cabecera de las órdenes del/los ejercicio(s) fiscal(es) deseados de proveedores alemanes.

Si observamos la Vista de Elementos en el centro, todo se ve así:
nexus_ps_example_15

Con esta configuración, la Task creará las siguientes tablas de resultados:

  • LFA1
  • BSAK
  • BSIK
  • BSEG
  • EKKO

Si realmente solo le interesa la información de la cabecera de órdenes, también puede cambiar las tablas LFA1, BSAK & BSIK y BSEG a Virtual Tables. Estas entonces ya no se guardan como tablas de resultados al final de una Extraction Run.