Um comprovante único
Importante
Algumas ou todas as funcionalidades observadas neste artigo estão disponíveis como parte de uma versão preliminar. O conteúdo e a funcionalidade estão sujeitos a alterações. Para obter informações sobre as versões prévias, consulte Disponibilidade das atualizações do serviço.
O que é "Um comprovante único"?
Devido à flexibilidade dos diários financeiros, você pode inserir um único comprovante que representa uma transação, mas que tem vários clientes, fornecedores, ativos fixos, projetos ou contas bancárias. Microsoft se refere a esta funcionalidade como Um comprovante único. Os cenários de Um comprovante único não incluem transações que tenham somente contas contábeis. Essas transações são lançadas na contabilidade, e não nos diários-razão auxiliares, como contas a receber, ativos fixos e bancos.
Há duas categorias de exemplos de Um comprovante único:
O comprovante contém várias transações que foram inseridas como uma única transação. Veja alguns exemplos possíveis:
- Vários pagamentos de fornecedores são inseridos em cada linha (nenhuma contrapartida é usada) e a compensação da soma de pagamento para uma conta bancária é inserida em uma linha. O resumo de pagamento é feito para atualizar o diário-razão auxiliar como um valor resumido que corresponde ao extrato da conta bancária. No entanto, cada transação de fornecedor ainda é registrada em detalhes no diário-razão auxiliar de Contas a pagar. O mesmo cenário também é encontrado no lado de pagamentos do cliente.
- Vários ativos fixos são adquiridos em um único comprovante. Essa abordagem geralmente é usada quando saldos iniciais são inseridos para o módulo Ativos fixos.
O comprovante contém uma transação que afeta vários tipos de conta não contábeis. Veja alguns exemplos possíveis:
- Transferências bancárias
- Os saldos de remuneração de fornecedor/cliente (mesma propriedade)
- Transferir saldos do cliente A para cliente B
- Faturas de fornecedor que têm várias linhas contendo ativos fixos ou projetos
Os exemplos anteriores para cada categoria representam as necessidades comerciais válidas. Às vezes, as necessidades comerciais não podem ser atendidas de outra forma: a organização deve inserir as transações como Um comprovante único. No entanto, outras vezes, há outras maneiras válidas de atender aos requisitos comerciais: as transações podem ser inseridas de maneira diferente ou usar outro recurso.
Problemas com Um comprovante único
O uso de uma funcionalidade de Um comprovante único para atender às necessidades comerciais pode causar problemas. Vários processos, reversões de transação e consultas/relatórios exigem detalhes da transação. Esses detalhes não podem ser determinados do modelo de dados atual quando várias transações são inseridas em resumo em um único comprovante. Além disso, os detalhes nem sempre podem ser claramente determinados quando o tipo de transação inserido é desconhecido. Essa limitação é causada pela flexibilidade dos diários, especialmente quando são inseridos por meio do diário geral.
Alguns cenários ainda podem funcionar corretamente, dependendo da configuração de sua organização. Estas são as áreas nas quais você pode encontrar problemas:
Liquidação – se houver mais de um fornecedor ou cliente em um comprovante, a contabilidade criada durante a liquidação poderá ser alocada incorretamente para dimensões financeiras. Para obter mais informações sobre problemas que podem ocorrer durante a liquidação, consulte Um comprovante único com vários registros de clientes ou fornecedores. O desempenho da liquidação é altamente influenciado pelo número de linhas do diário de faturas que usam Um comprovante único. Espera-se que o tempo necessário para o lançamento de liquidação e pagamento aumente exponencialmente, quanto mais as linhas do diário de faturas usarem Um comprovante único.
Cálculo de imposto – se mais de um comprovante ou cliente existir em um comprovante, o cálculo do imposto poderá estar incorreto.
Reversão de transação – se houver mais de um tipo de razão auxiliar em um comprovante, quando uma única transação do razão auxiliar for revertida, uma entrada contábil incorreta poderá ser lançada para o estorno na contabilidade. Por exemplo, se você adquirir vários ativos em um único comprovante e, em seguida, reverter a aquisição de um dos ativos, a contabilidade ficará incorreta para a reversão.
Relatórios e consultas – se você incluir mais de um tipo de conta do razão auxiliar (por exemplo, Fornecedor e Cliente) em um comprovante, os relatórios/consultas mostrarão somente o valor da primeira conta que for encontrado.
Por exemplo, você lança a seguinte fatura de fornecedor com várias linhas. Ela contém quatro projetos que representam as "linhas" na fatura. Essa abordagem é um requisito comercial comum para organizações que usam diários extensivamente.
Três dos quatro projetos são lançados na mesma conta principal (601500). Se você abrir o Gerenciador de origens contábeis para exibir detalhes sobre transações lançadas para essa conta principal, notará que o ID do projeto para as três linhas será 000057. Esse comportamento é uma limitação conhecida do Um comprovante único. Os detalhes não vinculam corretamente cada linha ao projeto apropriado no diário. Em vez disso, o valor da primeira conta que é encontrado sempre será mostrado em relatórios e em consultas.
Inserir uma transação como Um comprovante único
Para inserir transações como Um comprovante único, acesse Contabilidade > Configuração do razão > Parâmetros da contabilidade e, na guia Razão, defina a opção Permitir várias transações dentro de um comprovante como Sim.
Você pode inserir uma transação de Um comprovante único na página Nomes de diários, definindo o campos Novo comprovante como um dos seguintes valores:
- Apenas um número de comprovante – cada linha adicionada ao diário será incluída no mesmo comprovante, e as linhas conterão mais de um cliente, fornecedor, banco, ativo fixo ou projeto.
- Em relação ao saldo – insira um comprovante de várias linhas no qual não haja contrapartida, e as linhas contenham mais de um cliente, fornecedor, banco, ativo fixo ou projeto.
- Em relação ao saldo – insira um comprovante de linha única em que a conta e a contrapartida contenham um tipo de conta de diário-razão auxiliar, como Fornecedor/Fornecedor, Cliente/Cliente, Fornecedor/Cliente ou Banco/Banco.
Meu cenário comercial requer Um comprovante único?
Os cenários comerciais a seguir foram identificados como cenários para os quais os clientes usam a funcionalidade de Um comprovante único. Alguns requisitos comerciais podem ser atendidos somente usando Um comprovante único. No entanto, para muitos outros, estão disponíveis alternativas.
| Cenário | Descrição | Um comprovante único necessário? | Alternativa |
|---|---|---|---|
| Resumo de pagamento de fornecedor | Uma organização comunica uma lista de fornecedores e valores ao seu banco. O banco usa essa lista para pagar os fornecedores no nome da organização. Cada pagamento de fornecedor deve ser lançado em detalhes em Contas a pagar, mas a soma dos pagamentos é lançada na conta bancária como uma única retirada. | Número | A partir do Microsoft Dynamics 365 Finance versão 10.0.32, há um recurso chamado Capacidade de lançar pagamentos detalhados de fornecedores e clientes, mas resumir valores na conta bancária. Para obter mais informações, consulte Lançar pagamentos detalhados de fornecedor e cliente. |
| Resumo da pagamento de cliente | Os pagamentos de clientes são depositados como uma quantia total na conta bancária. Cada pagamento de cliente deve ser lançado em detalhes em Contas a receber, mas a soma dos pagamentos é lançada na conta bancária como um único depósito. | Número | A partir do Dynamics 365 Finance versão 10.0.32, há um recurso chamado Capacidade de lançar pagamentos detalhados de fornecedores e clientes, mas resumir valores na conta bancária. Para obter mais informações, consulte Lançar pagamentos detalhados de fornecedor e cliente. |
| Fatura de cliente/fornecedor | Uma fatura é inserida para um único cliente ou fornecedor, mas as linhas adicionais representam as linhas da fatura e têm vários ativos fixos ou projetos. | Sim | |
| Diário de pagamento antecipado de cliente com impostos em várias "linhas" | Um cliente faz um pagamento antecipado para uma ordem. As linhas da ordem têm impostos diferentes. O pagamento adiantado do cliente deve conter o cliente em várias linhas, para que os impostos possam ser calculados para cada linha. | Sim | |
| Reembolso do cliente | Se a tarefa periódica de reembolso for executada a partir do Módulo de contas a receber, ela criará uma transação para mover o saldo de um cliente para um fornecedor. O fornecedor é a mesma parte do cliente. | Sim | |
| Manutenção de ativo fixo: atualizar depreciação, dividir ativo e calcular depreciação na alienação | Atualização da depreciação, divisão de um ativo e cálculo de depreciação para a alienação de ativos são usados para criar um único comprovante. | Número | A partir da versão 10.0.21 do Finance, as transações de ativos fixos criadas para atualizar a depreciação, dividir um ativo e calcular a depreciação para a alienação de um ativo usam diferentes números de comprovante. |
| Notas promissórias e letras de câmbio | Letras de câmbio e notas promissórias movem o saldo do cliente e do fornecedor de uma conta contábil de Contas a receber/Contas a pagar para outra, com base no estado do pagamento. Como o mesmo cliente ou fornecedor é usado sempre no comprovante, não há problemas de relatório. | Sim | |
| Remuneração | Os saldos para um fornecedor e cliente são remunerados entre eles porque o fornecedor e o cliente são a mesma parte. Esta abordagem minimiza a troca de dinheiro entre uma organização e a parte do cliente/fornecedor. | Número | A partir do Microsoft Dynamics 365 Finance versão 10.0.40, há o recurso Remuneração de cliente e fornecedor. O recurso de remuneração cria automaticamente dois comprovantes separados para o fornecedor e o cliente. Para obter mais informações, consulte Saldos líquidos de cliente e fornecedor. |
| Transferir saldos | Talvez uma organização tenha que transferir o saldo de um fornecedor para outro em decorrência de um erro ou porque outro fornecedor assumiu a responsabilidade. As transferências desse tipo também ocorrem para tipos de conta como, clientes e contas bancárias. | Sim/Não | As transferências de saldo de uma conta (fornecedor, cliente, conta bancária etc.) para outra conta podem ser feitas através de comprovantes separados e a contrapartida pode ser lançada em uma conta contábil de compensação. Para algumas organizações, essa abordagem requer muita sobrecarga. Portanto, elas escolhem usar Um comprovante único. |
| Liquidar vários pagamentos não lançados na mesma fatura | Esse cenário geralmente é encontrado em organizações nas quais os clientes podem usar vários métodos de pagamento para pagar as compras. Neste cenário, a organização deve ser capaz de registrar vários pagamentos não lançados e liquidá-los com a fatura de cliente. | Número | Um novo recurso adicionado ao Finance permite que vários pagamentos não contabilizados sejam liquidados com uma única fatura. |
| Recursos específicos do país/região | O recurso Documento administrativo único (SAD) para a Polônia atualmente exige que as transações sejam agrupadas, e o número do comprovante é usado para essa finalidade. Pode haver recursos específicos adicionais de país/região que exigem a funcionalidade Um comprovante único. | Sim | |
| Mecanismo para agrupar transações de um evento de negócios | Uma organização tem um evento de negócios que aciona várias transações. O departamento de contabilidade deseja exibir as entradas contábeis juntas para facilitar a auditoria. Um cenário semelhante é aquele no qual as transações bancárias são registradas no Finance por meio de um arquivo recebido do banco. Geralmente, as organizações querem agrupar essas transações usando o número do extrato bancário no arquivo. | Número | Embora o agrupamento de transações seja um cenário válido, o número do comprovante nunca deve ser usado para essa finalidade. Os comprovantes sempre representam transações individuais, nunca um grupo de transações. As transações podem ser agrupadas por outros campos, como o número de lote do diário ou o número do documento. |
| Inserir saldos iniciais | Geralmente as organizações inserem os saldos iniciais das contas do diário-razão auxiliar (fornecedores, clientes, ativos fixos etc) em uma única transação de comprovante. | Número | Os saldos iniciais para cada conta do razão auxiliar devem ser inseridos como comprovantes separados. A contrapartida pode ser lançada em uma conta contábil de compensação, que é compensada pelo saldo inicial da contabilidade. |
| Corrigir a entrada contábil de um documento lançado | Uma organização pode ter de corrigir a conta contábil de Contas a receber ou de Contas a pagar para uma fatura lançada. Como a fatura está correta, ela não deve ser revertida. | Sim/Não | Se uma correção tiver que ser feita na conta contábil do contas a receber ou do contas a pagar, um ajuste poderá ser feito diretamente à conta contábil. Esta abordagem requer que o ajuste seja feito durante um "período de inatividade", de forma que a conta contábil possa permitir temporariamente entradas manuais. Uma desvantagem dessa abordagem é que os relatórios de reconciliação de fornecedor/cliente para o razão mostrarão uma diferença de entrada e saída. O valor líquido é 0 (zero). |
| Lançar resumo na contabilidade | As organizações geralmente querem lançar o resumo na contabilidade para minimizar o volume de dados. Entretanto, as organizações normalmente ainda exigem que os detalhes da transação sejam mantidos. Quando o lançamento é feito em resumo através de apenas um comprovante, os detalhes da transação não são conhecidos e não podem ser mantidos. | Número | Como os detalhes da transação são perdidos, se eles forem necessários, as organizações não devem usar Um Comprovante único para lançar no resumo. |
| “O sistema permite isso” | Geralmente as organizações usam a funcionalidade Um comprovante único meramente porque o sistema permite que elas utilize, sem entender as implicações. | Número | O mero fato de que o sistema habilita a funcionalidade a ser usada nunca é uma razão válida. A funcionalidade deve ser usada somente se for necessário atender a outro requisito comercial. |
O futuro de Um comprovante único
Por causa dos problemas que podem ocorrer quando Um comprovante único é usado, as seguintes opções estão sendo analisadas:
- Novos recursos continuarão a ser introduzidos se houver uma forma melhor de realizar um cenário comercial. Por exemplo, um recurso que foi introduzido no Finance versão 10.0.32 permite que os pagamentos sejam inseridos como comprovantes separados, mas a conta bancária ainda é atualizada no resumo. À medida que os recursos são adicionados, eles serão documentados para cada cenário comercial na coluna "Alternativa" da tabela anterior.
- Algumas transações podem continuar sendo inseridas por meio do diário em um único comprovante, mas dados adicionais podem ser rastreados para identificar corretamente os detalhes transacionais.
- Uma combinação de novos recursos pode ser usada, mas as transações para os cenários comerciais podem continuar sendo inseridas no diário usando um único comprovante.
À medida que novos recursos são introduzidos, sua organização deve avaliar continuamente se a opção Permitir várias transações dentro de um comprovante, na página Parâmetro da contabilidade, pode ser desativada. É recomendável que você não use Um comprovante único para integrações, a menos que você precise da funcionalidade para uma das lacunas funcionais documentadas.
À medida que as lacunas funcionais forem preenchidas, a Microsoft comunicará os novos recursos a serem usados em vez de Um comprovante único. Para alguns cenários comerciais, como uma fatura de fornecedor com várias linhas, Um comprovante único continuará sendo usado, mas com melhorias. Essas melhorias serão comunicadas à medida que forem entregues.