La contabilización de Remesas de Pago se lleva a cabo mediante procesos que cambian el estado de la remesa y de los pagos incluidos en ella y crean los asientos contables necesarios.
Configuración
Como los procesos actúan directamente sobre los pagos, es necesario que éstos estén configurados correctamente. Para ello es necesario definir los distintos estados posibles del concepto Pago y los procesos de cambio de estado en la ventana de Tipos de Conceptos, como se explica en el tema Contabilización de Pagos.
A continuación se procede a configurar los estados y procesos del concepto Remesa de Pago.
Estados
Se han definido los estados:
•1 (EL) En elaboración. Estará en este estado hasta que se termine de preparar.
•3 (COM) Completada. Pasará a este estado cuando se prepare y esté lista para ser enviada.
•5 (ENV) Enviada. Pasa a este estado cuando se envía al banco y los efectos pasan al estado remesado.
•7 (ECO) Confirming generado. Pasa a este estado cuando se ha enviado el Confirming al banco. El proceso también genera el fichero a enviar.
•10 (CON) Contabilizada. Estado final para las remesas de Pago, independientemente del tipo de efecto utilizado en la remesa.
Procesos
Los procesos de cambio de estado para Remesas de Pago se definen estableciendo:
Estado1: Estado inicial en el que debe encontrarse la remesa para que pueda transformarse mediante este proceso.
Estado2: Estado final de la remesa tras la ejecución del proceso.
Descripción: Texto identificativo del proceso, que se mostrará en el menú concepto actual, ventana de procesos, etc.
Javascript: Nombre del programa xjs que se ejecutará para llevar a cabo el cambio de estado. Si se deja en blanco, se ejecutará por defecto el programa pro.xjs, que es el proceso genérico de cambio de estado. Este programa únicamente lleva a cabo el cambio de estado y graba en el Registro de usuarios un nuevo registro indicando que el proceso ha sido ejecutado.
Es posible indicar dos programas separados por una coma, en cuyo caso se ejecutarán consecutivamente en el orden indicado.
Si el proceso crea un asiento, en Cuenta 1 y Cuenta 2 se especifican las cuentas contables sobre las que se harán los apuntes.
Cuenta 1 (Debe): Si no se especifica, se emplea por defecto la cuenta cypcueide, que es la cuenta contable del Proveedor, leída de la ficha de cada pago.
Cuenta 2 (Haber): Si no se especifica, se emplea por defecto la cuenta cypbanide, que es la cuenta de banco / caja de la remesa.
Se han definido los siguientes procesos de cambio de estado:
Completar: Aplicable a las remesas en estado 1(EL) a las que pasa al estado 3(COM), ejecutando el programa rpa_cerrar.xjs que, además de cambiar el estado de la remesa, realiza una serie de comprobaciones.
Enviar: Aplicable a las remesas en estado 3(COM) a las que pasa al estado 5(ENV). El programa ejecutado es remefectos.xjs, que, además de cambiar el estado de la remesa, lleva a los pagos al estado 7(RE), remesado.
Generar Confirming: Aplicable a las remesas en estado 3(COM), a las que pasa al estado 7(ECO). Se ejecutan dos programas consecutivamente:
1.remcontaefe.xjs: además de hacer el cambio de estado, crea el asiento contable contra las cuentas indicadas en los campos Cuenta 1 y Cuenta 2. En Cuenta 2 se ha introducido cueefeide, que es la cuenta de efectos comerciales a pagar del proveedor de cada pago. Al quedar en blanco Cuenta 1, el proceso emplea por defecto la cuenta cypcueide, que es la cuenta contable del Proveedor, leída de la ficha de cada pago.
2.rpa_confirming.xjs: este programa crea un archivo con los datos de los pagos para su envío al banco de cargo. El formato del archivo es distinto para cada entidad bancaria. Finalizado el proceso, se abre la ventana del editor de texto mostrando dicho archivo y la ventana de presentación preliminar, mostrando el informe con los datos exportados.
Contabilizar remesa: Aplicable a las remesas en estado 5(ENV), que van a ser pagadas directamente al proveedor. El programa ejecutado es remconta.xjs que, además de hacer el cambio de estado, crea un asiento contable contra las cuentas indicadas en Cuenta1 y Cuenta2. Al dejar estos dos campos en blanco, remconta utiliza las cuentas por defecto: cypcueide para Cuenta 1 (Debe) y cypbanide para Cuenta 2 (Haber), que es la cuenta contable del banco de cada remesa.
Contabilizar Confirming: Aplicable a las remesas en estado 5(ENV), a las que pone en estado 10(CON). El programa ejecutado es también remconta, aunque la Cuenta 1 es cueefeide.
Procedimiento
La inclusión de pagos en una remesa puede realizarse:
•Seleccionando los pagos en la ventana principal y aplicándoles la acción REMESAR efectos, con lo que se crea una nueva remesa y los efectos seleccionados quedan incluidos en ella.
•Añadiéndolos a una remesa existente, como se explica en el tema Remesa de Pago.
Para explicar mediante un ejemplo el proceso de contabilización de las remesas de pago, se distinguirá entre pago por transferencia y por Confirming.
Transferencia
Partiendo de una remesa en estado 1(EL), se ejecutan los procesos de cambio de estado disponibles en cada caso:
Al ejecutar el proceso Enviar remesa al banco, el programa remefectos.xjs cambia la remesa al estado 5(ENV) y pone a cada uno de los pagos en estado 7(R), que es el estado que se configuró para los pagos como Pago Remesado.
Ya en estado 5(ENV), el proceso disponible para la remesa es Contabilizar. Al hacer clic en Contabilizar remesa, se abre el diálogo del programa remconta.xjs, en donde se pueden determinar la fecha, serie y descripción del asiento y la descripción de los apuntes. En la parte inferior aparecen las cuentas especificadas en Cuenta 1 Cuenta 2.
Al ejecutar este proceso, la remesa pasa al estado 10(CON), los pagos pasan al estado 10 (P) y se genera el asiento siguiente, en el que se traspasan los pagos desde la cuenta contable de cada proveedor a la cuenta del banco de la remesa.
Confirming
Este ejemplo parte de una remesa, ya en estado 3 (completada), preparada para ejecutar el proceso Generar Confirming.
Tal como se ha configurado el concepto Remesa de Pago, el proceso Generar Confirming ejecuta consecutivamente dos programas: remcontaefe (efectos a cartera) y rpa_confirming (Generar confirming)
En primer lugar, al ejecutarse remcontaefe, se abre su ventana de diálogo en donde se pueden determinar la fecha, serie y descripción del asiento y la descripción de los apuntes. En la parte inferior aparecen las cuentas especificadas en Cuenta 1 Cuenta 2.
La ejecución de este programa cambia el estado de la remesa a 7(ECO) y a los pagos por el estado 7(R). Se genera el asiento siguiente, en el que se traspasan los pagos desde la cuenta contable de cada proveedor (400) a su cuenta de efectos comerciales a pagar (401).
A continuación se abre el diálogo del programa rpa_confirming, que crea un archivo con los datos de la remesa para su envío al banco y un informe sobre los datos exportados. El formato del archivo depende de la entidad bancaria, dato que el programa toma de los cuatro dígitos correspondientes al banco del IBAN de la remesa.
Por defecto, rpa_confirming guardará el fichero en la carpeta de ficheros temporales de Sigrid, pero es posible seleccionar otro destino pulsando el botón Examinar. En cuanto al nombre del fichero, si no se especifica, el programa lo construirá automáticamente concatenando el código de la remesa, nombre del banco y fecha de trabajo en el formato aaaammdd.
Antes de iniciar la exportación de datos, el programa comprueba una serie de datos imprescindibles para el Confirming:
•CIF y Razón Social del ordenante, que se introducen en los Parámetros Generales de la empresa, apartado Datos Fiscales.
•En el caso de transferencia, datos de domiciliación bancaria del pago (IBAN) del ordenante. Se introduce en la tabla auxiliar Cuentas Bancarias, aunque puede ser modificado en la remesa.
•Fecha de la remesa.
•CIF del proveedor de cada pago. Debe ser un CIF válido.
•Cuenta de banco de cada pago o, en su defecto, del proveedor.
•Si un proveedor requiere certificado, se comprobará su fecha de caducidad.
•Subcontratistas que requieran de referencia REA
•Pagos bloqueados.
También es necesario especificar el código de ordenante para el banco, aunque, si se deja en blanco, el programa ofrece la posibilidad de utilizar como tal los seis últimos caracteres del CIF.
Los códigos para cheque y transferencia son, por defecto, CHCF y TRCF respectivamente, aunque se pueden introducir unos distintos.
Al terminar la ejecución de rpa_confirming, se abre el bloc de notas mostrando el archivo para el banco y la presentación preliminar del informe.
En este momento, la remesa está en estado 7(ECO) y están disponibles dos procesos: Contabilizar Confirming y Deshacer Confirming. Ejecutando este último se abre el diálogo del programa remcontades.xjs indicando que se va a deshacer el proceso Generar Confirming, eliminando el asiento contable y devolviendo a la remesa al estado 3(COM) y a los pagos al estado 2(AP).
Una vez recibida la notificación del banco confirmando el pago a los proveedores, se ejecutará el proceso Contabilización Confirming, que utiliza el programa remconta para llevar la remesa al estado 10 (CON) y crear el asiento contable en el que se hace el traspaso de los pagos desde la cuenta de efectos comerciales a pagar de cada proveedor (401) a la cuenta de banco de la remesa (572).
Desde el estado 10 (CON), el único proceso disponible es Descontabilizar, que devuelve a la remesa al estado 3(COM) y a los pagos al estado 7(R). Este proceso utiliza el programa remcontades.xjs, cuya ventana de diálogo informa de los resultados de su ejecución:
