EJECUCION F110 SAP PAGOS AUTOMATICOS

1.   EJECUCIÓN.

En la primera etapa de la ejecución del proceso de pago hay que definir qué se ha de pagar, cuál será la vía de pago a utilizar, cuándo se llevará a cabo el pago, las sociedades que se tendrán en cuenta y cómo se les va a pagar.

Antes de llevar a cabo la ejecución del programa de pagos hay que realizar una serie de verificaciones en el registro maestro de deudores y acreedores. Se debe comprobar que en ellos se ha indicado la vía de pago que se utilizará en la ejecución así como la existencia de otros datos imprescindibles como el dato de la cuenta bancaria donde se realizará el pago.

Indicar que desde los registros maestros se pueden bloquear deudores y acreedores para que el sistema no los tenga en cuenta a la hora de la ejecución del programa de pagos.

Respecto a las vías de pago, también se pueden introducir a la hora de registrar las partidas abiertas y en caso de no coincidir con la que existe en el registro maestro del deudor o del acreedor prevalecerá la de la partida abierta.

La transacción para la ejecución del programa de pagos es: Finanzas – gestión financiera – acreedores – operaciones periódicas – pagos. (F110):

Cualquier ejecución del programa de pagos se identifica mediante dos campos:

-       Fecha de ejecución: se recomienda que coincida con la fecha real de la ejecución del programa. Sirve principalmente como identificación de la ejecución del programa.

-       Identificación: se utiliza para diferencias las ejecuciones de los programas con la misma fecha de ejecución.

1.1    EJECUCIÓN: Parámetros.

En la pestaña parámetros se deberán indica la siguiente información.

-       La fecha de contabilización que será la fecha en que el libro mayor se actualizará con las contabilizaciones. Aparece como valor propuesto la fecha del día de ejecución.

-       Todos los documentos introducidos hasta la fecha Documentos creados hasta se incluirán en la ejecución de pago.

-       Se indicarán las sociedades a tener en cuenta. Si se introducen varias sociedades, éstas irán separadas por una coma sin espacio entre ellas. Si por el contrario introducimos un rango, la primera y la última sociedad de dicho rango irán entre paréntesis, siempre teniendo en cuenta que todas las sociedades incluidas deberán estar en el mismo país.

-       Se introducirá también la vía de pago a utilizar en la ejecución actual. Si se indican varias el orden en que se introduzcan determinará la prioridad que les otorgará el programa de pagos en la ejecución. La vía introducida primero será la primera en prioridad, la siguiente será la segunda en prioridad, etc. El sistema realiza el pago utilizando la prioridad más alta posible después de la verificación.

-       En cuentas se señalarán aquellas cuentas auxiliares de deudores y/o acreedores se van a tratar.

Una vez grabados los parámetros, la pestaña de Status se actualiza tal y como lo hará en cada paso de la ejecución del programa.

1.2        EJECUCIÓN: Planificación y ejecución de la propuesta de pago.

Grabados los parámetros se ha de llevar a cabo la planificación de la propuesta. Para ello iremos al menú Tratar – propuesta – planificar, o bien botón propuesta en la barra de aplicaciones para introducir la fecha de inicio y si la ejecución es inmediata o en fondo (ejecutaremos de forma inmediata).

En la ejecución de propuesta, el programa selecciona documentos y cuentas con posiciones pendientes de pago. Para ello utiliza criterios de búsqueda que el usuario especificó cuando introdujo los parámetros. A continuación, agrupa estas posiciones por pagos y asigna las vías de pago y los datos bancarios que se utilizarán. Si el sistema no puede encontrar una vía de pago válida o datos bancarios válidos o si una posición está bloqueada para el pago, añadirá estas posiciones a la lista de excepciones.

Una vez finalizada la ejecución de la propuesta, el sistema genera dos informes: la lista de propuestas de pago y la lista de excepciones que el usuario puede tratar realizando las modificaciones oportunas antes de ejecutar el programa.

1.3    EJECUCIÓN: Listas de propuesta y de excepciones.

Tras ejecutar la planificación el sistema nos genera dos listas que podemos visualizar en el menú Tratar – propuesta – Visualizar, o desde el botón Visualizar propuesta de la barra de aplicaciones. 

 En la lista de propuesta de pagos aparecen los interlocutores comerciales y los importes que se deben pagar o recibir. En función de la estructura de líneas que los usuarios utilizan para la pantalla, pueden visualizarse los números de documento y los descuentos por pronto pago asociados

Las facturas que coinciden con los parámetros de pago especificados pero que, por algún motivo, no se pueden pagar, aparecen en la lista de excepciones.Si los usuarios seleccionan el log adicional, la lista muestra por qué no se puede pagar la factura.   

.Existen varias formas de configurar un bloqueo de pago

Si surge un problema durante el proceso de verificación de facturas, normalmente se bloquea el pago de la factura. Este tipo de bloqueo puede configurarse de modo que el bloqueo sólo se pueda eliminar durante el proceso de verificación de facturas.

Si existe un motivo por el que no se debería pagar a un acreedor, el usuario puede crear un bloqueo de pago en el registro maestro. El bloqueo creado en el registro maestro evita que se pague ninguna de las facturas del acreedor. También se puede configurar el bloqueo de modo que se tenga que eliminar manualmente en el registro de datos maestros antes de poder procesar un pago.

Cuando se introduce una factura de acreedor, se puede bloquear una factura para el pago. El tipo de bloqueo de pago determina si se puede eliminar durante la propuesta de pago.

Se pueden definir bloqueos de pago adicionales en el sistema. Los usuarios también pueden especificar si el bloqueo de pago se puede eliminar cuando se procesen los pagos.

1.4    EJECUCIÓN: Tratamiento de la propuesta de pago.

El usuario puede tratar la propuesta de pago y la lista de excepciones desde el menú Tratar – propuesta – tratar, o bien desde el botón Tratar propuesta de la barra de aplicaciones.

El usuario puede modificar visualizar los detalles de un pago particular para modificar sus condiciones de pago y añadir o quitar un bloqueo para el pago.

Los usuarios pueden asignar un responsable para el deudor o acreedor, para lo cual deberán introducir la clave del responsable en losdatos maestros de deudor o acreedor. Al tratar la propuesta de pago, se puede introducir la clave de un responsable específico para mostrar sólo los pagos de deudor y acreedor asignados a ese responsable:

En la primera pantalla de la transacción de tratamiento, se visualiza un resumen de todos los pagos propuestos por el programa, como muestra la siguiente imagen:

Si hace doble clic en un pago, podrá visualizar una lista de todas las partidas abiertas que deberán pagarse junto con el pago en cuestión. Se puede modificar el bloqueo de pago y el descuento por pronto pago de esas partidas abiertas.

También puede asignar la partida a un pago existente distinto o crear un nuevo pago seleccionando una vía de pago y el banco propio.

1.5    EJECUCIÓN: Ejecución de pago.

Una vez tratada y grabada la propuesta de pago, la ejecución de pago utiliza las modificaciones como base para los pagos reales.

Hasta este punto, no se ha realizado ninguna contabilización. Los documentos incluidos en esta ejecución de pago se han “bloqueado” para cualquier otra contabilización; es decir, una factura pagable en la ejecución de pago actual se bloquea para evitar su pago manual o su pago, o en una ejecución de pago distinta.

Para llevar a cabo la ejecuciones deberá ir a menú tratar – pago – planificar o bien utilizar el botón Ejecución pago en la barra de aplicaciones.

En esta etapa se crean los documentos de pago, se compensan las partidas abiertas y se realizan contabilizaciones en el libro mayor y el auxiliar:

El programa de pagos contabiliza automáticamente los pagos y las correspondientes contabilizaciones.

Algunos países requieren que los documentos de pago no se contabilicen antes de que se efectúe la liquidación real, es decir, no antes de que el pago se refleje enel extracto de cuenta. En la configuración de las vías de pago correspondientes a dichos países, se puede activar el indicador Crear sólo orden de pago. En este caso, el programa de pagos no contabilizará documentos de pago. En vez de esto, se genera una orden de pago que contiene toda la información relativa a losdocumentos pagados. En caso de que el pago aparezca en el extracto de cuenta, el documento de pago se generará al introducir la orden de pago. Hasta ese momento, las partidas pagadas se bloquearán para el resto de transacciones de compensación.

La clase de documento para el registro del pago se define en las especificaciones de vías de pago de cada país. Para los pagos multisociedades se puede introducir una clase de documento adicional que se utilizará para las contabilizaciones de compensación. Las dos clases de documento tienen que parametrizarse con la asignación de números interna.

En los documentos de la ejecución de pago se indica la fecha y el número de identificación de la ejecución en el texto de cabecera del documento.

La fecha valor del documento de compensación se calcula al añadir los días hasta fecha valor a la fecha de contabilización. Los días hasta fecha valor dependende la vía de pago, el banco, la cuenta, la moneda y el límite de la cuenta. Si no se introduce ningún valor, el sistema utilizará la fecha de contabilización como fecha valor. Para calcular la fecha valor de los pagos por cheque, en los datos maestros se puede introducir una duración de la gestión de cobro de cheques. Esta duración presenta una prioridad superior a la de los días hasta fecha valor en el caso de los cheques.

Si los pagos se realizan por divisiones individuales, la contabilización bancaria se efectúa para la división a la que pertenecen las posiciones pagadas. Si los pagos no se realizan por división específica, se puede especificar la división para las contabilizaciones bancarias. En el resto de casos, las contabilizaciones en cuentas transitorias se efectuarán sin referencia a las divisiones.

2.   IMPRESIÓN DE MEDIOS DE PAGO.

La ejecución de impresión inicia el programa de impresión que realiza lo siguiente:

-       Transfiere los medios de pago, los avisos de pago y la lista adjunta a la gestión de impresión.

-       Transfiere los datos de pago ISD a la gestión ISD.

-       Crea IDOC’s para los pagos selecciondos que se podrán transferir al subsistema EDI.   

Variantes para el programa de impresión

Un programa de impresión se asigna a cada vía de pago por cada país cuando se configura. Para que el programa pueda ejecutar el programa de impresión, deberá existir por tanto como mínimo una variante.

Las variantes comprenden una serie de criterios de selección que se utilizan para separar datos en el registro de impresión. Para cada variante que se haya llamado desde un programa de impresión de soporte de datos, se generarán órdenes de impresión separadas en la gestión de impresión.Los usuarios pueden accedera esta clase de órdenes para su impresión. Las variantes también contienen especificaciones de impresión.

Los campos Fecha de ejecución e identificador se pueden dejar vacíos en las variantes y en ese caso, el programa al ejecutar trasladará automáticamente dichos valores desde la ejecución actual.

En las parametrizaciones de configuración del programa de pagos, debe asignar formularios de medios de pago a la sociedad pagadora o bien a cada una de las vías de pago de cada sociedad.

El Sistema SAP proporciona formularios estándar que se podrán modificar en función de las necesidades específicas a nivel país.

EDI y avisos de pago.

En la ejecución de pago de pago, el primer programa de impresión que se ejecuta es RFFOEDI1.

Este report marca todos los pagos que están seleccionados para EDI, crea IDOC’s SAP para ellos, y los transfiere al subsistema EDI. Posteriormente el subsistema EDI convierte los IDOC’s en datos EDI que pueden enviarse al banco.

Los avisos de pago se pueden enviar por correo o por EDI, dependiendo de si el deudor o acreedor puede recibir mensajes EDI.

ISD – Intercambio de soporte de datos.

Con el intercambio de soporte de datos se crea un fichero que contiene toda la información de pago relevante de acuerdo con la normativa bancaria del país en cuestión.

El fichero ISD se almacena en la gestión de soporte de datos y se puede hacer un download del mismo a un soporte de datos. También se puede imprimir una nota adjunta ISD. Posteriormente el soporte de datos y la nota adjunta ISD se enviarán al banco.

El intercambio de soporte de datos solo se puede utilizar con vías de pago en que el medio de pago se envía al bancocomo por ejemplo, una transferencia, para que el banco continue con el procesamiento. No se puede usar en las vías de pago en las que el medio de pago se envía al acreedor o deudor (como un cheque).

Para utilizar ISD para una vía de pago específica, solo hay que seleccionar el campo Intercambio de soporte de datos en la variante. Para generar ficheros ISD independientes para cada banco propio, se deberá introducir una variante para cada banco propio.

El programa de impresión de cheques es RFFO “xx”_“y”, donde “xx” generalmente indica el país e “y” contiene definiciones adicionales para el formulario. Los programas siguientes se expiden de forma estándar:

-       RFFOAT_L: Medio de pago Austria – Cheques/ transferencia exterior/ ISD interior + exterior

-       RFFOD  S: Medio de pago internacional – Cheques (sin gestión de cheques)

-       RFFOD  T: Medio de pago internacional – Procedimiento cheque-letra

-       RFFOES_T: Medio de pago España – Transferencia ISD, cheques bancarios

-       RFFOUS_C: Medio de pago internacional – Cheques (con gestión de cheques)

Hay que identificar la ejecución de pago, el banco propio y el lugar en que se imprimen los cheques y los documentos adjuntos. Los cheques se pueden imprimir con números de cheque predefinidos (con gestión de cheques) , o bien el número de documento también puede utilizarse como número de cheque (sin gestión de cheques).

En la configuración de vía de pago de país (ver capítulo anterior) puede indicarse un programa de impresión por cada una de las vías de pago. Y en el área de datos de formulario, se puede definir el tipo de formato del formulario y el formulario de medio de pago que se utilizará.

El programa de impresión:

-       Asigna números de cheque a documentos de pago

-       Actualiza los documentos de pago y los documentos de factura originales con la información de cheques

-       Imprime cheques y documentos adjuntos

Si se usa la gestión de cheques, hay que utilizar lotes de cheques para imprimir los cheques.

Los cheques se gestionan por lotes. Si utiliza cheques ya numerados por el banco, se especifican los rangos de números de cheques en los lotes. Si no, inicie la numeración de los cheques desde 1.

Los lotes de cheques se utilizan para los pagos manuales y automáticos. Por motivos de control, se recomienda utilizar un lote independiente para cada tipo de pago. 

3.   PMW: PAYMENT MEDIUM WORKBENCH.

Payment Medium Workbench se puede utilizar como alternativa a los programas estándar de impresión de medios de pago. En este apartado vamos a ver una pequeña introducción a esta herramienta del sistema. Los medios de pago se pueden crear mediante los programas de impresión estándar RFFO* o mediante PMW.

Anteriormente, los formatos de medios de pago se programaban en unos 60 programas de medios de pago estándar (RFFO*). En Payment Medium Workbench, sin embargo, estos formatos se definen fuera del programa de medios de pago pudiéndose cambiar con facilidad sin realizar modificaciones, creando nuevos formatos sin necesidad de tener experiencia de programación si se utiliza el motor ISD.

Hasta ahora, los avisos de pago también se creaban con los programas RFFO*. En Payment Medium Workbench, los avisos de pago se crean con el nuevo programa RFFOAVIS_FPAYM emitiéndose todos los avisos en un fichero de impresión permitiendo mejores opciones de clasificación para los avisos. 

Cada vía de pago individual se puede convertir a los formatos de medios de pago de PMW. Esto significa que se pueden utilizar los programas de medios de pago estándar RFFO* y los nuevos formatos de medios de pago de PMW en el mismo sistema, e incluso en la misma ejecución de pago.

Pasos de conversión para una vía de pago.

Una vía de pago se convierte en vía de pago PMW en 4 pasos:

1.    Hay que activar el botón de selección utilizar PMW en la configuración  de vía de pago / país para indicar que se quiere usar la PMW y se hay que asignar a la vía de pago el formato de medio de pago, es posible que también sea necesario introducir un suplemento de formato.

Un formato de medio de pago contiene diversos campos que se completan con contenido de SAP. Este proceso se denomina asignación y puede realizarse de dos maneras:

- Con módulos de función programada, o

- Mediante el motor ISD (Intercambio de soporte de datos).

El formato del medio de pago se define mediante tablas en las que, entre otras cosas, se asignan los eventos de verificación desde el programa de medios de pago a los módulos de función correspondientes para el formato:

- El evento de verificación 00 permite influir en la secuencia de clasificación de los datos de pago y, por lo tanto, en la selección para la creación de medios de pago.

- El evento de verificación 05 le permite completar otros campos de referencia de formato específico en los datos de pago. Puede usar estos valores durante la creación de medios de pago en eventos de verificación 20, 30 y 40, y para estructurar el destino de utilización (Customizing para destino de utilización).

- El evento de verificación 10 permite controlar otros parámetros de formato que se definen en una estructura en Customizing  para crear los formatos de medios de pago y que se ofrecen en la pantalla de selección del programa de medio de pago genérico.

- El evento de verificación 20 permite crear una cabecera para el medio de pago. Las siguientes estructura de importación están disponibles para completar la cabecera: I_FPAYH (datos de pago), I_FPAYHX (Customizing de pago) y I_FORMAT_PARAMS (otros parámetros de formato).

- Se puede utilizar el evento de verificación 25 para controlar si se ha iniciado un nuevo medio de pago. Puede elegir crear un nuevo medio de pago físico (nuevo archivo) o un nuevo medio de pago lógico (nueva cabecera; no un nuevo archivo).

El Motor de Intercambio de Soporte de Datos (MISD) permite definir los formatos de archivos que cumplen con los requisitos del banco para el intercambio  de soporte de datos. Esto es especialmente importante porque no se definen estándares internacionales o regionales. Algunos países ni siquiera tienen sus propios estándares nacionales, lo que significa que el archivo tiene que cumplir con los estándares específicos del banco. El MISD permite definir nuevos formatos y cambiar los existentes de forma lexible y fácil, sin necesidad de ningún conocimiento de programación ABAP.

2.    Después se le asigna a la vía de pago información sobre la creación de datos del destino de utilización, en la carpeta destino de utilización según origen  (también se puede acceder desde: IMG – gestión financiera – contabilidad de deudores y acreedores – operaciones contables – salida de pagos - salida de pagos automática – medios de pago – parametrizar formatos del Payment Medium Workbench – asignar formato de medio de pago y destino de utilización).

Una vía de pago de PMW siempre tiene asignado un formato de PMW y un modelo de contenido para el destino de utilización.   

.Cada formato de PMW (con o sin suplemento) tiene hasta tres tipos de campos de texto para información de referencia (cuadro de texto de la izquierda imagen anterior, Formato de PMW)

-       Tipo 1: Información de facturación (destino de utilización clásico).

-       Tipo 2: Referencia interna (si se devuelve el medio de pago).

-       Tipo 3: Referencia externa (para el interlocutor comercial).

El contenido del destino de utilización se define en un modelo de contenido, independiente del formato, en el Customizing o bien mediante un módulo de funciones. En el Customizing, se puede definir el contenido en función del idioma para garantizar que los interlocutores comerciales siempre reciban el texto en su propio idioma.

El modelo de contenido (en destino de utilización en la ilustración) proporciona información (tal como se muestra en la imagen) a los campos de referencia cuando se crea el medio de pago.

3.    En la vía de pago a nivel sociedad se asigna el formulario para la nota adjunta.

4.    Para programar automáticamente los medios de pago de PMW en el programa de pagos, se deben definir variantes de selección: IMG – gestión financiera – contabilidad de deudores y acreedores – operaciones contables – salida de pagos - salida de pagos automática – medios de pago – parametrizar formatos del Payment Medium Workbench – crear y asignar variantes de selección.

La granularidad se especifica en la definición del formato de medio de pago y determina cómo se van a emitir los medios de pago por separado en las  agrupaciones de pagos. En general, una agrupación de pagos corresponde a un fichero de pago.

Ejemplo: Si se selecciona sociedad y banco propio como nivel de granularidad, se creará una agrupación de pagos para cada combinación de sociedad y banco propio.

Como mínimo se debe definir una variante de selección en el programa de medios de pago genérico SAPFPAYM para cada agrupación de pagos posible. El programa de medios de pago se tratará con todas las variantes definidas.

La granularidad no se puede reducir, para los formatos de PMW suministrados con el sistema. Esto se debe a que la granularidad suministrada por SAP se basa en las necesidades de formato (generalmente especificadas por los bancos).

Una vez lanzada la creación de los medios de pago, se procesan las vías de pago individuales y se inician los siguientes programas.

• Con una de las vías de pago estándar, el programa RDDO* asignado se inicia con las variantes definidas en la ejecución de pago. El programa genera los medios y de pago y los avisos.
• Con una vía de pago PMW se inician los nuevos programas de Paymente Medium Workbench.

Pasos en el proceso de PMW.

Cuando se crean medios de pago para un pago con vía de pago PMW se inicia el programa SAPFPAYM_SHEDULE.

Dicho programa lleva a cabo un servicio previo procesando los datos suministrados de nuevo por la ejecución de pago específicamente para PMW:

• Los pagos se clasifican de acuerdo con el formato de PMW y otros campos específicos del formato.
• Las agrupaciones de pagos se crean en función del nivel de granularidad (normalmente más tarde se crea un fichero de medio de pago para cada agrupación).
• Se forma el destino de utilización.

El programa de pagos SAPFPAYM y el programa de avisos RFFOAVIS_FPAYM se inician en función de los datos generados por el programa de pagos.

• El programa RFFOAVIS_FPAYM genera todos los avisos necesarios y los avisos de saldo cero.
• El programa SAPFPAYM se inicia con todas las variantes que se definen en las agrupaciones de pago relevantes en Customizing. Este programa genera los medios de pago para las vías de pago de PMW, las notas adjuntas de los medios de pago, un log de errores y la lista adjunta.

4.   VERIFICACIÓN DE SALDO DEBE.

En algunos casos, la ejecución de pago puede conllevar que se realicen pagos incluso a pesar de que la cuenta tenga un saldo Debe.

En la imagen 23 se muestra un ejemplo de este tipo. Una cuenta de acreedor contiene una factura de 98€ y un abono de 100€. La factura contiene una vía de pago para las salidas de pagos. Pero no se ha definido ninguna vía de pago para la entrada de pagos ni en el registro maestro ni en el abono.

La propuesta de pago añade el abono a la lista de excepciones, puesto que no se puede pagar sin una vía de pago apropiada. Sin embargo, la factura de 98€ se paga, porque tiene asignada vía de pago.

Hasta ahora, para bloquear pagos a personas que deben dinero a la empresa, la propuesta de pago tenía que procesarse manualmente.

La verificación de saldo Debe se puede realizar una vez creada una propuesta de pago. La verificación compensa todas las partidas del Debe vencidas sin una vía de pago recibido con los pagos propuestos. Si el saldo Debe o el saldo Haber resultante es menor que el importe de pago mínimo, los pagos se añadirán a la lista de excepciones y la cuenta se colocará en una lista de cuentas bloqueadas. Las cuentas relevantes siguen bloqueadas incluso si se borra la propuesta de pago. Esto significa que los pagos para las cuentas bloqueadas no se realizan en la ejecución de pagos, los bloqueos no se eliminan hasta que se vuelve a crear otra propuesta con la misma identificación.

Las cuentas bloqueadas se pueden liberar manualmente.

La verificación de saldo Debe se realiza con el programa RFF110SSP, c

5.   AUTOMATIZACIÓN DEL PROCESO DE PAGO.

El programa RFF110S se utiliza para el programa de pagos SAPF110S en segundo plano. La pantalla de selección para este programa indica esencialmente los mismos parámetros que la transacción F110. Esto significa que se pueden grabar estos parámetros en una variante y programar que el programa RFF110S se ejecute periódicamente con esta variante:

·      Es necesario utilizar variables de selección para adaptar automáticamente los datos de tiempos a la fecha de ejecución periódica.

·      El programa RFF110S, a su vez, puede ejecutar automáticamente cuatro programas adicionales de forma consecutiva.

-       Para evitar la salida de pagos a pesar de un saldo Debe vencido, debería programarse primero el programa RFF110S como una ejecución de propuesta. A continuación, debería llamarse automáticamente al programa RFF110SSP para realizar la verificación de saldo debe.

-       Después de la verificación de saldo Debe, se vuelve a llamar automáticamente al programa RFF110S. Esta vez, sin embargo, como ejecución de actualización con posible generación de los medios de pago.

Se puede programar que los programas se ejecuten de forma periódica mediante la gestión de Jobs o Schedule Manager.

El estatus de la ejecución es visible en la transacción F110 desde el momento en el que el report RFF110S crea los parámetros.

Shedule Manager.

Puede utilizarse para automatizar las actividades recurrentes periódicamente.

Se puede iniciar con la transacción SCMA o directamente desde el menú mySAP – Finanzas – gestión financiera – acreedores – operaciones periódicas - SCMA - Schedule Manager.

La lista de tareas es el elemento principal y representa un conjunto de actividades que se deben llevar a cabo durante un período de tiempo. El sistema proporciona una serie de instrucciones que se pueden mostrar u ocultar para ayudar en la creación de tareas.

Se pueden definir cuatro tipos diferentes de tareas en el plan de tareas: programa con variante, notas, transacción, definiciones de proceso.

El usuario puede utilizar Schedule Manager y las funciones de programación de programas para sus procesos de pago.

ERRORES O NOTAS EN LA EJECUCION DEL PROGRAMA DE PAGOS SAP

NOTAS EJECUCION PROGRAMA DE PAGOS AUTOMATICOS SAP

·       En el pago de factura simple deben verificarse: partida vencida-no bloqueada-via de pago en partida o en el maestro de acreedor,saldo acreedor,cuenta bancaria en el maestro

·       En el caso de una partida sin la via de pago busca el maestro de acreedor y si no la tiene no la tomara para el pago

·       En la propuesta se puede reasignar la via de pago

·       Una factura bloqueada no puede pagarse directamente

·       Si el tipo de bloqueo es modificable en propuesta se podrá quitar y pagar la factura

·       Si el tipo de bloqueo no es modificable en propuesta no se podrá pagar

·       Si una factura ya está tomada en una propuesta no podrá pagarse por otra propuesta a menos que se borre la propuesta original.

·       Una vez borrada la propuesta se puede proceder al pago

·       Las factura también pueden pagarse con la retención si toda la retención está correctamente configurada con la cuenta creada

·       Se puede pagar una factura con una abono siempre que el abono sea inferior a la factura .

·       Si el abono es superior a la factura no nos dejará pagar

·       El Saldo acreedor de las facturas y abonos permite el pago

·       Si la partida tiene otra via de pago diferente a la propuesta no la tomará

·       Logicamente se pueden pagar facturas de varios proveedores si cumple todos los requisitos

·       Si un proveedor figura como receptor alternativo del pago desviará el pago a la cuenta bancaria de otro proveedor

·       Si un proveedor es cliente puede pagar facturas del proveedor y netear con las del clientes si cumple todos los requisitos

·       También se pueden pagar facturas de varias sociedades si son correctamente seleccionadas en los parametros y separdas por una coma o entre parentesis

·       Se pueden pagar factuas en otra moneda si tenemos correctamente configurado el banco propio adaptado a una moneda no local y el programa de pagos tiene activado pago en moneda extranjera.

·       Se pueden pagar y cobra factura con descuento por pronto pago si las condicioens de pago son correctas y las cuentas creadas.

·       Se pueden pagar facturas con diferencias de cambio si tenemos la cuenta creada , si el tipo de cambio en el pago es diferente a la factura y si el programa lo tiene activado.

·       Si dentro de la parametrizacion el importe de pago supera el limite del banco buscará otro banco propio que lo permita según orden de jerarquía

·       Si tenemos correctamente parametrizada la via de cobro de domiciliados podemos realizar un cobro domiciliado y además en el maestro del cliente tiene que tener la cuenta y el flag de cobro domiciliado.

·       En la configuracion de la via de pago de la sociedad si desactivamos interlocutor extranjero no se podrá pagar prov.extranjeros

·       En la configuracion de la via de pago de la sociedad si activamos interlocutor extranjero si se podrá pagar prov.extranjeros

·       Si desactivamos el banco extranjero en la via de pago sociedad no nos dejara pagar por banco extranjero

·       Si activamos el banco extranjero en la via de pago sociedad si nos dejara pagar por banco extranjero

·       Si se activa pago individual se paga por cada factura y además puede cambiar de banco propio si supera el limite

·       Creacion de propuesta y pago automatico en job por la F110S PLANIFICADA

·       Si el proveedor tiene alguna modificación pendiente de confirmar en el maestro no podrá pagarse

·       No podrá pagarse si el proveedor está bloqueado para las contabilizaciones

·       No podrán ejecutarse dos propuestas de pago simultaneas con la misma via de pago

El importe disponible de pago en los bancos propios no se actualiza automáticamente.

El Modulo SAP FI es el de Sap Finanzas , con el CURSO SAP FI aprenderás todos los procesos financieros en SAP.

Dentro del Area Financiera de SAP también hay otros módulos como SAP CO de Controlling y SAP TRM que corresponde a Tesorería.

Estudiar un CURSO SAP FI o MASTER SAP FI te posiciona en multitud de ofertas laborales ya que es el Módulo SAP más demandado ya que todas las Empresas que usan SAP siempre lo tendrán implementado.

El CURSO SAP FI está compuesto por varios submódulos como son :

-SAP GL : Contabilidad General

-SAP AP : Cuentas a Pagar

-SAP AR:  Cuentas a Cobrar

-SAP BL : Contabilidad Bancaria

-SAP AA : Activos Fijos

Este CURSO SAP FI te proporcionará una visión completa del módulos SAP FI Finanzas en SAP S/4 Hana

Aprenderás desde cero el módulo financiero contable al completo según la Certificación Oficial SAP C_TS4FI_2020

MÁSTER SAP S/4 Hana Finanzas donde de ven todos los procesos del area financiera:

Contabilidad General-Cuentas a Pagar-Cuentas a Cobrar-Contabilidad Bancaria-Activos Fijos-Cierre Contable e Informes Financieros.

TEMA 1 Resumen de SAP S/4HANA

TEMA 2 Configuración central de Gestión financiera (FI)

TEMA 3 Datos Maestros

TEMA 4 Control de documentos

TEMA 5 Control de contabilización

TEMA 6 Compensación de documentos financieros

TEMA 7 Pagos automáticos

TEMA 8 Programa de reclamación

TEMA 9 Correspondencia

TEMA 10 Operaciones de libro mayor especiales

TEMA 11 Entrada preliminar

TEMA 12 Validaciones y sustituciones

TEMA 13 Archivo de datos en FI

TEMA 14 Antigüedad de datos en FI

TEMA 15 Estructuras organizativas Activos Fijos

TEMA 16 Datos maestros Activos Fijos

TEMA 17 Movimientos de activos fijos

TEMA 18 Valoración y operaciones periódicas Activos

TEMA 19 Sistema de información

TEMA 20 Transferencia de datos antiguos

TEMA 21 Resumen del cierre financiero y parametrizaciones básicas

TEMA 22 Balances financieros

TEMA 23 Activos fijos y capital circulante

TEMA 24 Deudores y acreedores

TEMA 25 Periodificaciones

TEMA 26 Actividades de cierre técnicas, organizativas y documentales

TEMA 27 COCKPIT DE CIERRE FINANCIERO

TEMA 28 Reconciliación intercompañías

TEMA 29 REPASO FINAL CURSO

CURSO SAP FI