Um comprovativo

Importante

Algumas ou a totalidade das funcionalidades abordadas neste artigo encontram-se disponíveis como parte de uma versão de pré-visualização. Os conteúdos e as funcionalidades encontram-se sujeitos a alterações. Para mais informações sobre as versões de pré-visualização, consulte Disponibilidade de atualizações do serviço.

O que é Um comprovativo?

Devido à flexibilidade dos diários financeiros, é possível introduzir um único comprovante que represente uma transação, mas que tenha vários clientes, fornecedores, activos fixos, projectos ou contas bancárias. A Microsoft refere-se a esta funcionalidade como Um voucher. Os cenários de um voucher não não incluem transacções que incluem apenas contas de ledger. Essas transacções são lançadas no Razão e não em livros auxiliares como Contas a receber, Activos fixos e Banco.

Existem duas categorias de exemplos de cupões One:

• O voucher contém várias transacções que foram introduzidas como uma única transação. Eis alguns dos exemplos possíveis:

  • Os pagamentos de vários fornecedores são entrados em cada linha (não é usada uma conta de contrapartida) e o montante de pagamento compensado para uma conta bancária é entrado numa linha. A compactação de pagamentos é feita para atualizar o livro auxiliar do banco como um montante compactado que corresponde ao extrato de conta bancária. No entanto, cada operação do fornecedor continua a ser registada em detalhe no livro auxiliar de Contas a pagar. O mesmo cenário também se verifica no lado do pagamento ao cliente.
  • Vários activos fixos são adquiridos num único voucher. Esta abordagem é com frequência utilizada quando os saldos iniciais são introduzidos para o módulo Fixed assets .

• O voucher contém uma transação que afecta vários tipos de contas não contabilísticas. Eis alguns dos exemplos possíveis:

  • Transferências bancárias
  • Compensação de saldos de fornecedores/clientes (mesma parte)
  • Transferência de saldos do cliente A para o cliente B
  • Facturas de fornecedores com várias linhas que contêm activos fixos ou projectos

Os exemplos anteriores para cada categoria representam requisitos comerciais válidos. Por vezes, os requisitos comerciais não podem ser satisfeitos de outra forma: a organização tem de registar as transacções como Um voucher. No entanto, noutras ocasiões, existem outras formas válidas de satisfazer os requisitos comerciais: as transacções podem ser introduzidas de forma diferente ou utilizar outra caraterística.

Problemas com Um comprovativo

A utilização da funcionalidade Um voucher para satisfazer os requisitos da empresa pode causar problemas. Vários processos, estornos de transacções e inquéritos/relatórios requerem detalhes da transação. Esses detalhes não podem ser determinados a partir do modelo de dados atual se forem introduzidas várias transacções resumidas num único comprovante. Além disso, os detalhes nem sempre podem ser claramente determinados se o tipo de transação que está a ser introduzido for desconhecido. Esta limitação é causada pela flexibilidade dos diários, especialmente quando são reintroduzidos através do diário geral.

Alguns cenários poderão ainda funcionar corretamente, dependendo da configuração da sua organização. Eis algumas áreas em que pode encontrar problemas:

• Liquidação - Se existir mais do que um fornecedor ou cliente num voucher, a contabilidade criada durante a liquidação pode ser incorretamente atribuída a dimensões financeiras. Para mais informações sobre os problemas que podem ocorrer durante a liquidação, consulte Voucher único com vários registos de clientes ou fornecedores.

• Cálculo do imposto - Se existir mais do que um vale ou cliente num vale, o cálculo do imposto pode estar incorreto.

• Estorno de transação - Se existir mais do que um tipo de conta do livro auxiliar num vale, quando uma única transação do livro auxiliar é estornada, pode ser lançado um lançamento contabilístico incorreto para o estorno no livro geral. Por exemplo, se você adquirir vários ativos em um único voucher e depois estornar a aquisição de um dos ativos, a contabilidade do Razão estará incorreta para o estorno.

• Relatórios e inquéritos - Se incluir mais do que um tipo de conta do livro auxiliar (por exemplo, Fornecedor e Cliente) num voucher, os relatórios/inquéritos mostrarão apenas o primeiro valor de conta encontrado.

  Por exemplo, lança-se a seguinte fatura de fornecedor com várias linhas. Contém quatro projectos que representam as "linhas" da fatura. Esta abordagem é um requisito comercial comum para as organizações que utilizam os diários de forma extensiva.

  

  Três dos quatro projectos são lançados na mesma conta principal (601500). Se abrir o Explorador da fonte de contabilidade para ver os detalhes sobre as transacções lançadas para essa conta principal, verá que o ID do projeto para as três linhas é 000057. Isto comportamento é uma limitação conhecida do One voucher. Os detalhes não ligam corretamente cada linha ao projeto apropriado no diário. Em vez disso, o primeiro valor de conta encontrado será sempre apresentado nos relatórios e nas consultas.

  

Introduzir uma transação como Um voucher

Para introduzir transacções como Um voucher, vá a Razão > Configuração do ledger > Parâmetros do ledger geral e, em seguida, no separador Ledger , defina a opção Permitir várias transacções num voucher para Sim.

Pode introduzir uma transação de Um comprovativo na página Nomes de diário definindo o campo Novo comprovativo para um dos seguintes valores:

• Apenas um número de comprovante - Cada linha que você adicionar 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 onde não há conta de contrapartida e as linhas contêm mais de um cliente, fornecedor, banco, ativo fixo ou projeto.
• Em relação ao saldo - Introduza um comprovativo de linha única em que tanto a conta como a conta de contrapartida contêm um tipo de conta do livro auxiliar, como Fornecedor/Fornecedor, Cliente/Cliente, Fornecedor/Cliente, ou Banco/Banco.

O meu cenário empresarial exige um vale?

Os seguintes cenários empresariais foram identificados como cenários para os quais os clientes utilizam a funcionalidade Um vale. Alguns requisitos comerciais só podem ser satisfeitos através da utilização de um voucher. No entanto, para muitos outros, existem alternativas.

Cenário	Descrição	É necessário um vale?	Alternativa
Compactação de pagamentos do fornecedor	Uma organização comunica uma lista de fornecedores e montantes ao seu banco. O banco utiliza esta lista para pagar aos fornecedores em nome da organização. Cada pagamento de fornecedor deve ser lançado detalhadamente em Contas a pagar, mas a soma dos pagamentos é lançada na conta bancária como uma única retirada.	Não	A partir da versão 10.0.32 do Microsoft Dynamics 365 Finance, existe uma funcionalidade denominada Capacidade de lançar pagamentos detalhados de fornecedores e clientes, mas resumir os montantes na conta bancária. Para obter mais informações, consulte Lançar pagamentos detalhados de fornecedores e clientes.
Compactação de pagamentos de clientes	Os pagamentos dos clientes são depositados como um montante fixo na conta bancária. Cada pagamento de cliente deve ser lançado detalhadamente em Contas a receber, mas a soma dos pagamentos é lançada na conta bancária como um depósito único.	Não	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 os valores para a conta bancária. Para obter mais informações, consulte Lançar pagamentos detalhados de fornecedores e clientes.
Fatura do fornecedor/cliente	Uma fatura é entrada para um único cliente ou fornecedor, mas as linhas adicionais representam as linhas da fatura e têm múltiplos activos fixos ou projectos.	Sim
Diário de pré-pagamento de cliente com impostos em várias "linhas"	Um cliente efectua um pré-pagamento de uma encomenda. As linhas da encomenda têm impostos diferentes. O pagamento de cliente de pré-pagamento deve conter o cliente em várias linhas, para que os impostos possam ser calculados para cada linha.	Sim
Reembolso de clientes	Se a tarefa periódica Reembolso for executada a partir de Contas a receber, ela cria uma operação para mover o saldo de um cliente para um fornecedor. O fornecedor é a mesma parte que o cliente.	Sim
Manutenção de activos fixos: Depreciação acumulada, divisão de um ativo e cálculo da depreciação na alienação	A depreciação acumulada, a decomposição de um imobilizado e o cálculo da depreciação para a alienação do imobilizado são utilizados para criar um único comprovante.	Não	A partir da versão 10.0.21 do Finance, os movimentos do imobilizado criados para a depreciação de recuperação, a decomposição de um imobilizado e o cálculo da depreciação para a alienação do imobilizado usam números de comprovante diferentes.
Letras de câmbio e notas promissórias	As letras de câmbio e as notas promissórias deslocam o saldo do cliente ou do fornecedor de uma conta do registo de Contas a receber ou Contas a pagar para outra, com base no estado do pagamento. Uma vez que o mesmo cliente ou fornecedor é sempre utilizado no voucher, não existem problemas de reporte.	Sim
Compensação	Se um cliente e um fornecedor forem a mesma parte, os saldos do fornecedor e do cliente são compensados entre si. Esta abordagem minimiza a troca de dinheiro entre uma organização e a parte do cliente/fornecedor.	Não	Desde a versão 10.0.40 do Microsoft Dynamics 365 Finance, existe a funcionalidade Compensação de clientes e fornecedores . A função de compensação cria automaticamente dois comprovantes separados para o fornecedor e o cliente. Para obter mais informações, consulte Saldos líquidos de fornecedores e clientes.
Transferir saldos	Uma organização pode ter que transferir um saldo de um fornecedor para outro, seja por causa de um erro ou porque outro fornecedor assumiu a responsabilidade. As transferências deste tipo também ocorrem para tipos de contas como Customer e Bank.	Sim/Não	As transferências de saldo de uma conta (fornecedor, cliente, banco, etc.) para outra podem ser feitas por meio de comprovantes separados, e a contrapartida pode ser lançada em uma conta de ledger de compensação. Para algumas organizações, esta abordagem exige demasiadas despesas gerais. Por conseguinte, optam por utilizar o vale One.
Liquidação de vários pagamentos não lançados na mesma fatura	Este cenário é normalmente encontrado em organizações onde os clientes podem utilizar vários métodos de pagamento para pagar as suas compras. Neste cenário, a organização tem de conseguir registar vários pagamentos não publicados e liquidá-los contra a fatura do cliente.	Não	Uma nova funcionalidade que foi adicionada ao Finance permite que vários pagamentos não lançados sejam liquidados contra uma única fatura.
Funcionalidades específicas do país/região	A funcionalidade do Documento Administrativo Único (DAU) para a Polónia exige atualmente que as transacções sejam agrupadas e o número do vale é utilizado para isto fim. Poderão existir características adicionais específicas de cada país/região que exijam a funcionalidade Um vale.	Sim
Mecanismo para agrupar transações de um evento empresarial	Uma organização tem um único evento que desencadeia várias transacções. O departamento de contabilidade pretende visualizar os lançamentos contabilísticos em conjunto para facilitar a auditoria. Um cenário semelhante é aquele em que as transacções bancárias são registadas nas Finanças através de um ficheiro que é recebido do banco. As organizações querem frequentemente agrupar essas transações utilizando o número do extrato bancário no ficheiro.	Não	Embora o agrupamento de transacções seja um cenário válido, o número do vale nunca deve ser utilizado para isto fim. Os vales representam sempre transacções individuais, nunca um grupo de transacções. Em vez disso, as transações podem ser agrupadas por outros campos, como o número do lote do diário ou o número do documento.
Registo de saldos iniciais	As organizações entram com frequência os saldos iniciais das contas do livro auxiliar (fornecedores, clientes, activos fixos, etc.) como um único movimento de comprovante.	Não	Os saldos iniciais de cada conta do livro auxiliar devem ser registados em talões separados. A contrapartida pode ser lançada em uma conta de compensação, que é compensada pelo saldo inicial do Razão.
Correção do lançamento contabilístico de um documento lançado	Uma organização pode ter de corrigir a conta do ledger de Contas a receber ou Contas a pagar para uma fatura lançada. Uma vez que a fatura está correcta, não deve ser anulada.	Sim/Não	Se tiver de ser feita uma correção na conta do ledger de Contas a receber ou Contas a pagar, pode ser feito um ajustamento diretamente na conta do ledger. Esta abordagem requer que o ajustamento seja efectuado durante um "período de inatividade", de modo a que a conta do ledger possa temporariamente permitir a entrada manual. Uma desvantagem desta abordagem é que os relatórios de reconciliação entre fornecedor/cliente e ledger mostrarão uma diferença entre entradas e saídas. O valor líquido é 0 (zero).
Lançamento sumário no razão geral	Muitas vezes, as organizações querem efetuar lançamentos no Razão de forma resumida, para minimizar a quantidade de dados. No entanto, essas organizações normalmente ainda requerem que os detalhes da transação sejam mantidos. Quando o lançamento é feito em resumo através de um único comprovante, os detalhes da transação não são conhecidos e não podem ser actualizados.	Não	Uma vez que os detalhes da transação se perdem, as organizações não devem utilizar um voucher para lançar em resumo se os detalhes forem necessários para o relatório.
"O sistema permite"	As organizações utilizam frequentemente a funcionalidade Um comprovativo apenas porque o sistema lhes permite utilizá-la, sem compreenderem as implicações.	Não	O simples facto de o sistema permitir a utilização da funcionalidade nunca é uma razão válida. A funcionalidade só deve ser utilizada se for necessária para satisfazer outro requisito comercial.

O futuro de Um comprovativo

Devido aos problemas que podem ocorrer quando é utilizado um vale, estão a ser exploradas as seguintes opções:

• Continuarão a ser introduzidas novas funcionalidades se houver uma melhor forma de realizar um cenário comercial. Por exemplo, uma funcionalidade que foi introduzida na versão 10.0.32 do Finance permite que os pagamentos sejam introduzidos como talões separados, mas a conta bancária continua a ser actualizada em resumo. À medida que as funcionalidades forem adicionadas, serão documentadas para cada cenário empresarial na coluna "Alternativa" da tabela anterior.
• Algumas transacções podem continuar a ser introduzidas através do diário num único voucher, mas podem ser rastreados dados adicionais para identificar corretamente os detalhes da transação.
• Poderá ser utilizada uma combinação de novas funcionalidades, mas as transacções para os cenários empresariais poderão continuar a ser introduzidas no diário utilizando um único voucher.

À medida que são introduzidas novas funcionalidades, a sua organização tem de avaliar continuamente se a opção Permitir várias transacções num único voucher na página General ledger parameter pode ser desactivada. Recomendamos que não utilize o One voucher para integrações, a menos que necessite da funcionalidade para uma das lacunas funcionais documentadas.

À medida que as lacunas funcionais forem colmatadas, a Microsoft comunicará as novas funcionalidades a utilizar em vez do One voucher. Para alguns cenários empresariais, como uma fatura de fornecedor com várias linhas, o Talão único continuará a ser utilizado, mas com melhorias. Essas melhorias serão comunicadas à medida que forem sendo efectuadas.