Conceptos y su contabilización

Se inicia cuando: un funcionario de FEMORF necesita crear un concepto de cobro o de pago, cambiar su prioridad de pago, o definir contra qué cuentas contables, líneas de crédito y métodos de pago se mueve.

Termina cuando: el concepto queda disponible para los procesos que cobran y contabilizan, o el sistema rechaza el cambio por código repetido, por asignación repetida o porque el concepto ya está en uso.

Participan: Funcionarios de FEMORF encargados de la parametrización y acciones automáticas.

Así funciona hoyFlujo ideal

Formularios: Conceptos; Asignar conceptos a cuentas contables; Asignar conceptos a líneas de crédito; Asignar conceptos a métodos de pago.

flowchart LR
  subgraph funcionario["Funcionario de FEMORF"]
    P1["Abre el catálogo de conceptos"]
    P2["Crea un concepto o cambia su nombre"]
    P3["Arrastra los conceptos para fijar la prioridad de pago"]
    P4["Le asigna cuentas contables con porcentaje y naturaleza"]
    P5["Lo asigna a una línea de crédito y a un tipo de uso"]
    P6["Lo asigna a un método de pago"]
    P7["Pide eliminar un concepto"]
  end
  subgraph automaticas["Acciones automáticas"]
    S1{"¿Puede abrir la pantalla?"}
    S2{"¿El código ya existe?"}
    S3["Guarda el concepto al final de la prioridad"]
    S4["Guarda el nuevo orden sin confirmarlo en pantalla"]:::warning
    S5["Ningún cobro consulta la prioridad de pago"]:::risk
    S6{"¿Ya existe esa misma asignación?"}
    S7["Exige línea de crédito aunque el uso no sea de crédito"]:::warning
    S8{"¿El concepto está en uso?"}
    S9["Bloquea el borrado e indica dónde se usa"]
    S10["Borra el concepto y renumera la prioridad de todos los demás"]:::risk
  end
  R1["Acceso denegado"]:::risk
  R2["Código repetido rechazado"]:::risk
  R3["Asignación repetida rechazada"]:::risk
  R4["Concepto disponible para cobrar y contabilizar"]:::success

  P1 --> S1
  S1 -- "No" --> R1
  S1 -- "Sí" --> P2 --> S2
  S2 -- "Sí" --> R2
  S2 -- "No" --> S3
  S3 --> P3 --> S4 --> S5
  S3 --> P4 --> S6
  P6 --> S6
  S6 -- "Sí" --> R3
  S6 -- "No" --> R4
  P5 --> S7 --> R4
  P7 --> S8
  S8 -- "Sí" --> S9
  S8 -- "No" --> S10

  classDef risk fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d;
  classDef warning fill:#fef3c7,stroke:#d97706,color:#78350f;
  classDef success fill:#dcfce7,stroke:#15803d,color:#14532d;
  style funcionario fill:#eff6ff,stroke:#2563eb
  style automaticas fill:#f5f3ff,stroke:#7c3aed

Esta es una propuesta por validar con FEMORF; aún no está implementada.

Formularios actuales relacionados: Conceptos; Asignar conceptos a cuentas contables; Asignar conceptos a líneas de crédito; Asignar conceptos a métodos de pago.

flowchart LR
  subgraph funcionario["Funcionario de FEMORF"]
    P1["Propone el concepto con su prioridad y sus asignaciones"]
    P2["Corrige las observaciones"]
  end
  subgraph direccion["Dirección de FEMORF"]
    A1["Revisa el impacto del cambio"]
    A2{"¿Aprueba la publicación?"}
  end
  subgraph automaticas["Acciones automáticas"]
    S1["Confirma el permiso en cada operación"]
    S2["Verifica que las cuentas del concepto sumen cien por ciento"]
    S3["Verifica que exista asignación para cada proceso que lo usará"]
    S4["Muestra el cobro y el asiento que resultarían"]
    S5["Publica con fecha de vigencia y conserva la versión anterior"]
    S6["Reparte cada recaudo siguiendo la prioridad publicada"]
    S7["Registra quién cambió qué y comunica el resultado"]
  end
  R1["Cambio devuelto para corrección"]:::risk
  R2["Concepto vigente con sus asignaciones completas"]:::success

  P1 --> S1 --> S2 --> S3 --> S4 --> A1 --> A2
  A2 -- "No" --> R1 --> S7 --> P2 --> P1
  A2 -- "Sí" --> S5 --> R2 --> S6
  R2 --> S7
  S2 -. "Supuesto por validar con FEMORF" .-> S3
  A1 -. "Supuesto por validar con FEMORF" .-> A2

  classDef risk fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d;
  classDef success fill:#dcfce7,stroke:#15803d,color:#14532d;
  style funcionario fill:#eff6ff,stroke:#2563eb
  style direccion fill:#eff6ff,stroke:#2563eb
  style automaticas fill:#f5f3ff,stroke:#7c3aed

Pantallas del proceso

Catálogo de conceptos ordenado por prioridad de pago.

Asignación de cada concepto a sus cuentas contables, con porcentaje y naturaleza.

Asignación de conceptos a las líneas de crédito.

Relación entre conceptos y los medios de pago admitidos.

Reglas del proceso

Cada concepto se identifica con un código y un nombre. El código se define al crearlo y ya no se puede cambiar; el nombre sí se puede corregir.
No se admiten dos conceptos con el mismo código: al crear, el sistema lo rechaza e informa cuál es el código repetido.
Un concepto nuevo se ubica al final de la prioridad de pago. La prioridad se cambia arrastrando los conceptos dentro de la lista.
Un concepto solo se ofrece para asignarlo a una línea de crédito si ya tiene al menos una cuenta contable asignada. Las pantallas de cuentas contables y de métodos de pago, en cambio, ofrecen todos los conceptos del catálogo.
Cada cuenta contable asignada a un concepto lleva un porcentaje y una naturaleza, débito o crédito. Un mismo concepto se puede repartir entre varias cuentas.
La asignación de una cuenta contable indica además a qué área corresponde: Socios, Cartera, Tesorería o Contabilidad. Ese dato es opcional al guardar.
No se admite repetir la misma combinación de concepto, cuenta contable y área, ni la misma combinación de concepto y método de pago.
La asignación a líneas de crédito exige siempre una línea, un tipo de uso (aportes, ahorro programado, crédito, proveedores, otros, cobro de admisión o convenios) y un tipo de movimiento (interés corriente, interés de mora, abono a capital, desembolso u otros).
Un concepto no se puede eliminar si está relacionado con cuentas contables, con asignaciones a líneas de crédito, con cuentas por cobrar, con cuentas por pagar, con conceptos manuales o con métodos de pago. El sistema bloquea el borrado y enumera con cuáles de ellos está relacionado.
La asignación a métodos de pago alimenta solo dos selecciones del sistema: los conceptos de banco que se ofrecen en el desembolso por transferencia y el concepto de cruce del comprobante de entrada.
La naturaleza queda registrada dos veces para la misma pareja: una en la cuenta del plan contable y otra en la asignación del concepto. Los procesos usan la de la asignación y nunca comparan ambas.

Diferencias y hallazgos

H-PAR-CPT-01 — La prioridad de pago se configura pero no gobierna ningún cobro

La pantalla permite ordenar los conceptos por prioridad de pago y guarda ese orden, pero ningún proceso de recaudo lo consulta: el abono a un crédito se aplica íntegro a capital, sin repartirse entre mora, interés corriente y capital. En el ambiente revisado los cuarenta y siete conceptos tienen la prioridad en cero, es decir, la prioridad nunca se estableció y la lista se muestra en un orden que el fondo no definió.

H-PAR-CPT-02 — Eliminar un concepto reescribe la prioridad de todos los demás

Cuando un concepto sí se puede borrar, el sistema renumera de uno en adelante la prioridad de todo el catálogo. Como hoy todas las prioridades valen cero, esa renumeración las asigna en un orden que nadie eligió, sin dejar constancia de quién la produjo. Además, el reordenamiento manual se guarda sin ninguna confirmación en pantalla, de modo que el funcionario no sabe si quedó grabado.

H-PAR-CPT-03 — La protección de borrado cubre el concepto, no sus asignaciones

El concepto en uso está protegido, pero sus asignaciones no: la cuenta contable, la línea de crédito y el método de pago se pueden borrar sin ninguna comprobación de uso. Quitar la cuenta contable de un concepto que se está cobrando deja sin cuenta a los procesos que lo necesitan y los interrumpe. Al borrar una asignación contable el sistema informa que se eliminó incluso cuando esa asignación ya no existía.

H-PAR-CPT-04 — Los porcentajes por cuenta no se controlan como conjunto

Nada verifica que las cuentas de un concepto sumen cien por ciento: la única comprobación es que cada porcentaje esté entre cero y cien, y se hace solo en la pantalla, no al guardar. Un concepto puede quedar repartido al ochenta por ciento y contabilizar de menos, o al ciento cincuenta y contabilizar de más. Además, el reparto de aportes espera exactamente dos cuentas: si el concepto tiene una sola o más de dos, la operación que lo usa se interrumpe.

H-PAR-CPT-05 — El área de la asignación contable decide si el sistema la encuentra, y es opcional

Los procesos buscan la cuenta del concepto indicando el área a la que pertenecen. Una asignación guardada sin área queda invisible para ellos, y una guardada con el área equivocada deja al proceso sin cuenta y detiene la operación. La pantalla no indica qué área espera cada proceso ni advierte cuando un concepto queda sin asignación para el área que lo va a usar. Cuando un concepto tiene varias cuentas y el proceso necesita una sola, se toma la primera que aparece, sin un criterio definido.

H-PAR-CPT-06 — La línea de crédito se exige siempre y las asignaciones se pueden duplicar

Para registrar un concepto de aportes, de ahorro programado, de proveedores, de convenios o de cobro de admisión hay que elegir de todas formas una línea de crédito, que no significa nada para esos usos y queda visible en el listado. Esta pantalla tampoco rechaza asignaciones repetidas, a diferencia de las de cuentas contables y métodos de pago. Cuando hay más de una asignación para el mismo tipo de uso, el proceso que la consulta toma una cualquiera y no mira la línea de crédito.

H-PAR-CPT-07 — Solo se verifica el permiso al entrar, y los cambios no dejan historial

El permiso se comprueba únicamente al abrir cada pantalla; crear, modificar, eliminar y reordenar no lo vuelven a comprobar, de modo que los botones ocultos son solo una ocultación visual. La pantalla de métodos de pago ni siquiera tiene permisos propios: usa el mismo permiso de ver el área de parametrización para consultar, crear, modificar y eliminar. Ninguna de las cuatro pantallas deja historial de cambios: no se puede reconstruir quién cambió una cuenta, un porcentaje, una naturaleza o la prioridad, ni cuándo.

Supuestos por validar con FEMORF

A-PAR-CPT-01: Supuesto por validar con FEMORF: la prioridad de pago debe gobernar el reparto de todo recaudo, con un orden explícito entre mora, interés corriente, capital y los demás conceptos.
A-PAR-CPT-02: Supuesto por validar con FEMORF: las cuentas contables de un concepto deben sumar exactamente cien por ciento, y debe definirse qué ocurre cuando un concepto se reparte entre más de dos cuentas.
A-PAR-CPT-03: Supuesto por validar con FEMORF: un concepto puede tener asignaciones contables distintas según el área que lo use, y debe definirse quién determina el área correcta para cada proceso.
A-PAR-CPT-04: Supuesto por validar con FEMORF: la línea de crédito solo debe exigirse cuando el uso del concepto es de crédito, y debe definirse si un mismo tipo de uso puede tener más de un concepto asignado.
A-PAR-CPT-05: Supuesto por validar con FEMORF: los cambios en el catálogo y en sus asignaciones requerirán aprobación previa, fecha de vigencia y un historial consultable de quién cambió qué.