Recurro a uds ya que se me presenta un caso en el cual se deben compensar automáticamente partidas de deudor por periodos y que de esta forma se muestre el saldo de la partida por ejemplo prestamos a empleados sin necesidad de ejecutar la F.13 o realizar un traslado con compensación a la cuenta de deudor, o realizar un abono por la f-32.
En este caso desconozco si se puede hacer una parametrizacion que me permita lograr lo antes expuesto.
¿Por que no utilizar las transacciones usuales?
¿Puedes dar mas información?
Si quieres automatizar podrías crear un job que ejecute la transacción durante la noche.
En este caso el cliente que hace la solicitud no quiere que ningún usuario realice procedimiento alguno a través de las transacción usuales quiere que el sistema realice todo el proceso.
El detalle es que la f.13 me realiza las compensaciones si las partidas positivas son iguales a las negativas desconozco si existe alguna forma de que esta me vaya amortizando una partida deudora por cada abono que reciba.
justamente considero que la mejor opción es crear un desarrollo. Ahora bien sera prudente hacer el mismo copiando la F.13 y modificandola? o que otro punto de partida me sugieren??
Hacer una copia Z del report SAPF124 (que es el que está detrás de la F.13) puede que no sea nada sencillo porque tiene muchos includes y lo mismo no se puede hacer un z de todos ellos para modificarlos.
Yo mejor haría un report nuevo.
@millan_karim, otra opcion seria que generes un reporte Z, donde utilices el modulo de funcion POSTING_INTERFACE_CLEARING, que es el que utiliza la F-32.
Sera necesario que la partida deudora y cada uno de los abonos para poder compensarlas entre si tengan algun elemento en comun, por ejemplo, con el campo asignacion (ZUONR).
En mi experiencia, se compensaba la partida original y todos sus abonos, y en caso de generar diferencia se contabilizaba una nueva partida por el resto. Si no queres generar una partida nueva, seguramente con la ayuda de un Abaper, podras realizar la compensacion parcial.
Creo yo que no requieres desarrollo ya que en la transacción OB74 puedes establecer el criterio 1 para la compensación automática, de no cumplirse el criterio 2 y hay hasta 5, y sinceramente no he ocupado más que 3 pero dando una revisada me parece que si podrías seleccionar uno que te de lo que indicas.
Por ejemplo, detecto 3 campos para criterio: Periodo de alta, fecha de documento, fecha de contabilización. Tendrías que hacer pruebas para validar.
en el caso propuesto, tal como lo indica el compañero @jnievas lo que se busca es que sea compensaba la partida original y todos sus abonos, y en caso de generar diferencia se contabilizaba una nueva partida por el resto. Desconozco si aplicando los criterios de de compensación pueda generar dicho proceso.
gracias por el comentario estimado justamente este es el resultado que se pretende conseguir, ya tendría que validar a parte de la función que indicas cuales serian las tablas de datos a utilizar en el desarrollo del Z.
Amigo @jnievas en este caso cuando realizas el proceso de compensación por asignación para deudores a través del Z se realiza una Call Transaction directamente a la FB05?
hola @millan_karim
En mi caso se trabajo con la BAPI POSTING_INTERFACE_CLEARING, completando los datos
No soy abaper para confirmarte si se puede usar directamente un call transaction a la FB05, pero puedes intentarlo.
ok, Justamente eso es lo que que quiero compensar una cuenta de mayor por el campo de Asignación y que esta a su vez me contabilice las diferencias de compensación en la misma cuenta de mayor puedo presumir que es mejor usar la BAPI que mencionas antes de hacer un call transation a la FB05. Adicional a lo que me comentas se puede considerar otra función para este caso?
Para el caso que mencionas considero que es la BAPI adecuada, que te permitirà compensar la/s partida/s abierta/s y registrar en la misma cuenta o en la que desees la diferencia de compensacion.