Devoluciones domiciliadas en extracto bancario
By s4pcademy
¡Hola SAPers!
Aquí está mi última publicación, donde me gustaría compartir algunos detalles sobre la funcionalidad de SAP. Me tomó algún tiempo preparar esta publicación y me llevará algún tiempo leerla. Espero que no te arrepientas esta vez. Por favor, mira también mis otras publicaciones.
Introducción
Débito directo es una transacción financiera, donde la empresa envía la instrucción al banco para cobrar el pago directamente de la cuenta bancaria del deudor. La domiciliación bancaria correctamente implementada simplifica el cobro de deudas para la empresa. Este proceso está bien descrito/documentado. Pero por regla general, la documentación cubre el proceso regular, es decir, cuando el banco logró cobrar el pago. Las devoluciones por domiciliación (cancelaciones/rechazos) no se describen adecuadamente. Esta publicación tiene como objetivo llenar este vacío de conocimiento.
Vista general del proceso
La siguiente captura de pantalla proporciona una descripción general de alto nivel del proceso en torno a la domiciliación bancaria:
El débito directo se inicia en SAP a través del programa de pago automatizado (es decir, F110). El programa genera el documento de pago que acredita la cuenta del cliente. Este documento de pago compensa automáticamente las partidas abiertas en la cuenta del cliente y genera una partida abierta al liquidar la cuenta del LM para los pagos bancarios entrantes. Si todo va bien, el banco cobrará el pago al cliente y mostrará el recibo asociado en un extracto bancario. Esta es una explicación simplificada, pero espero que proporcione una buena explicación. La siguiente captura de pantalla proporciona una descripción general de las publicaciones contables típicas.
Consideremos ahora el caso de devolución domiciliada. La devolución puede ocurrir debido a una variedad de razones, por ejemplo, fondos insuficientes, mandato de domiciliación bancaria incompleto/erróneo, etc. El banco cobra una tarifa de devolución por cada operación. Lo que es aún más complicado, su banco puede proporcionar la información en el extracto bancario en formato agregado, es decir, el monto de la operación (1005,00 EUR) incluirá el monto del pago original (1000,00 EUR) + la tarifa de devolución (5,00 EUR). La siguiente captura de pantalla muestra un extracto bancario de muestra con dicha operación agregada.
La siguiente captura de pantalla muestra las publicaciones esperadas en el extracto bancario con respecto a la devolución de débito directo. Aunque solo tenemos una línea en el extracto bancario, el sistema debería poder generar dos publicaciones separadas:
- Pago de devolución domiciliada con 2 zonas de contabilización.
- Comisión bancaria asociada a la devolución domiciliada.
Veamos cómo se puede implementar este proceso en el sistema.
Flujo de proceso en el sistema
El programa de pago automático generó un documento de pago 2000000006 por un monto total de 1000,00 EUR. Este número de documento de pago se proporcionará en la nota al beneficiario para el débito directo devuelto en el extracto bancario. Vea el ejemplo anterior, donde se resalta este valor.
A continuación se proporciona una captura de pantalla del documento de pago:
Esta ejecución de pago borró automáticamente la partida abierta asociada con la factura de cliente 1800000007:
El intervalo de números de documentos contables debe incluir el rango de números para documentos de pago. La siguiente captura de pantalla muestra el bloque de pantalla de selección apropiado en la transacción FF_5.
Si trabaja con el sistema S4 HANA y usa la aplicación Fiori F1680 “Administrar archivos de pagos entrantes”, deberá configurar el conjunto de parámetros, que almacena los rangos de números asociados con el extracto bancario. Por favor refiérase a mi anterior correoque describe esta configuración.
La siguiente captura de pantalla muestra el registro de importación asociado con la carga de este extracto bancario. Como puede ver, el programa dividió un artículo en dos artículos diferentes, asignó diferentes reglas de contabilización y contabilizó automáticamente los documentos en ambas áreas de contabilización.
Como puede ver, el registro de la segunda área de contabilización muestra que el programa identificó el documento de pago original 2000000006/2023. El borrado se restableció automáticamente. Además, como puede ver, el informe muestra la partida abierta para la factura de cliente 1800000007. Esta factura se compensó durante la ejecución del pago, pero ahora se vuelve a abrir.
La siguiente captura de pantalla muestra la contabilización asociada a la devolución de la domiciliación bancaria:
La siguiente captura de pantalla muestra ambas líneas en el extracto bancario (transacción FEBAN/FEB_BSPROC):
El programa mostrará la línea relacionada en la ventana de diálogo:
Si usa S4 HANA y la aplicación Fiori F1520 “Reprocesar partidas de extractos bancarios” para el procesamiento posterior de las partidas del extracto bancario, no podrá ver esta relación. Esta funcionalidad no estaba implementada en Fiori. Al menos está disponible a partir de la versión 9.0.21 de esta app.
Configuración del sistema
Utilice la siguiente ruta de menú o vista de mantenimiento VC_FIEB_RETURNS (a través de SM34) para configurar el procesamiento de los débitos directos devueltos:
SPRO → Contabilidad financiera → Contabilidad bancaria → Transacciones comerciales → Transacciones de pago → Extracto bancario electrónico → Configurar procesamiento de devoluciones.
Las devoluciones de débitos directos, por regla general, se muestran con códigos de transacción comercial dedicados (códigos BTC) en el extracto bancario. Debe identificar estos códigos BTC y asignarlos a motivos de devolución internos (por ejemplo, ZR1). En mi caso, el código BTC es 108 y solo uso un código de motivo interno.
El motivo del extracto bancario externo se proporciona en la nota al beneficiario en el subcampo 34. El código de motivo de devolución en mi ejemplo es 909. El código de motivo externo se almacena en el campo FEBEP-KKREF.
Asigne dos reglas de contabilización para cada motivo de devolución interna: una regla para contabilizar el débito directo devuelto, otra para las tarifas de devolución. Además, active la casilla de verificación para restablecer la compensación del documento de pago.
La siguiente captura de pantalla muestra la configuración de las reglas de publicación (en OT83) que se usaron para este ejemplo:
Puede definir cambios automáticos adicionales de las facturas de clientes reabiertas. Puede establecer el bloqueo de reclamación/pago, cambiar el método de pago o eliminar las condiciones de pago. Si estas opciones no son suficientes, puedes usar BADI FIEB_RET_CHANGE_DOC para cambiar otros atributos de la partida abierta.
Además, puede cambiar el mandato de domiciliación bancaria para el cliente, por ejemplo, configurando su estado como cancelado u obsoleto.
El último componente de la solución es implementar el BADI FIEB_RETURNS_ADDIN (disponible a partir de la versión 4.70). El propósito de este BADI es obtener / calcular el monto de los cargos de devolución asociados con el débito directo devuelto.
Este BADI recibe el encabezado del extracto bancario (I_FEBKO), los detalles de la línea (I_FEBEP), así como una tabla con la nota al beneficiario (T_FEBRE). Esencialmente, la mejora debe analizar las líneas asociadas con la nota al beneficiario para obtener el monto de los cargos de devolución. En mi mejora, preparé un método de utilidad (es decir, GET_NOTE_TO_PAYEE_AS_STRING) dentro de la clase de implementación BADI que transforma esta tabla en una cadena. Una vez que es una cadena, puede definir una expresión regular para buscar el monto del cargo.
¡Importante! El BADI debe devolver al programa de llamada el monto de los cargos de devolución como un monto negativo. El código fuente de muestra para BADI se proporciona a continuación:
class zcl_im_fieb_dd_returns definition
public
final
create public .
public section.
interfaces if_ex_fieb_returns_addin .
protected section.
private section.
class-methods get_note_to_payee_as_string
importing
!it_febre type any table
returning
value(rv_note_to_payee) type string .
endclass.
class zcl_im_fieb_dd_returns implementation.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Static Private Method ZCL_IM_FIEB_DD_RETURNS=>GET_NOTE_TO_PAYEE_AS_STRING
* +-------------------------------------------------------------------------------------------------+
* | [--->] IT_FEBRE TYPE ANY TABLE
* | [<-()] RV_NOTE_TO_PAYEE TYPE STRING
* +--------------------------------------------------------------------------------------</SIGNATURE>
method get_note_to_payee_as_string.
" Note to payee should not be empty
if lines( it_febre ) = 0.
return.
endif.
" Prepare string representation of note to payee
field-symbols: <line> type febre.
loop at it_febre assigning <line>.
if <line> is not assigned.
return.
endif.
concatenate rv_note_to_payee <line>-vwezw into rv_note_to_payee.
endloop.
condense rv_note_to_payee.
endmethod.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_IM_FIEB_DD_RETURNS->IF_EX_FIEB_RETURNS_ADDIN~CHANGE_RETURN_CHARGES
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_FEBKO TYPE FEBKO
* | [--->] I_FEBEP TYPE FEBEP
* | [--->] T_FEBRE TYPE STANDARD TABLE
* | [<---] E_SUBRC TYPE SY-SUBRC
* | [<---] E_MSGID TYPE SY-MSGID
* | [<---] E_MSGTY TYPE SY-MSGTY
* | [<---] E_MSGNO TYPE SY-MSGNO
* | [<---] E_MSGV1 TYPE SY-MSGV1
* | [<---] E_MSGV2 TYPE SY-MSGV2
* | [<---] E_MSGV3 TYPE SY-MSGV3
* | [<---] E_MSGV4 TYPE SY-MSGV4
* | [<-->] C_RETURN_CHARGES TYPE FIEB_RET_CHARGES
* +--------------------------------------------------------------------------------------</SIGNATURE>
method if_ex_fieb_returns_addin~change_return_charges.
" Get string representation of note to payee
data: lv_note_to_payee type string.
lv_note_to_payee = get_note_to_payee_as_string( t_febre ).
if lv_note_to_payee="".
return.
endif.
" Use regular expression to fetch the amount of return fees
constants lc_fee_pattern type string value 'DRF\+(\d{5,15}.\d{2})'.
data lv_return_fee_amt type string.
find regex lc_fee_pattern in lv_note_to_payee
ignoring case
submatches lv_return_fee_amt.
" Format the resulting value
if sy-subrc = 0 and lv_return_fee_amt <> ''.
shift lv_return_fee_amt left deleting leading '0'.
replace first occurrence of ',' in lv_return_fee_amt with '.'.
else.
return.
endif.
" Return fee should be passed to calling program with a minus sign
c_return_charges-kwbtr = lv_return_fee_amt.
c_return_charges-kwbtr = c_return_charges-kwbtr * -1.
" Return reason code
c_return_charges-rrext = i_febep-kkref.
endmethod.
endclass.Notas finales
Espero que esta publicación haya brindado información útil y hayas aprendido algo nuevo. He tratado de cubrir el proceso de principio a fin, pero todavía hay áreas en las que puede profundizar y buscar mejoras adicionales. Una vez que se implemente esta funcionalidad, es posible que se enfrente a otra pregunta importante: si las devoluciones se procesan de forma totalmente automática en el extracto bancario, ¿cómo sabrá el usuario que hubo algún problema con el débito directo fallido? Por supuesto, puede configurar el cambio automático de las partidas abiertas. Pero incluso si este elemento abierto tiene un bloqueo de pago, el usuario puede preguntarse quién puso el bloqueo de pago y por qué. Una posible solución para abordar este requisito es implementar notificaciones por correo electrónico a los usuarios responsables del procesamiento de extractos bancarios. El extracto bancario en SAP ofrece una variedad de opciones de mejora y la notificación por correo electrónico no es una solución muy complicada. Tal vez lo cubra en otro blog en el futuro.
Saludos,
Bohdan Petrushchak
PD Descargo de responsabilidad. Toda la información confidencial (cuentas bancarias, nombres de empresas, etc.) utilizada en este ejemplo fue inventada. Si hay alguna coincidencia con empresas de la vida real, es puramente accidental.
