Um voucher
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, pode introduzir um único voucher que representa uma transação, mas que tem vários clientes, fornecedores, ativos fixos, projetos ou contas bancárias. A Microsoft refere-se a esta funcionalidade como Um comprovativo. Os cenários de Um voucher não incluem transações que incluam apenas contas de razão. Essas transações são lançadas no razão geral, não em livros razão auxiliares, como Contas a receber, Ativos fixos e Banco.
Existem duas categorias de exemplos de Um voucher:
O voucher contém várias transações que foram introduzidas como uma única transação. Eis alguns dos exemplos possíveis:
- São introduzidos vários pagamentos de fornecedor em cada linha (não é utilizada qualquer conta de contrapartida) e a contrapartida da soma de pagamento para uma conta bancária é introduzida numa linha. O resumo do pagamento é feito para atualizar o livro razão auxiliar bancário como um valor resumido que corresponde ao extrato da conta bancária. No entanto, cada transação de fornecedor ainda é registada em detalhe no livro razão auxiliar Contas a pagar. O mesmo cenário também é encontrado no lado do pagamento do cliente.
- Vários ativos fixos são adquiridos num único voucher. Frequentemente, esta abordagem é utilizada quando os saldos iniciais são introduzidos para o módulo Ativos fixos.
O voucher contém uma transação que afeta vários tipos de conta de não razão. Eis alguns dos exemplos possíveis:
- Transferências bancárias
- Compensação de saldos de fornecedores/clientes (mesmas partes)
- Transferência de saldos do cliente A para o cliente B
- Faturas de fornecedor com várias linhas que contêm ativos fixos ou projetos
Os exemplos anteriores para cada categoria representam requisitos de negócio válidos. Por vezes, os requisitos de negócio não podem ser satisfeitos de outra forma: a organização tem de introduzir as transações como Um voucher. No entanto, outras vezes, existem outras formas válidas de satisfazer os requisitos de negócio: as transações podem ser introduzidas de forma diferente ou usar outra caraterística.
Problemas com Um comprovativo
O uso da funcionalidade Um voucher para satisfazer os requisitos de negócio pode causar problemas. Vários processos, reversões de transações e consultas/relatórios requerem detalhes da transação. Esses detalhes não podem ser determinados a partir do modelo de dados atual se várias transações forem introduzidas resumidamente num único voucher. Além disso, os detalhes nem sempre podem ser claramente determinados se o tipo de transação que está a ser inserido é desconhecido. Esta limitação deve-se à flexibilidade dos diários, especialmente quando são introduzidos através do diário geral.
Alguns cenários podem ainda funcionar corretamente, dependendo da configuração da sua organização. Eis as áreas onde pode encontrar problemas:
Liquidação — Se existir mais do que um fornecedor ou cliente num voucher, a contabilidade criada durante a liquidação poderá estar incorretamente alocada às dimensões financeiras. Para mais informações sobre problemas que podem ocorrer durante a liquidação, consulte Voucher único com vários registos de clientes ou fornecedores. O desempenho da liquidação é fortemente influenciado pelo número de linhas do diário de faturas que utilizam Um voucher. Espera-se que o tempo necessário para a liquidação e lançamento do pagamento aumente exponencialmente, quanto mais linhas do diário de faturas usarem Um voucher.
Cálculo do imposto — Se existir mais do que um voucher ou cliente num voucher, a cálculo do imposto poderá estar incorreto.
Reversão de transações — Se existir mais do que um tipo de conta de livro razão auxiliar num voucher, quando uma única transação de livro razão auxiliar for revertida, poderá ser lançada uma entrada contabilística incorreta para a reversão no razão geral. Por exemplo, se adquirir vários ativos num único voucher e, em seguida, reverter a aquisição de um dos ativos, a contabilidade razão geral estará incorreta para a reversão.
Relatórios e consultas — Se incluir mais do que um tipo de conta de livro razão auxiliar (por exemplo, Fornecedor e Cliente) num voucher, os relatórios/consultas mostrarão apenas o primeiro valor de conta encontrado.
Por exemplo, publica a seguinte fatura de fornecedor com várias linhas. Contém quatro projetos que representam as "linhas" na fatura. Esta abordagem é um requisito de negócio comum para organizações que usam diários extensivamente.
Três dos quatro projetos são lançados na mesma conta principal (601500). Se abrir o explorador de origem da Gestão contabilística para ver detalhes sobre as transações lançadas dessa conta principal, notará que o ID do projeto para as três linhas é 000057. Este comportamento é uma limitação conhecida de Um voucher. Os detalhes não irão associar corretamente cada linha ao projeto apropriado no diário. Em vez disso, o primeiro valor da conta encontrado será sempre mostrado em relatórios e consultas.
Introduzir uma transação como Um voucher
Para introduzir transações como Um voucher, aceda a Razão geral > Configuração do livro razão > Parâmetros do razão geral e, em seguida, no separador Livro razão, defina a opção Permitir várias transações com um único voucher como Sim.
Pode introduzir uma transação de Um voucher na página Nomes de diário ao definir o campo Novo voucher para um dos seguintes valores:
- Apenas número de Um voucher — Cada linha adicionada ao diário será incluída no mesmo voucher e as linhas irão conter mais do que um cliente, fornecedor, banco, ativo fixo ou projeto.
- Em ligação ao saldo — Introduza um voucher de várias linhas onde não há conta de contrapartida e as linhas contêm mais do que um cliente, fornecedor, banco, ativo fixo ou projeto.
- Em ligação ao salto — Introduza um voucher de linha única onde tanto a conta como a conta de contrapartida contenham um tipo de conta de razão auxiliar, tal como Fornecedor/Fornecedor, Cliente/Cliente, Fornecedor/Cliente ou Banco/Banco.
O cenário do meu negócio requer Um voucher?
Os seguintes cenários de negócio foram identificados como cenários para os quais os clientes utilizam a funcionalidade Um voucher. Alguns dos requisitos de negócio só podem ser satisfeitos com a utilização de Um voucher. No entanto, para muitos outros, existem alternativas.
Cenário | Descrição | O Um voucher é obrigatório? | Alternativa |
---|---|---|---|
Resumo de pagamento do fornecedor | Uma organização comunica uma lista de fornecedores e valores ao respetivo banco. O banco usa esta lista para pagar aos fornecedores em nome da organização. Cada pagamento de fornecedor tem de ser lançado em detalhe em Contas a pagar, mas a soma dos pagamentos é lançada na conta bancária como um único levantamento. | N.º | A partir da versão 10.0.32 do Microsoft Dynamics 365 Finance, há uma caraterística chamada de Capacidade de lançar pagamentos detalhados de fornecedores e clientes, mas resumir os montantes na conta bancária. Para mais informações, consulte Lançar pagamentos detalhados de fornecedores e clientes. |
Resumo de pagamentos de cliente | Os pagamentos de cliente são depositados como um montante fixo na conta bancária. Cada pagamento de cliente tem de ser lançado em detalhe em Contas a receber, mas a soma dos pagamentos é lançada na conta bancária como um único depósito. | N.º | A partir da versão 10.0.32 do Dynamics 365 Finance, há uma caraterística chamada de Capacidade de lançar pagamentos detalhados de fornecedores e clientes, mas resumir os montantes na conta bancária. Para mais informações, consulte Lançar pagamentos detalhados de fornecedores e clientes. |
Fatura de cliente/fornecedor | Uma fatura é introduzida para um único cliente ou fornecedor, mas linhas adicionais representam as linhas da fatura e têm vários ativos fixos ou projetos. | Sim | |
Diário de pré-pagamento de cliente com impostos em várias "linhas" | Um cliente faz um pré-pagamento para uma encomenda. As linhas da encomenda têm impostos diferentes. O pré-pagamento do cliente tem de 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 de Reembolso for executada a partir de Contas a receber, cria uma transação para mover o saldo de um cliente para um fornecedor. O fornecedor é a mesma parte que o cliente. | Sim | |
Manutenção de ativos fixos: depreciação de atualização, divisão de ativo e cálculo da depreciação na alienação | A depreciação de atualização, a divisão de um ativo e o cálculo da depreciação na alienação de ativos são utilizados para criar um único voucher. | N.º | A partir da versão 10.0.21 do Finance, as transações de ativos fixos criadas para a depreciação de atualização, divisão de um ativo e cálculo da depreciação para a alienação de ativos usam números de voucher diferentes. |
Letras de câmbio e notas promissórias | As letras de câmbio e notas promissórias movem o saldo do cliente ou fornecedor de uma conta de razão 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 fornecedor e o cliente são a mesma parte, os saldos para o fornecedor e cliente são compensados entre si. Esta abordagem minimiza a troca de dinheiro entre uma organização e a parte do cliente/fornecedor. | N.º | A partir da versão 10.0.40 do Microsoft Dynamics 365 Finance, existe a caraterística Compensação de cliente e fornecedor. A caraterística de compensação cria automaticamente dois vouchers separados para o fornecedor e o cliente. Para mais informações, consulte Saldos líquidos de fornecedor e de cliente. |
Transferir saldos | Uma organização pode ter de transferir um saldo de um fornecedor para outro, seja por causa de um erro ou porque outro fornecedor assumiu a responsabilidade. Transferências deste tipo também ocorrem para tipos de contas como Cliente e Banco. | Sim/Não | As transferências de saldo de uma conta (fornecedor, cliente, banco, etc.) para outra podem ser efetuadas através de comprovativos separados e a contrapartida pode ser publicada numa conta de razão transitória. Para algumas organizações, esta abordagem requer muitos custos. Por isso, optam por utilizar Um voucher. |
Liquidar vários pagamentos não lançados para a 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.º | Uma nova caraterística que foi adicionada no Finance permite que vários pagamentos não publicados sejam liquidados contra uma única fatura. |
Caraterísticas específicas de país/região | A caraterística Documento Administrativo Único (SAD) para a Polónia exige atualmente que as transações sejam agrupadas, sendo o número do voucher utilizado para esse efeito. Poderá haver caraterísticas adicionais específicas de cada país/região que requerem a funcionalidade Um voucher. | Sim | |
Mecanismo para agrupar transações de um evento empresarial | Uma organização tem um único evento empresarial que aciona várias transações. O departamento de Contabilidade quer ver as entradas contabilísticas em conjunto para auditoria mais fácil. Um cenário semelhante é aquele em que as transações bancárias são registadas no Finance 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.º | Embora o agrupamento de transações seja um cenário válido, o número do voucher nunca deve ser utilizado para este fim. Os vouchers representam sempre transações individuais, nunca um grupo de transações. Em vez disso, as transações podem ser agrupadas por outros campos, tais como o número do lote do diário ou o número do documento. |
Introduzir saldos iniciais | As organizações introduzem frequentemente saldos iniciais para contas de livros-razão auxiliares (fornecedores, clientes, ativos fixos, etc.) como uma transação única de um voucher. | N.º | Os saldos iniciais de cada conta de razão auxiliar têm de ser introduzidos como vouchers separados. A contrapartida pode ser lançada numa conta de razão de compensação, que é contrapartida pelo saldo inicial do razão geral. |
Corrigir a entrada contabilística de um documento publicado | Uma organização poderá ter de corrigir a conta de razão Contas a receber ou Contas a pagar de uma fatura lançada. Uma vez que a fatura está correta, não deverá ser revertida. | Sim/Não | Se tiver de ser efetuada uma correção na conta de razão de Contas a receber ou Contas a Pagar, pode ser efetuado um ajuste diretamente na conta de razão. Esta abordagem requer que o ajuste seja efetuado durante um "tempo de inatividade", para que a conta de razão possa permitir temporariamente entradas manuais. Uma desvantagem desta abordagem é que os relatórios de reconciliação fornecedor/cliente para livro razão mostrarão uma diferença entre entradas e saídas. O valor líquido é 0 (zero). |
Publicar em resumo no razão geral | As organizações querem frequentemente publicar no razão geral 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 a publicação é efetuada em forma de resumo através de um único voucher, os detalhes da transação não são conhecidos e não podem ser mantidos. | N.º | Uma vez que os detalhes da transação são perdidos, as organizações não podem utilizar o Um voucher para publicar em forma de resumo se os detalhes forem obrigatórios para reporte. |
"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 simples facto de o sistema permitir a utilização da funcionalidade nunca é uma razão válida. A funcionalidade deve ser usada apenas se for necessária para satisfazer outro requisito de negócio. |
O futuro de Um comprovativo
Devido aos problemas que podem ocorrer quando o Um voucher é utilizado, estão a ser exploradas as seguintes opções:
- Novas caraterísticas continuarão a ser introduzidas se houver uma maneira melhor de realizar um cenário de negócios. Por exemplo, uma caraterística que foi introduzida na versão 10.0.32 do Finance permite que os pagamentos sejam introduzidos como vouchers separados, mas a conta bancária ainda é atualizada em forma de resumo. À medida que as caraterísticas são adicionadas, serão documentadas para cada cenário de negócio na coluna "Alternativa" da tabela anterior.
- Algumas transações podem continuar a ser introduzidas através do diário num único voucher, mas dados adicionais podem ser rastreados para identificar corretamente os detalhes transacionais.
- Poderá ser utilizada uma combinação de novas caraterísticas, mas as transações para os cenários de negócio poderão continuar a ser introduzidas no diário utilizando um único voucher.
À medida que novas caraterísticas são introduzidas, a sua organização tem de avaliar continuamente se a opção Permitir várias transações com um voucher na página Parâmetro do razão geral pode ser desativada. Recomendamos que não utilize o Um voucher para integrações, a menos que necessite da mesma para uma das lacunas funcionais documentadas.
À medida que as lacunas funcionais são preenchidas, a Microsoft comunicará as novas caraterísticas a serem utilizados em vez do Um voucher. Para alguns cenários de negócio, como uma fatura de fornecedor com várias linhas, o Um voucher continuará a ser utilizado, mas com melhorias. Essas melhorias serão comunicadas à medida que forem entregues.