Hola queria consultarles algo, estoy debugeando el programa RPCALCX0 que genera el recibo de pago, y al ver el debug me trae en la tabla rt-betrg para el cc-nomina 1510 estos valores: betpe = 802,95, ANZHL = 9.00 y para betrg = 7227.00
El usuario del modulo me indica que ese monto del betrg es la mitad del monto que deberia traer ya que el valor correcto seria 14454,00 al debugear noto que el lee del rt esos valores, hay alguna otra forma con otra transaccion que pueda ver ese valor o de que depende ese campo rt-betrg??.
En la transacción PC_PAYRESULT puedes ver la tabla RT y todas las demás generadas por el proceso de calculo de nómina.
El campo betrg indica el importe del cc-nomina.
El porque sale un valor u otro puede ser por multitud de cosas. Para empezar habría que analizar todo el flujo de calculos segun el esquema de calculo, para ello activa el log en el programa de calculo. A partir de ahi debes seguir el valor de los cc-nomina, sobre todo en la tabla IT.
El calculo de nómina cambia mucho entre paises y también entre empresas.
Hay que análizar el tipo de Cc-nomina. Es un emolumento basico, un pago complementario, extras, complementos, Indemnizaciones por enfermedad, etc. Cada grupo tiene un comportamiento diferente en el calculo.
Si todo parece correcto hay que ver si hay algun split.
Además habría que analizar si hay retroactividad.
Por lo que veo el importe que sale es la mitad del que te indican. Habría que ver que se tiene en cuenta para ese calculo.
Puede ser bastante complejo sino estas familiarizado con el calculo de nomina.
Hola amigo gracias por tu explicacion, cuando la ejecuto ya tiene seleccionada lo del log pero yo no conozco nada de hr, veo mucha informacion ahi, aqui el detalle lo está dando para el mismo pais pero solo en sap calidad en produccion esta correcto, ese analisis que indica lo debe hacer es un funcional?? yo soy abap sin conocimientos en hr.
Me meti en la tx que indicas pero ese valor de ccnomina 1510 no aparece ahi en ninguno de los item que se despliegan.
El análisis lo debería hacer un funcional HCM con conocimiento de PY (calculo de nómina).
Si rl problema no habia dado hasta ahora, puede ser por una situación no contemplado por el esquema de nomina, por algún cambio que se haya hecho, o por error en la introducción en los datos del empleado. Hay que hacer un análisis funcional con conocimiento de la noemativa del pais y los aspectos especificos del empleado y la empresa.
Bueno aqui no hay funcional, solo usuarios, como puedo colocarle al esquema de calculo un break point para debugearlo, porque veo que al leer el cluster el trae esos valores y me indican que no deberian ser esos los montos.
el programa de calculo de nómina (en tu caso RPCALCX0) es realmente un interprete que va ejecutando lo que dice el esquema de nómina. Por eso es extraño que el problema esté en el programa en si y la idea no es debuguearlo, sino tratar de identificar en que parte del esquema está el problema.
El esquema de nómina esta escrito en una especie de ensamblador criptico que con tablas de entrada y salida, donde se llama a reglas (especie de árboles de decisión que hacen operaciones sobre los CC-nómina) y llamadas a funciones.
Dependiendo del problema que tengas hay varias formas de depurar la nómina. Las más basicas son:
Si conoces la función concreta a debugear donde crees que está el problema puedes acceder al código de la misma a través de la PE04 y poner un break-point en la línea que creas que tiene el problema.
Si el problema viene de una regla puedes poner un break point en el esquema de nómina (PE01) mediante la sentencia BREAK “PREFIJO” antes de la linea (el prefijo des un parametro de usuario AB4 que definas).
En el siguiente enlace de SAP tienes información detallada sobre el tema:
La persona que indica que el monto no es el correcto dice que puede ser una regla pero yo comparo el log en PRD y QA y se ven iguales en el log.
No entiendo esas operaciones lo que observo es que el monto de 1.605.90 luego se convierte en 802,95 que es lo que se imprime en el recibo es la mitad, de que depende eso de las operaciones de la regla?
Se puede obtener si una regla alguien la modifico?
Como indica @jmpm el Driver de Nómina solo esta interpretando y ejecutando las reglas de cálculo especificada y es una análisis funcional el que se debe realizar. Dado de no tienen consultor funcional deberás aclarar algunos puntos con el usuario.
El concepto de nómina (CCnómina) /09V es una Base de valoración por lo que el importe en el campo RTE (BETPE) se debe estar usando posteriormente en el cálculo para obtener otros valores, posiblemente el CCnómina 1510 que mencionaste en un inicio.
Que una base de valoración se calculé de una forma u otra es según las necesidades de cálculo por lo que si esta base divide entre 2 los importes ingresados es así como debió haberse definido al momento de crearse.
En tu ultimo print no observo si al final de la regla guarda el importe ya dividido en otro CCnómina /0XX, este ultimo debe ser el que tiene asignado el concepto 1510. Si puedes colocar el detalle de la regla completa seria de ayuda. Puedes ver el detalle en la transacción PE02.
El concepto de nómina 1510 debe estar usando la base de valoración resultante de la regla ZU68, si el usuario requiere el el importe no aparezca dividido entre 2, deben usar un concepto de nómina que use la base de valoración por ejemplo /09V que tiene los importes antes de dividirse.
De no tener un concepto con esta base de valoración deben consultar con el usuario si requiere que se cambie la base del concepto de nómina 1510, esto ultimo considerar que aplicaría para todos los empleados a los que se le aplique.
De no aplicar para todos debes crear un nuevo concepto de nómina, preferiblemente copia del 1510 y a este se le agrega la base /09V para que el importe se valore con la base sin división.
Lo anterior esperando que el 1510 sea un concepto informado y que no este siendo generado por otro grupo de reglas y allí se debe rastrear mas a profundidad.
Hola Amigo gracias por tu excelente informacion, una pregunta eso que dices que " de la regla guarda el importe ya dividido en otro CCnómina /0XX, " eso donde lo veo en proceso? en salida?
Porque observo que el /09V aparee dos veces en esta pantalla:
en PRD sale bien pero en CALIDAD no, y necesitamos saber cual es el detalle.
EN PRD no salen dos veces el ccnomina /09V en cambioen calidad si. Pero no se si ese es el detalle y como llego esa infi ahi.
Muchas Gracias
Para saber a que CCnómina lo guarda, debes consultar el proceso de la regla, PE02 debe existir una operación ADDWTIXXXX (XXXX = CCnómina que recibe los cambios) o bien ADDWT XXXX.
Si el concepto aparece 2 veces puede deberse a que existe mas de un split de puesto de trabajo o bien emolumento básico, esto puede deberse a que existen cambios organizativos o modificaciones a la asignación organizativa dentro del mismo período de evaluación, para confirmar esto puedes consultar la tabla WPBP al inicio de la ejecución del esquema.
Por lo que observo el segundo registro del /09V no lleva valores por lo que no influye en tu base, dado que en esta caso suma los dos registros. Lo que debes confirmar con el usuario es si el concepto 1510 que base de valoración de debe usar, una que lleve el valor completo o bien la mitad del valor.
Hola Amigo, muchas gracias por tu excelente explicacion, entrando a la PE02 y viendo lo que comentas encontre que:
Ahora lo que comentas del 1510 si se divide o no, en calidad es que da el detalle en produccion esta igual y todo sale correcto, lo que queremos es conocer cual es la diferencia, que aun no logro determinar, porque si las reglas estan iguales en ambos ambientes y QA es una copia de PRD para el mes de febrero, esto ocurre con todos los codigos de empleados pero en calidad en produccion todo correcto… Si en esa regla indica que se divida deberia dividir en ambos ambientes .
Según veo el titulo de la regla ZU68 esta resta el valor del concepto /09V de ORT al /09V de IT por lo que tus variaciones entre mandantes puede deberse al contenido que se hereda en la tabla ORT que al final esta siendo restado al concepto /09V que se genera en el proceso actual.
Son varias variables las que pueden estar afectando tu desviación y el comportamiento de tus reglas de cálculo. Tendríamos que entrar a mas detalle y debuggear todo el esquema y interpretar que valores están cambiando entre mandantes.
