Juego de herramientas robot P2P analysis for SAP ERP

Este estudio analítico identifica posibles transacciones duplicadas que pueden estar causadas por un error del proveedor o del personal de CP.

Una transacción se define como una partida presupuestaria de una factura. Las transacciones duplicadas se identifican sobre la base de 12 combinaciones diferentes de campos, que se llaman pruebas secundarias. Para obtener más información sobre las pruebas secundarias, consulte Juego de herramientas robot P2P analysis for SAP ERP.

Las partidas presupuestarias duplicadas en una única factura no se reportan para el análisis y la revisión, ya que dichas partidas presupuestarias suelen hacer referencia al mismo elemento o a los mismos servicios en distintas ubicaciones o entidades. Muchos de los riesgos de las facturas duplicadas, como programar la misma venta para dos proveedores distintos o introducir el número de factura del proveedor de forma incorrecta, no se aplican a la misma factura. Puede que estas partidas presupuestarias se reporten si son duplicados de una o más partidas presupuestarias en otra factura.

Se aplica un concepto igual-igual diferente para hacer que no se reporte el mismo conjunto de transacciones marcadas varias veces. Esto se consigue definiendo campos diferentes como uno o más campos que se identificaron como duplicados en una prueba secundaria previa.

Ejemplo

• La prueba secundaria P2P01AP_01 marca las transacciones con el número de proveedor y el número de factura del proveedor duplicados. Puede que haya, o no, otros duplicados, como la misma fecha de facturación o el mismo importe de transacción, ya que esta prueba secundaria no tiene requisitos para ningún campo que no sea el número de documento.
• La prueba secundaria P2P01AP_02 marca las transacciones con el número de proveedor, la fecha de facturación y el importe de transacción duplicados.
  • Esta transacción ya se habría marcado en la primera prueba secundaria si el número de factura del proveedor estuviera duplicado. Por lo tanto, se añade el requisito de que el número de factura del proveedor sea diferente.
  • Para reducir la posibilidad de falsos positivos y encontrar los duplicados más probables, la prueba también requiere un número de factura del proveedor similar (definido como tener una secuencia idéntica de dígitos numéricos después de descartar todos los demás caracteres).

Notas

• Una transacción no se puede excluir del análisis una vez que haya coincidido con otra transacción. Todavía está disponible para coincidir con otras transacciones en el conjunto de claves iguales en pruebas secundarias posteriores.
• Puede que las pruebas secundarias que analizan los duplicados en campos de datos bancarios o de números de teléfono reporten las mismas transacciones marcadas varias veces. Un proveedor puede tener varias cuentas bancarias al igual que un número de teléfono principal y secundario. Cada cuenta bancaria se prueba de forma individual y, si dos proveedores coinciden en varias cuentas bancarias, los posibles duplicados se reportan para cada coincidencia. Ocurre lo mismo con los números de teléfono.
• La moneda de la factura no tiene que ser idéntica para las pruebas secundarias que buscan importes de transacciones iguales (BSIK / BSAK_WRBTR). Es posible que las transacciones marcadas con importes idénticos y monedas diferentes señalen errores de entrada del personal de CP.
• El código de la empresa de los proveedores en los duplicados marcados no tiene que ser idéntico.
• Las transacciones con datos faltantes en cualquiera de los campos iguales se eliminarán del análisis. Los datos faltantes en los campos diferentes seguirán en el análisis.
• A continuación, se detalla la diferencia de gestión de las mayúsculas y minúsculas para campos iguales y diferentes:
  • Los campos iguales no distinguen entre mayúsculas y minúsculas. Por ejemplo, en las pruebas secundarias que buscan duplicados en el nombre del proveedor, ABC CORP y Abc Corp se consideran duplicados
  .
  • Los campos diferentes originales distinguen entre mayúsculas y minúsculas. Por ejemplo, en las pruebas secundarias que requieren números de factura de proveedores diferentes para transacciones que se marcarán como duplicadas en los campos iguales, los números de factura JAN-2021-07 y Jan-2021-07 del proveedor se consideran diferentes y las transacciones que coinciden en los campos iguales se marcarán.
  • Los campos diferentes estandarizados como c_Vendor_Name_Sorted se utilizan según su definición, lo que puede incluir la conversión a mayúsculas.

Parámetros predeterminados Dos parámetros predeterminados, v_P2P01AP_min_threshold y v_delete_P2P01AP, están disponibles para este estudio analítico en las hojas de cálculo Default_Config_Params y Script P2P01AP_Duplicate_Transactions del archivo Default Analytic Configuration, respectivamente. Si los parámetros predeterminados no son aplicables o están incompletos, puede declarar los valores necesarios en el archivo User Analytic Configuration. Asegúrese de respetar el formato y las convenciones de nombres que se mencionan en el archivo Default Analytic Configuration.

Tabla de resultados para este estudio analítico R_P2P01AP_Duplicate_Transactions.

Este estudio analítico identifica detalles de transacciones y proveedores con palabras clave de alto riesgo que podrían indicar errores, derroche o abuso.

Se examinan los siguientes campos:

• Descripción de facturas a nivel de encabezado: BKPF_BKTXT.
• Descripción de partidas presupuestarias: BSIK / BSAK_SGTXT.
• Campo de nombre del proveedor: c_Full_Vendor_Name. El campo c_Full_Vendor_Name concatena los campos LFA1_NAME1 hasta LFA1_NAME4 en el script de preparación de datos P_LFB1_LFA1_BUKRS. Si la tabla del proveedor se rellena sin registros, solo se prueban los campos de descripción de la factura y descripción de la partida presupuestaria.

Algunas palabras clave comunes de alto riesgo se almacenan en una tabla de parámetros en el archivo Default Analytic Configuration.

• Las palabras clave predeterminadas se pueden reemplazar por un conjunto alternativo rellenando la tabla de parámetros en el archivo User Analytic Configuration. Tenga en cuenta que, si alguna de las palabras clave predeterminadas se va a aplicar, debe mencionarla en el archivo User Analytic Configuration. Si el usuario proporciona una tabla de parámetros, la tabla de parámetros predeterminada se descarta por completo.
• La búsqueda de palabras clave no distingue entre mayúsculas y minúsculas.
• La búsqueda de palabras clave identifica coincidencias parciales, donde la palabra clave es una subcadena de una palabra en los archivos de búsqueda, por ejemplo, la palabra clave regalo se encuentra en la descripción que contiene la palabra regalos.
• La búsqueda de palabras clave no identifica coincidencias parciales cuando una o más palabras en los campos de búsqueda son subcadenas de una palabra clave; por ejemplo, la palabra clave pagar en una descripción que contiene pagar a los proveedores o pagar a los proveedores mencionados.

Si hay una coincidencia de más de una palabra clave en los tres campos de prueba, el estudio analítico las concatena en una lista separada por barra vertical, que se muestra en el campo c_Matched_Keyword_List. Además, el estudio analítico reporta el campo Primary_Matched_Keyword, que contiene en la tabla de parámetros la primera palabra clave que tenía coincidencias. Esta funcionalidad supone que la tabla de parámetros se rellena con palabras clave en orden descendente de criticidad.

• Si aparecen varias coincidencias en una misma palabra clave en uno o más campos, solo se reportan una vez.
• Si una palabra clave tiene varias coincidencias, se reportan en el orden en el que aparecen en la tabla de parámetros.

No hay un filtro de resultados predeterminado disponible. Puede declarar los filtros de resultados en el archivo User Analytic Configuration para perfeccionar los resultados.

Parámetros predefinidos Un parámetro predefinido, v_P2P02AP_min_threshold, está disponible para este estudio analítico en la hoja de cálculo Default_Config_Params del archivo Default Analytic Configuration. Si el parámetro predeterminado no es aplicable o está incompleto, puede declarar los valores necesarios en el archivo User Analytic Configuration. Asegúrese de respetar el formato y las convenciones de nombres que se mencionan en el archivo Default Analytic Configuration.

Tabla de resultados para este estudio analítico R_P2P02AP_High_Risk_Keywords.

Este estudio analítico identifica importes de transacciones inusuales para un proveedor determinado que son iguales o mayores que un número específico de desviaciones estándar desde el importe de transacción promedio del proveedor. Es posible que estas transacciones indiquen un error cometido por el proveedor o por el personal de CP.

El siguiente pseudocódigo describe el proceso en detalle. Cada partida presupuestaria de la factura se trata como transacción.

• Se calcula el recuento total de la transacción para un proveedor determinado, independientemente del código de la empresa. Este campo es necesario para generar reportes.
• El comando OUTLIER se utiliza para reportar cualquier importe en la moneda local (DMBTR) que corresponda a por lo menos n desviaciones estándar desde el importe de transacción medio promedio de un proveedor determinado, donde n es un parámetro configurable. Se presupone una única moneda por proveedor. No está permitido tener distintas monedas por código de empresa para el mismo proveedor.

• Los proveedores marcados se unen con la tabla maestra del proveedor (P_LFB1_LFA1_BUKRS) para buscar campos de reportes adicionales.

No hay un filtro de resultados predeterminado disponible. Puede declarar los filtros de resultados en el archivo User Analytic Configuration para perfeccionar los resultados, como el importe de valor atípico mínimo para reportar.

Parámetros predefinidos Un parámetro predefinido, v_P2P03AP_num_std_dev, está disponible para este estudio analítico en la hoja de cálculo Default_Config_Params del archivo Default Analytic Configuration. Si el parámetro predeterminado no es aplicable o está incompleto, puede declarar los valores necesarios en el archivo User Analytic Configuration. Asegúrese de respetar el formato y las convenciones de nombres que se mencionan en el archivo Default Analytic Configuration.

Tabla de resultados para este estudio analítico R_P2P03AP_Outliers_Std_Dev.

Este estudio analítico identifica importes de transacciones inusuales basados en el análisis de Benford de los primeros n dígitos. Es posible que estas transacciones indiquen un error cometido por el proveedor o por el personal de CP.

Al principio, se examinan todas las transacciones (partidas presupuestarias) para evaluar la distribución del conjunto de datos completo e identificar los valores atípicos estadísticos. Los valores atípicos se definen como combinaciones de dígitos iniciales cuya frecuencia no coincide con la frecuencia esperada según la fórmula de Benford. Esta prueba secundaria de transacciones se filtra de manera más precisa para que aparezcan solo esas combinaciones de números iniciales con un valor estadístico Z igual o mayor que el umbral especificado por el usuario (el valor predeterminado es 7).

Para cada una de las combinaciones de dígitos iniciales marcadas resultantes, los proveedores con los recuentos de transacciones más altos aparecen en los resultados, y estos proveedores contribuyen más a los valores atípicos estadísticos. Los proveedores con recuentos de transacciones más bajos no aparecen en los resultados o no se tienen en cuenta para la matriz de resultados de proveedores.

El siguiente pseudocódigo describe el proceso en detalle:

1. Define el campo calculado c_Leading_Digits, que captura los n dígitos iniciales de cada importe en la moneda de la factura (BSIK/BSAK_WRBTR).
2. Aplica el comando BENFORD a lo siguiente:
   • Cuenta las ocurrencias actuales de cada posible combinación de dígitos iniciales en los datos de la transacción.
   • Compara el recuento actual con el recuento esperado (se calcula usando la fórmula Benford)
   • Muestra el valor estadístico Z para cada combinación de dígitos iniciales, que es una medida de la distancia entre el recuento real y el recuento esperado expresada en desviaciones estándar.
3. Extrae cada combinación de dígitos iniciales de la tabla de salida BENFORD con un valor estadístico Z mayor que n, donde n es un valor definido por el usuario (el valor predeterminado es 7).
4. Une las combinaciones de dígitos iniciales marcadas con el campo c_Leading_Digits de la tabla de transacción para llevar a cabo solo las transacciones que tengan, por lo menos, el valor estadístico Z especificado.
   • Es posible que las transacciones de un proveedor determinado se asignen a una o más de las combinaciones marcadas.
   • O es posible que las transacciones de un proveedor determinado no se asignen a ninguna de las combinaciones marcadas y el proveedor no aparezca en análisis posteriores.
5. Resume las transacciones resultantes del proveedor y las combinaciones de dígitos iniciales para obtener un recuento de transacción para combinaciones. Es posible que el recuento de transacción refleje partidas presupuestarias para una o más facturas.
6. Ordena la tabla resumida por combinaciones de dígitos iniciales y el recuento de transacción (en orden descendente), de manera que el recuento de transacción mayor aparece al principio para cada combinación de dígitos iniciales.
7. Vuelve a resumir la tabla resultante solo de la combinación de dígitos iniciales, de manera que solo se lleva a cabo el recuento de transacción mayor para cada combinación de dígitos iniciales.
8. Une la tabla de transacciones de CP completa con la tabla resumida que contiene los proveedores con el recuento de transacción más alto por combinación de dígitos iniciales, de manera que solo estos proveedores siguen adelante. La lógica de este paso es la siguiente:
   • Estos proveedores contribuyen más a los valores atípicos estadísticos y son el foco de este análisis.
   • Los proveedores con un recuento de transacción más bajo no son el foco del análisis y no aparecen en los siguientes procesos.
9. Une los proveedores restantes con la tabla maestra del proveedor (P_LFB1_LFA1_BUKRS) para buscar campos de reportes adicionales.

No hay un filtro de resultados predeterminado disponible. Puede declarar los filtros de resultados en el archivo User Analytic Configuration para perfeccionar los resultados, como el importe de valor atípico mínimo para reportar.

Parámetros predefinidos Dos parámetros predefinidos, v_P2P04AP_leading_digits y v_P2P04AP_zstat_threshold, están disponibles para este estudio analítico en la hoja de cálculo Default_Config_Params del archivo Default Analytic Configuration. Si los parámetros predeterminados no son aplicables o están incompletos, puede declarar los valores necesarios en el archivo User Analytic Configuration. Asegúrese de respetar el formato y las convenciones de nombres que se mencionan en el archivo Default Analytic Configuration.

Tabla de resultados para este estudio analítico R_P2P04AP_Outliers_Benford.

Este estudio analítico identifica patrones de registro que pueden indicar errores cometidos por el proveedor o por el personal de CP. Específicamente, este estudio analítico reporta transacciones publicadas por los usuarios que también han creado el registro maestro de proveedores en LFA1 o LFB1, o en ambos, ocasionando divisiones de tareas inadecuadas.

Compara el campo de transacción BKPF_USNAM con los campos del proveedor LFA1_ERNAM y LFB1_ERNAM. En LFA1, solo se examina la entrada que coincide con el código de transacción de la empresa.

Al principio, se examina la tabla de transacciones completa a nivel de partida presupuestaria para identificar todas las ocurrencias. A continuación, las transacciones marcadas se incluyen en un reporte resumido que el usuario y el proveedor elaboran y que muestra un importe total de transacciones y un importe total de transacciones en la moneda local.

El reporte resumido muestra los datos de la transacción (partida presupuestaria) con el importe más alto en la moneda local que se ha encontrado para cada combinación marcada de usuario y proveedor.

El siguiente pseudocódigo describe el proceso en detalle. Cada partida presupuestaria de la factura se trata como transacción.

1. Une la tabla de transacciones con el proveedor maestro para buscar a los usuarios LFA1 y LFB1 que crearon la entrada del proveedor.
2. Ordena la tabla unida por proveedor, nombre de usuario e importe en moneda local (en orden descendente), de manera que el importe de transacción más alto aparece al principio de cada combinación.
3. Filtra la tabla ordenada para las transacciones en las que ocurre lo siguiente:
   • El usuario que creó la transacción es el mismo usuario que creó la entrada del proveedor en LFA1.
   • O el usuario que creó la transacción es el mismo usuario que creó la entrada del proveedor y la entrada del código de empresa en LFB1.
4. Resume las transacciones marcadas por combinación de usuario y proveedor para producir un recuento total de transacciones y un importe en la moneda local, e incluye los campos de partida presupuestaria de la transacción con el mayor importe en la moneda local.
   • Los proveedores se incluyen en un único registro, independientemente de los códigos de empresa.
   • Se supone que la moneda local para un proveedor es idéntica en todos los códigos de empresa al calcular el importe total.
5. La tabla resumida se ordena para reportar las combinaciones de usuario y proveedor marcadas en orden descendente según el importe local (independientemente de la moneda).

No hay un filtro de resultados predeterminado disponible. Puede declarar los filtros de resultados en el archivo User Analytic Configuration para perfeccionar los resultados, como el importe de valor atípico mínimo para reportar.

Tabla de resultados para este estudio analítico R_P2P05AP_SOD_Vendor_AP.

Este estudio analítico identifica patrones de registro que pueden indicar errores cometidos por el proveedor o por el personal de CP. Específicamente, este estudio analítico muestra los proveedores donde todas las transacciones del periodo de investigación fueron publicadas por el mismo usuario en todos los códigos de empresa del proveedor.

Al principio, se examina la tabla de transacciones completa a nivel de partida presupuestaria para identificar todas las ocurrencias del mismo usuario que publicó todas las transacciones del proveedor. A continuación, las transacciones marcadas se incluyen en un reporte resumido que elabora el proveedor y que muestra un importe total de transacciones y un importe en la moneda local.

El reporte resumido incluye los datos de la transacción (partida presupuestaria) con el mayor importe en la moneda local que se ha encontrado para cada proveedor marcado.

El siguiente pseudocódigo describe el proceso en detalle. Cada partida presupuestaria de la factura se trata como transacción.

1. Ordena la tabla de transacciones por proveedor, usuario e importe en la moneda local y en orden descendente.
2. Resume la tabla de transacciones con el número de proveedor y el nombre de usuario para generar una tabla con una lista de todos los usuarios que publican transacciones de un proveedor determinado.
   • Crea un importe total en la moneda local para cada combinación, renombrado c_Total_Trans_Amount_LC_VenUsr. Se supone que la moneda es la misma en todos los códigos de empresa para el proveedor.
   • Renombra el campo del recuento como c_Trans_Count_VenUsr
   • Se continúa con los datos de la transacción (partida presupuestaria) con el importe más alto en la moneda local que se ha encontrado para cada combinación marcada de usuario y proveedor.
3. Vuelve a resumir la tabla resultante, solo con el proveedor, y genera subtotales para el proveedor como se muestra a continuación:
   • Total de c_Total_Trans_Amount_LC_VenUsr, renombrado como c_Total_Trans_Amount_LC.
   • Total de c_Total_Trans_Amount_LC_VenUsr, renombrado como c_Trans_Count.
   • Se continúa con los datos de la primera transacción (partida presupuestaria) que se han encontrado para cada proveedor. En el caso de que haya un único usuario debido al criterio de ordenamiento anterior, será la transacción con el importe más alto en la moneda local.
   • Renombra el campo de recuento como c_Unique_User_Count.
4. Extrae todos los campos para esos proveedores cuyo recuento de usuario único es 1 y cuyo recuento de transacciones es igual o mayor que el umbral especificado (el valor predeterminado es 10).
5. Une los proveedores marcados con la tabla maestra del proveedor (P_LFB1_LFA1_BUKRS) para buscar campos de reportes adicionales.

No hay un filtro de resultados predeterminado disponible. Puede declarar los filtros de resultados en el archivo User Analytic Configuration para perfeccionar los resultados, como el importe de valor atípico mínimo para reportar.

Parámetros predefinidos Un parámetro predefinido, v_P2P06AP_min_count, está disponible para este estudio analítico en la hoja de cálculo Default_Config_Params del archivo Default Analytic Configuration. Si el parámetro predeterminado no es aplicable o está incompleto, puede declarar los valores necesarios en el archivo User Analytic Configuration. Asegúrese de respetar el formato y las convenciones de nombres que se mencionan en el archivo Default Analytic Configuration.

Tabla de resultados para este estudio analítico R_P2P06AP_Posting_Patterns_Single_User.