Flujo completo de pagos y cobros a nivel contable (clasificación de efectos en cartera, impagados... en subcuentas)

Según lo que comentamos en las Jornadas de Vilanova, esta es la descripción del requerimiento que comentamos. Lamento que haya quedado tan largo, es un intento de clarificarlo lo más posible.

¿Qué?:
clasificar los saldos vivos (deudas pendientes de conciliar) de proveedores y clientes a lo largo de los procesos de cobros y pagos.

¿Por qué?
las empresas donde la gestión de cartera es importante, bien por el número de movimientos, o por que utilizan sistemas de gestión de cobro o pago con sus bancos, suelen requerir que la información de las deudas con proveedores y clientes se clasifique según la fase del proceso en que se encuentren. En las empresas sometidas a auditoría, los auditores solicitan esta clasificación habitualmente. El Plan General Contable prevé cuentas contables del grupo 43 para clientes y del grupo 40 para proveedores para reflejar cada situación.

¿Cómo?

CLIENTES: típicamente una deuda de un cliente con la empresa podría pasar por las siguientes situaciones:

"inicial": deuda recién contraída, facturada por ejemplo. Pero también cualquier apunte al cliente que signifique que está en deuda con nosotros.

"en cartera": se ha recibido algún documento de pago contra la deuda, pero no significa que la deuda se haya liquidado Ej, se ha recibido un pagaré.

Las dos siguientes son alternativas entre sí:
"remesado al descuento": se ha descontado (financiado) la deuda, si bien la deuda sigue pendiente de vencimiento y por lo tanto sigue existiendo el riesgo de impago hasta que al vencimiento el cliente la liquide. Ej. el pagaré recibido se presenta a un banco y este anticipa el dinero.
"en gestión de cobro": se remiten deudas a un banco que actúa por cuenta del cliente, por lo tanto hasta el vencimiento sigue existiendo la deuda. Ej. factoring

"liquidado": la deuda ha llegado a buen fin. En OE sería la conciliación. El usuario seleccionaría las deudas que hayan vencido de las que están "en cartera" o "remesadas" o "en gestión de cobro"

"impagado": se declara que una deuda ha sido expresamente rechazado por el cliente. La deuda sigue reflejada, pero en otro estado.

El PGC tiene cuentas para cada estado: 4300 -> "inicial", 4310 -> "en cartera". 4311 -> "remesado al descuento". 4312 -> "gestión de cobro". 4315 -> "impagado". De forma análoga para las cuentas 433 de clientes, empresas del grupo.

Típicamente la recepción de un documento "en cartera" engloba varias deudas (varios vencimientos).
Cualquier descuento al banco implica, además, un movimiento de entrada a la cuenta bancaria de la compañía y contrapartida la cuenta de "deudas por efectos descontados 5208"
Hay que tener en cuenta flujos para impagar efectos remesados y volverlos a poner en circulación (o sea, volver a cartera y remesar). Más tarde describiré el flujo tal como lo veo.

En el siguiente diagrama, se muestra el flujo (y los movimientos contables asociados) de un cobro de una factura de cliente: http://img132.imageshack.us/img132/2569/gestindeefectoscobrosac.png

PROVEEDORES: los procesos de pago a proveedores son más simples: o se paga la deuda al vencimiento o se puede emitir algún tipo de efecto (eg. pagaré) pagadero al vencimiento.

"inicial": aceptación de una deuda, eg: contabilización de una factura, pero también cualquier apunte que signifique que se está en deuda con el proveedor.

"gestión de pago": se ha emitido algún efecto pagadero al vencimiento, eg: emisión de un pagaré o emisión del cuaderno CSB 19 de ordenes de pago por transferencia o cheque o la emisión de fichero para ordenes de confirming.

"liquidado": la deuda se acepta para pago. En OE sería la conciliación, exactamente cómo lo hace el extracto bancario cuando ofrece la opción "cargar facturas", aunque debería ofrecer para seleccionar las deudas en "gestión de pago" o las facturas a las que no se les ha hecho ninguna gestión

El PGC dispone de las cuentas 4000 -> "inicial", 4010 -> "gestión de pago" Lo mismo para acreedores 4100 y 4110

La emisión de un efecto a pagar puede incluir varios vencimientos pendientes. Es típico en pagarés. Si se usa Confirming es típico lo contrario: un pago por deuda. Por lo tanto debe poder parametrizarse o darle la opción al usuario.

En general:
Debe mantenerse la trazabilidad a lo largo del proceso, eg. debe poderse seguir un vencimiento de una factura hasta su liquidación, y en sentido contrario, desde la liquidación hasta los vencimientos, deudas, liquidadas.

Importante: no hay que olvidar que, independientemente de cómo esté clasificada, la deuda sigue vigente y forma parte del "riesgo del cliente" (o de la deuda a proveedores exigible). Por lo tanto debe sumar a la hora de calcular y controlar el riesgo de los clientes. Lo que esto aporta es la posibilidad de clasificar los movimientos que componen el riesgo (los llamados "saldos vivos") por su situación.

Los informes deben poder aportar la información clasificada así, pero también mostrar la situación en fechas pasadas (es común que los informes de auditoría se realicen en el primer trimestre pero referidos al 31/12 anterior).

Lo ideal es que todo esto fuera parametrizable: las cuentas, los bancos implicados.

Algunos gestores pueden requerir que los saldos vivos se clasifiquen por los estados anteriores, pero sin clasificar por cuenta, utilizando para todos los estados la misma cuenta de proveedores 4000 y la misma de clientes 4300 (en este caso no deberían producirse los asientos ya que no modifican el saldo). Pero lo habitual es que adicionalmente al cambio de estadi se contabilice en las cuentas anteriores.

También podría utilizarse como clasificador las diferentes cuentas, sin existir un campo estado en cada deuda.

En OE no sería necesario, pero los contables clásicos podrían exigir que la contabilización se realizara en subcuentas individualizadas para cada cliente y proveedor, eg: 4300xxxx, 4310xxxx, 4311xxxx, 4315xxxx donde xxxx es el código de cliente. Esto debería intentar evitarse con el objetivo de "reducir el balance" siempre que los informes disponibles individualizaran de la misma manera. Si se necesitara así, se complicaría la asignación de cuentas a los partners ya que cada uno tendría que tener configurado un diccionario {estado:cuenta}. (creo que hay un módulo que al crear un partner crea la cuenta 4000xxxx y 4300xxx; si se configurara el uso individualizado ¿podrían crear también el resto?)

Funcionalidad:
sería algo como establecer flujos de trabajo con procesos para cada cambio de estado (ej. en clientes: llevar a cartera, remesar al descuento, llevar a gestión de cobro, liquidar). Todos los procesos operarían de forma similar:

 1) seleccionar las deudas adecuadas (las del estado anterior) a conciliar; por cliente, fecha de vencimiento, factura si es el caso, otros criterios;

 2) lo anterior debe crear apuntes a la misma cuenta de las seleccionadas pero de signo contrario y debe crearse una conciliación entre unas y otras. La contrapartida debe ser un apunte o apuntes a la cuenta parametrizada para ese estado.
Ej1: en clientes el proceso "llevar a cartera" debería poder seleccionarse deudas pendientes sólo en estado "inicial" o "impagado", cuenta 4300 o 4315. Los movimientos contables creados deben ser 4300 (o 4315) de signo contrario y conciliados con los seleccionados; la contrapartida 4310. Lo que ocurre es que este apunte de contrapartida representa el pagaré recibido por la compañía desde el cliente y este puede decidir emitir un pagaré por cada deuda o agrupar varias deudas en un solo efecto.
Ej2: el proceso de remesar al descuento debería seleccionar sólo las deudas en estado "cartera" o cuenta 4310 creando apuntes en la 4310 de signo contrario dejándolos como conciliados con los seleccionados y creando como contrapartidas apuntes a la 4311. Adicionalmente hay un asiento bancario de la cuenta 572 de bancos a 5208 de deudas por efectos descontados.

 3) aquí es donde debería integrarse con los módulos de remesas o futuros de impresión de cheques o pagarés.

 4) confirmación contable despúes de que se asegure el usuario que se ha transmitido y procesado el CSB o bien impresos los pagarés, cheques o cualquier otro proceso ligado a la ejecución del proceso para el estado en cuestión.

Importante resaltar que el uso de este proceso puede ser opcional y que debe poder parametrizarse cómo usarlo (forma de pago/cobro, cuentas, bancos etc).

Creo que como primera aproximación para comprender el problema es suficiente. Pero sin entrar en detalles de implementación parece que todos los pasos del proceso son muy similares en cuanto a la operativa del usuario: una vista donde seleccionar apuntes donde construir apuntes contables que siempre serían de la forma "cuenta estado anterior" contrapartida "cuenta nuevo estado", eg. el proceso de pasar a cartera sería: 4300 contra 4310. El proceso de gestión de pago a proveedores sería 4000 contra 4010 (no entro a hora si el debe o haber es el correcto). Además en algún proceso habría que sumarizar los importes y realizar un apunte adicional. Esto se parece mucho a la definición de los diarios contables de OE donde se puede configurar las cuentas de debe y haber por defecto. Para que fuera útil al usuario debe proporcionarse ayuda para construir estos apuntes mostrándole las deudas en "estado o cuenta anterior", con filtros para seleccionar por partner, fecha, fecha vencimiento, importes.., de manera que los apuntes se creen en la misma cuenta (la anterior) que los seleccionados pero de signo contrario y todos queden conciliadas, con contrapartida la cuenta del nuevo estado. La operativa en sí es la misma a todos los estados, tanto de clientes como proveedores, por lo que parece que la vista o vistas serían la misma o muy similares y pudieran ser gobernadas por configuración y por la definición de su flujo de trabajo.

Si no os hemos aburrido demasiado, y os parece tan interesante como a nosotros, podríamos discutirlo en más detalle.

Emilio Arrufat + Alberto Gallén.

Enlaces de interés:
  - Diagrama de flujo del cobro de una factura de cliente:
    http://img132.imageshack.us/img132/2569/gestindeefectoscobrosac.png
  - "RUTA A SEGUIR PARA EL COBRO DE LAS FACTURAS" (nicasiofernandez.es contabilidad & nic on line):
    http://www.nicasiofernandez.es/ruta%20a%20seguir%20para%20el%20cobro.htm
  - "Registro Contable de las Operaciones de Tesorería" (Curso ITE):
    http://www.ite.educacion.es/w3/eos/RecursosFP/Administracion/GradoMedio/GestAdmi/modulo4/m4u13.swf