Un comprobante
Importante
Toda la funcionalidad de la que se habla en este artículo, o parte de ella, está disponible como parte de una versión preliminar. El contenido y la funcionalidad están sujetos a cambios. Para obtener más información acerca las versiones preliminares, consulte Disponibilidad de actualización del servicio.
¿Qué es Un comprobante?
Debido a la flexibilidad de los diarios financieros, puede ingresar un solo comprobante que represente una transacción, pero que tenga varios clientes, proveedores, activos fijos, proyectos o cuentas bancarias. Microsoft se refiere a esta funcionalidad como Un comprobante. Los escenarios de Un comprobante no incluyen transacciones con solo cuentas contables. Esas transacciones se contabilizan en el libro mayor, no en libros auxiliares como Clientes, Activos fijos y Banco.
Hay dos categorías de ejemplos de Un comprobante:
El comprobante contiene varias transacciones que se ingresaron como una sola transacción. Estos son algunos de los posibles ejemplos:
- Los pagos de varios proveedores se ingresan en cada línea (no se usa cuenta de contrapartida) y la desviación de la suma de pagos respecto a una cuenta bancaria se ingresa en una línea. El resumen de pagos se realiza para actualizar el libro mayor auxiliar del banco como un importe resumido que coincida con el extracto de la cuenta bancaria. Sin embargo, cada transacción de proveedor se sigue registrando en detalle en el libro auxiliar de Proveedores. El mismo escenario también se encuentra en el lado del pago del cliente.
- Se adquieren múltiples activos fijos en un solo comprobante. Este enfoque se usa a menudo cuando se ingresan saldos iniciales para el módulo Activos fijos .
El comprobante contiene una transacción que afecta a varios tipos de cuentas que no son del libro mayor. Estos son algunos de los posibles ejemplos:
- Transferencias de bancos
- Compensación de saldos de proveedores/clientes (misma parte)
- Transferencia de saldos del cliente A al cliente B
- Facturas de proveedor que tienen varias líneas que contienen activos fijos o proyectos
Los ejemplos anteriores de cada categoría representan requisitos empresariales válidos. A veces, los requisitos comerciales no se pueden cumplir de otra manera: la organización debe ingresar las transacciones como Un comprobante. Sin embargo, en otros momentos, existen otras formas válidas de cumplir con los requisitos comerciales: las transacciones se pueden ingresar de manera diferente o usar otra característica.
Problemas con un comprobante
El uso de la funcionalidad de Un comprobante para cumplir con los requisitos comerciales puede causar problemas. Diversos procesos, reversiones de transacciones y consultas/informes requieren detalles de la transacción. Esos detalles no se pueden determinar a partir del modelo de datos actual si se ingresan múltiples transacciones en resumen en un único comprobante. Además, los detalles no siempre se pueden determinar claramente si se desconoce el tipo de transacción que se ingresa. Esta limitación se debe a la flexibilidad de los diarios, especialmente cuando se ingresan a través del diario general.
Es posible que algunos escenarios sigan funcionando correctamente, según la configuración de su organización. Aquí hay áreas donde puede encontrar problemas:
Liquidación: si existe más de un proveedor o cliente en un comprobante, la contabilidad que se crea durante la liquidación puede asignarse incorrectamente a las dimensiones financieras. Para obtener más información acerca de los problemas que pueden ocurrir durante la liquidación, consulte Asiento único con varios registros de clientes o proveedores. El rendimiento de la liquidación está muy influido por el número de líneas del diario de facturas que utilizan Un vale. Se prevé que el tiempo necesario para la liquidación y la contabilización de los pagos aumente exponencialmente cuantas más líneas del diario de facturas utilice Un asiento.
Cálculo de impuestos: si existe más de un comprobante o existe un cliente en un comprobante, es posible que el cálculo de impuestos sea incorrecto.
Reversión de transacciones: si existe más de un tipo de cuenta de libro mayor auxiliar en un comprobante, cuando se revierte una sola transacción de libro mayor auxiliar, es posible que se registre un asiento contable incorrecto para la reversión en el libro mayor general. Por ejemplo, si adquiere varios activos en un solo comprobante y luego revierte la adquisición de uno de los activos, la contabilidad general será incorrecta para la reversión.
Informes y consultas: si incluye más de un tipo de cuenta de libro auxiliar (por ejemplo, Proveedor y Cliente) en un comprobante, los informes/consultas mostrarán solo el primer valor de cuenta que se encuentre.
Por ejemplo, usted registra la siguiente factura de proveedor multilínea. Contiene cuatro proyectos que representan las "líneas" de la factura. Este enfoque es un requisito comercial común para las organizaciones que utilizan los diarios de forma amplia.
Tres de los cuatro proyectos se contabilizan en la misma cuenta principal (601500). Si abre el explorador de orígenes de contabilidad para ver detalles sobre las transacciones registradas para esa cuenta principal, notará que el id. del proyecto para las tres líneas es 000057. Este comportamiento es una limitación conocida de Un comprobante. Los detalles no se vincularán correctamente a cada línea del proyecto apropiado en el diario. En su lugar, el valor de la primera cuenta que se encuentre siempre se mostrará en los informes y en las consultas.
Introducir una transacción como Un comprobante
Para ingresar transacciones como Un comprobante, vaya a Libro mayor > Configuración del libro mayor > Parámetros del libro mayor, y luego, en la pestaña Libro mayor, configure la opción Permitir transacciones múltiples dentro de un comprobante en Sí.
Puede ingresar una transacción de un comprobante en la página Nombres de diarios configurando el campo Nuevo comprobante en uno de los siguientes valores:
- Un solo número de comprobante: cada línea que agregue al diario se incluirá en el mismo comprobante y las líneas contendrán más de un cliente, proveedor, banco, activo fijo o proyecto.
- En relación con el saldo: ingrese un comprobante de varias líneas donde no haya una cuenta de contrapartida y las líneas contengan más de un cliente, proveedor, banco, activo fijo o proyecto.
- En relación con el saldo: Introduzca un asiento en el que tanto la cuenta como la cuenta de contrapartida contengan un tipo de cuenta de submayor, como Proveedor/Proveedor, Cliente/Cliente, Proveedor/Cliente o Banco/Banco.
¿Mi escenario empresarial requiere Un comprobante?
Los siguientes escenarios comerciales se han identificado como escenarios para los que los clientes utilizan la funcionalidad de Un comprobante. Algunos requisitos empresariales se pueden cumplir solo con Un comprobante. Sin embargo, para muchos otros, hay alternativas disponibles.
| Situación | Description | ¿Es necesario Un comprobante? | Alternativo |
|---|---|---|---|
| Resumen de pagos a proveedores | Una organización comunica una lista de proveedores e importes a su banco. El banco utiliza esta lista para pagar a los proveedores en nombre de la organización. Cada pago de proveedor debe contabilizarse en detalle en Proveedores, pero la suma de los pagos se contabiliza en la cuenta bancaria como una única retirada. | Ninguno | A partir de Microsoft Dynamics 365 Finance versión 10.0.32, hay una característica que se llama Capacidad para contabilizar pagos detallados de proveedores y clientes, pero resumir los importes en la cuenta bancaria. Para obtener más información, consulte Contabilizar pagos detallados de clientes y proveedores. |
| Resumen de pagos de clientes | Los pagos de los clientes se depositan como una suma global en la cuenta bancaria. Cada pago de cliente debe contabilizarse en detalle en Clientes, pero la suma de los pagos se contabiliza en la cuenta bancaria como un único depósito. | Ninguno | A partir de Dynamics 365 Finance, versión 10.0.32, hay una característica que se llama Capacidad para contabilizar pagos detallados de proveedores y clientes, pero resumir los importes en la cuenta bancaria. Para obtener más información, consulte Contabilizar pagos detallados de clientes y proveedores. |
| Factura de cliente/proveedor | Se ingresa una factura para un solo cliente o proveedor, pero las líneas adicionales representan las líneas de la factura y tienen múltiples activos fijos o proyectos. | Sí | |
| Diario de pagos de anticipo del cliente que tiene impuestos sobre las varias "líneas" | Un cliente realiza un prepago de un pedido. Las líneas del pedido tienen diferentes impuestos. El pago del cliente de prepago debe contener al cliente en varias líneas, de modo que se puedan calcular los impuestos para cada línea. | Sí | |
| Reembolso al cliente | Si la tarea periódica de reembolso se ejecuta desde Clientes, crea una transacción para mover el saldo de un cliente a un proveedor. El proveedor es la misma parte que el cliente. | Sí | |
| Mantenimiento de activos fijos: recuperación de la depreciación, división de activos y cálculo de depreciación en el desecho | La recuperación de la depreciación, la división de un activo y el cálculo de la depreciación para el desecho de activos, todo se usa para crear un solo comprobante. | Ninguno | A partir de la versión 10.0.21 de Finanzas, las transacciones de activos fijos que se crean para recuperar la depreciación, dividir un activo y calcular la depreciación para el desecho de un activo usan diferentes números de comprobante. |
| Letras de cambio y pagarés | Las letras de cambio y pagarés pasan al cliente o el saldo de proveedor de una cuenta de clientes o proveedores a otra, en función del estado del pago. Debido a que siempre se usa el mismo cliente o proveedor en el comprobante, no existen problemas de informes. | Sí | |
| Compensación | Si un cliente y proveedor son la misma parte, los saldos para el proveedor y el cliente están uno junto al otro. Este enfoque minimiza el intercambio de dinero entre una organización y la parte del cliente o proveedor. | Ninguno | A partir de Microsoft Dynamics 365 Finance versión 10.0.40, existe la característica de Compensación de clientes y proveedores. La función de compensación crea automáticamente dos asientos separados para el proveedor y el cliente. Para obtener más información, consulte Saldos de retribución de cliente y proveedor. |
| Transferir saldos | Una organización podría tener que transferir un saldo de un proveedor a otro, ya sea debido a un error o debido a que otro proveedor ha asumido el pasivo. Las transferencias de este tipo también se producen para los tipos de cuenta como cliente y Banco. | Sí/No | Las transferencias de saldo a partir de una cuenta (proveedor, cliente, banco, etc.) a otra se pueden realizar a través de asientos independientes y la contrapartida se puede registrar en una cuenta contable de compensación. Para algunas organizaciones, este enfoque requiere demasiada preparación. Por lo tanto, eligen usar Un comprobante en su lugar. |
| Liquidación de varios pagos no contabilizados en la misma factura | Este escenario se encuentra normalmente en las organizaciones en las que los clientes pueden usar varias formas de pago para pagar compras. En este escenario, la organización debe poder registrar varios pagos sin registrar y liquidarlos con la factura de cliente. | Ninguno | Una nueva característica agregada en Finanzas permite liquidar varios pagos no saldados contra una única factura. |
| Funciones específicas de países o regiones | La característica Documento Único Administrativo (SAD) para Polonia requiere que las transacciones se agrupen, y el número de comprobante se usa para este propósito. Puede haber características específicas del país o región adicionales que requieran la funcionalidad de Un comprobante. | Sí | |
| Mecanismo para agrupar transacciones de un evento de negocio | Una organización tiene un solo evento de negocio que desencadena varias transacciones. El departamento de contabilidad desea ver las entradas contables de forma conjunta para facilitar la auditabilidad. Un escenario similar es aquel en el que las transacciones bancarias se registran en Finanzas a través de un archivo que se recibe del banco. Las organizaciones a menudo desean agrupar juntas esas transacciones mediante el número de extracto bancario en el archivo. | Ninguno | Aunque agrupar transacciones es un escenario válido, el número de comprobante nunca debe usarse para este propósito. Los comprobantes siempre representan transacciones individuales, nunca un grupo de transacciones. En lugar de esto, las transacciones se pueden agrupar con otros campos del diario, como el número de lote del diario en sí o el número de documento. |
| Introducir saldos iniciales | Las organizaciones a menudo especifican saldos iniciales para cuentas de submayor (proveedores, clientes, activos fijos, etc.) como una única transacción de comprobante. | Ninguno | Los saldos iniciales de cada cuenta del libro submayor se deben ingresar como comprobantes separados. La compensación se puede contabilizar en una cuenta del libro mayor de compensación, que se compensa con el saldo inicial del libro mayor. |
| Corregir el asiento contable de un documento contabilizado | Es posible que una organización tenga que corregir la cuenta contable Clientes o Proveedores en relación con una factura contabilizada. Debido a que la factura es correcta, no debe revertirse. | Sí/No | Si tiene que realizarse una corrección en la cuenta contable Clientes o Proveedores, se puede realizar un ajuste directamente en la cuenta contable. Este enfoque requiere que el ajuste se efectúe durante un "tiempo de inactividad”, de modo que la cuenta contable pueda permitir temporalmente la entrada manual. Una desventaja de este enfoque es que los informes de conciliación de proveedor/cliente con el libro mayor mostrarán una diferencia al entrar y salir. El importe neto es 0 (cero). |
| Contabilizar en resumen en contabilidad general | Las organizaciones a menudo desean registrar en la contabilidad general en forma de resumen, para minimizar la cantidad de datos. Sin embargo, esas organizaciones normalmente requieren que se mantengan los detalles de transacción. Cuando la contabilización se realiza en forma de resumen mediante un comprobante único, no se conocen los detalles de la transacción y no se pueden mantener. | Ninguno | Dado que los detalles de la transacción se pierden, las organizaciones no deben usar Un comprobante para contabilizar en resumen si los detalles son necesarios para los informes. |
| "El sistema lo permite" | Las organizaciones a menudo usan la funcionalidad de un comprobante simplemente porque el sistema les permite utilizarla, sin comprender las implicaciones. | Ninguno | El mero hecho de que el sistema habilite el uso de la funcionalidad nunca es una razón válida. La funcionalidad debe usarse solo si es necesaria para cumplir con otro requisito comercial. |
El futuro de Un comprobante
Debido a los problemas que pueden producirse cuando se usa Un comprobante, se extán explorando las siguientes opciones:
- Se seguirán introduciendo nuevas características si hay una mejor manera de lograr un escenario empresarial. Por ejemplo, una característica que se introdujo en la versión 10.0.32 de Finanzas permite que los pagos se ingresen como comprobantes separados, pero la cuenta bancaria se sigue actualizando en resumen. A medida que se agreguen características, se documentarán para cada escenario comercial en la columna "Alternativa" de la tabla anterior.
- Es posible que se sigan ingresando algunas transacciones a través del diario en un solo comprobante, pero es posible que se realice un seguimiento de los datos adicionales para identificar correctamente los detalles de la transacción.
- Es posible que se utilice una combinación de características nuevas, pero las transacciones para los escenarios comerciales pueden seguir introduciéndose en el diario mediante el uso de un único comprobante.
A medida que se introducen nuevas características, su organización debe evaluar continuamente si la opción Permitir múltiples transacciones dentro de un comprobante de la página Parámetro de contabilidad general se puede desactivar. Le recomendamos que no use Un comprobante para las integraciones, a menos que la funcionalidad sea necesaria para una de las brechas funcionales documentadas.
A medida que se cubran las lagunas funcionales, Microsoft comunicará las nuevas características que se utilizarán en lugar de Un asiento. Para algunos escenarios empresariales, como una factura de proveedor con varias líneas, se seguirá utilizando un asiento, pero con mejoras. Esas mejoras se comunicarán a medida que se entreguen.