Melhorias feitas no cálculo do Custo Médio no Microsoft Dynamics GP

Este artigo discute os seguintes pontos:

• Processos diferentes que ocorrem quando você atualiza para o Microsoft Dynamics GP.
• Os cenários em que as transações de ajuste do Razão Geral são geradas e nos quais os ajustes de custo são feitos.
• O cálculo do custo médio e alguns novos aprimoramentos que são feitos para o cálculo do custo médio no Microsoft Dynamics GP.

Aplica-se a: Microsoft Dynamics GP
Número original do KB: 923960

Atualização para o Microsoft Dynamics GP

Processos que ocorrem quando você atualiza

Durante o processo de atualização, o Microsoft Dynamics GP define os valores dos seguintes campos na tabela IV10200:

• Método de avaliação (VCTNMTHD)
• Quantidade na mão (QTYONHND)
• Custo ajustado (ADJUNITCOST)

Os recibos de compra inseridos antes de atualizar para o Microsoft Dynamics GP não têm os dados necessários para gerar automaticamente transações do Razão Geral ou para recalcular os custos médios. Portanto, os seguintes processos ocorrem quando você atualiza:

• Para cada item que tem um método de avaliação perpétuo ou lifo perpétuo, o Microsoft Dynamics GP identifica o recibo não vendido mais recente que está na tabela IV10200. O Microsoft Dynamics GP define os seguintes valores na tabela IV10200:

  • Método de Avaliação: 1 para FIFO Perpétuo ou 2 para LIFO Perpétuo
  • Quantidade em mãos: a quantidade geral em todos os sites para o item
  • Custo ajustado: o custo unitário do recibo não vendido mais recente para o item

  Observação

  Durante esse processo, os valores que estão no campo Código de Localização e no campo Tipo de Quantidade são ignorados.

• Para cada item que tem um método de avaliação periódica, o Microsoft Dynamics GP identifica o recibo não vendido mais recente na tabela IV10200. O Microsoft Dynamics GP define os seguintes valores na tabela IV10200:

  • Método de avaliação: 4 para um método de avaliação periódica fifo ou 5 para método de avaliação periódica LIFO
  • Quantidade em mãos: a quantidade geral em todos os sites para o item
  • Custo ajustado: o valor que está no campo Custo Atual na janela Manutenção de Item

  Observação

  Durante esse processo, os valores que estão no campo Código de Localização e no campo Tipo de Quantidade são ignorados.

• Para cada item que tem um método de avaliação perpétuo médio, o Microsoft Dynamics GP identifica o recibo não vendido mais recente que está na tabela IV10200. O Microsoft Dynamics GP define os seguintes valores na tabela IV10200:

  • Método de Avaliação: 3
  • Quantidade em mãos: a quantidade geral em todos os sites para o item
  • Custo ajustado: o valor que está no campo Custo Atual na janela Manutenção de Item

  Observação

  Durante esse processo, os valores que estão no campo Código de Localização e no campo Tipo de Quantidade são ignorados.

• Para todos os recibos de compra que não são atualizados por ações mencionadas anteriormente nesta seção, o Microsoft Dynamics GP define o campo Método de Avaliação como zero. O valor zero indica que o recibo foi postado em uma versão do Microsoft Dynamics GP antes da versão 9.0.

• Considere qualquer registro que seja carimbado usando um dos métodos mencionados anteriormente nesta seção. Se algum desses registros tiver um campo Quantity Sold maior que zero, a conversão também criará um registro de detalhes Quantity Sold na tabela IV10201. Este registro mostra o mesmo valor que o campo Quantity Sold para o recibo.

Efeitos em itens de inventário por determinados métodos de avaliação

As seguintes informações se aplicam aos clientes que têm itens de inventário que têm um método de avaliação de Perpétuo Médio, de LIFO Perpétuo ou de FIFO Perpétuo:

• O Microsoft Dynamics GP gera automaticamente ajustes no Razão Geral se um item foi vendido ou consumido do inventário e se o custo foi alterado. Em versões anteriores antes da versão 9.0, o Microsoft Dynamics GP gerou um relatório que instruiva você a inserir manualmente os ajustes na conta de Inventário e na conta custo de mercadorias vendidas (COGS). Essa ação foi projetada para corrigir as contas usadas pelas transações que venderam ou que consumiram os itens. No Microsoft Dynamics GP, esses ajustes agora são gerados automaticamente.

  O Microsoft Dynamics GP salva detalhes adicionais da transação Quantity Sold na tabela IV10201. Esses dados adicionais permitem que o Microsoft Dynamics GP gere as transações de ajuste. O Microsoft Dynamics GP gera o relatório geral postando Diário para as transações de ajuste para as transações de Quantity Sold que são postadas após a atualização para o Microsoft Dynamics GP. O diário de variação de custo ainda exibe uma mensagem para itens que não têm detalhes sobre o valor do campo Quantity Sold . Esta mensagem sugere que você faça um ajuste de custo para transações no Razão Geral.

• Um valor de ajuste é feito para a diferença entre o custo original e o custo recém-determinado da transação postada.

As ações a seguir podem fazer com que o Microsoft Dynamics GP gere transações de ajuste no Razão Geral para Perpétuo Médio, para LIFO Perpétuo ou para itens perpétuos fifo:

• A janela Ajustar Custos de Inventário é usada para alterar o custo unitário de um recibo de compra. O Microsoft Dynamics GP calcula a diferença de custo para determinar a quantidade necessária de ajuste para uma transação.
• Os usuários selecionam para reavaliar o inventário quando postam uma fatura de compra na qual o custo da fatura difere do custo de remessa.
• Um item de linha de pedido de compra será alterado para um status de Fechado se as seguintes condições forem verdadeiras para a ordem de compra:
  • O valor do campo Quantity Shipped é maior que o valor do campo Quantity Invoiced .
  • O valor do campo Faturado de Quantidade não é zero.
• Uma transação de Retorno de Ordem de Compra é postada.
• Um recibo de compra é inserido em uma pilha de recibos de compra existente quando a data de postagem vem antes da data de um recibo de compra existente.

Os seguintes cenários fazem com que ajustes de custo sejam gerados:

• Você posta uma transação de remessa de pedido de compra que tem os seguintes valores:
  • Quantidade enviada: 100
  • Custo Unitário: $1,00
• Você posta uma fatura de vendas que tem os seguintes valores:
  • Quantidade Enviada: 10
  • Custo Unitário: $1,00
  • Quantidade faturada: $10
• Você recebe uma transação de Fatura de Pedido de Compra para a remessa que foi postada usando um custo unitário de US$ 2 cada. Você reavalia o inventário usando um dos seguintes métodos:
  • Você debita a conta inventário para a reavaliação de $100.
  • Você debita a conta Compras Acumuladas por US$ 100 e credita a conta Contas a pagar por US$ 200.
  • Você credita a conta de inventário pelos US$ 10 que foram removidos depois que o recibo original foi postado. Para equilibrar essa fatura, você deve debitar a conta COGS por US$ 10.

Informações de postagem do Razão Geral

Transações de postagem do Razão Geral que são geradas automaticamente

As seguintes condições são verdadeiras para as transações de postagem do Razão Geral que são geradas automaticamente:

• O Microsoft Dynamics GP usa as preferências de postagem inseridas para a série na qual a transação se originou. O programa usa um tipo de entrada Origin de Entrada Geral.

• O destino do relatório de postagem é selecionado usando a janela Configuração de Postagem na qual o campo Série está definido como Financeiro e o campo Relatório é definido como Postagem Geral Diário.

• Ao postar um documento usando a postagem em nível de transação, o Microsoft Dynamics GP segue as regras existentes. O programa posta no Razão Geral em vez de por meio do Razão Geral.

• O Microsoft Dynamics GP sempre posta em resumo.

• Depois que o Microsoft Dynamics GP cria com êxito transações do Razão Geral, essas transações são adicionadas a um lote do Razão Geral que tem os seguintes atributos:

  • ID do lote: gerado pelo sistema

  • Origem: Entrada Geral

  • Comentário: Ajuste de custo

  • Frequência: Uso Único

  • O Microsoft Dynamics GP honra as opções "post to" e "post through" da série na qual a transação se originou.

  • Quando você posta um lote de um módulo, o Microsoft Dynamics GP cria uma entrada de diário para cada documento nesse lote que faz com que um ajuste de Razão Geral seja gerado. Exemplos desses módulos são Processamento e Inventário de Pedidos de Vendas. Pode haver várias contas que estão postando em resumo.

    Observação

    Dependendo da opção selecionada na janela Instalação de Postagem, o Microsoft Dynamics GP executa ações diferentes para um lote de entrada geral que tem os atributos mencionados neste item bullet. Se você selecionar a opção Criar Novo , o programa criará um novo lote se a entrada ainda existir no Razão Geral. Se você selecionar a opção Append , o programa adicionará as transações ao lote existente. Uma exceção ocorre quando as transações se originam da janela Ajustar Custos de Inventário. Nesse caso, o Microsoft Dynamics GP sempre cria um novo lote.

  • Considere os seguintes exemplos de como o Microsoft Dynamics GP honra as opções "post to" e "post through" para transações de alteração de custo:

    • No Processamento de Pedidos de Vendas, um documento de retorno datado de data/data cria uma entrada de diário de alteração de custo. Essa entrada de diário de alteração de custo honrará as opções "post to" e "post through" para a origem da Entrada de Transação de Vendas da série Sales.
    • No Processamento de Pedidos de Compra, um recibo de remessa datada cria uma entrada de diário de alteração de custo. Essa entrada de diário de alteração de custo honrará as opções "post to" e "post through" para a origem da Entrada de Transação de Recebimentos da série Compras.
    • No Inventário, um ajuste de aumento datado de back-dated cria uma entrada de diário de alteração de custo. Essa entrada de diário de alteração de custo honrará as opções "post to" e "post through" para a origem da Entrada de Transação da Série de Inventário.

• Considere os seguintes valores para um item:

  • Conta de variação de preço de compra
  • Conta de inventário
  • Conta de deslocamento de inventário
  • Conta de variação de inventário

  Quando o Microsoft Dynamics GP deve obter esses valores, o seguinte processo ocorre:

  • O Microsoft Dynamics GP tenta primeiro obter a conta da janela Manutenção da Conta de Item.
  • Se a conta estiver em branco na janela Manutenção da Conta de Item, o Microsoft Dynamics GP tentará obter a conta da janela Configuração de Contas de Postagem. Nesta janela, o campo Exibição é definido como Inventário.
  • Se o Microsoft Dynamics GP não conseguir obter a conta necessária durante as etapas mencionadas anteriormente, a conta ficará em branco.

• A substituição de site é aplicada quando o Microsoft Dynamics GP obtém uma conta para o item.

• Uma transação de Razão Geral é salva no lote do Razão Geral e essa conta fica em branco se as seguintes condições forem verdadeiras:

  • O Microsoft Dynamics GP tenta criar uma transação de Razão Geral usando contas de uma transação de detalhes do Quantity Sold.
  • Uma ou mais dessas contas não são mais válidas ou não existem mais.

• Se pelo menos uma transação tiver uma conta de postagem em branco, o Microsoft Dynamics GP não postará o lote, mesmo que a caixa Post to General Ledger marcar seja selecionada na janela Configuração de Postagem para a série Inventário. Você deve inserir um número de conta para que o lote possa ser postado.

• Ao postar, o Microsoft Dynamics GP verifica as contas de postagem para verificar se elas estão ativas. Se uma conta estiver inativa, o Microsoft Dynamics GP postará no módulo Inventário e criará um lote do Razão Geral para essa transação.

Itens que usam o método de avaliação perpétuo média

As seguintes condições são verdadeiras para itens que usam o método de avaliação perpétuo médio:

• O custo atual (médio) é automaticamente recalculado após essas ações adicionais:

  • O usuário opta por reavaliar o inventário quando o usuário posta uma fatura de pedido de compra para a qual o custo da fatura difere do custo de remessa.
  • O usuário usa a janela Ajustar Custos de Inventário para editar o custo de um registro de recibo de compra.
  • O usuário altera o status de um item de linha de pedido de compra para Fechado se o valor do campo Quantity Shipped para o item de linha for maior que o valor do campo Quantity Invoiced e se o valor do campo Quantity Invoiced não for zero.
  • O usuário posta uma transação de Retorno de Ordem de Compra.
  • O usuário insere um recibo de compra em uma pilha de recibos de compra existente.

• O recálculo do custo médio (atual) de um item e os ajustes no valor de Quantity Sold de um Perpétuo Médio, um LIFO Perpétuo ou um item perpétuo FIFO ocorrem somente quando você ajusta um recibo de compra que foi postado após a atualização para o Microsoft Dynamics GP. Como o Microsoft Dynamics GP não armazena os dados necessários antes de atualizar para o Microsoft Dynamics GP, você não pode recalcular o custo médio ou postar transações ajustadas para os recibos de compra mais antigos.

• O Microsoft Dynamics GP executará as seguintes ações se o custo unitário de um recibo de compra existente para um item de custo médio for atualizado:

  • O Microsoft Dynamics GP primeiro recalcula o novo custo ajustado para o registro de recebimento atualizado usando a seguinte fórmula:

    {(Quantidade do Recibo Anterior Na Mão x Custo Unitário Ajustado do Recibo Anterior) + [(Quantidade de Recebimento – Retornado pela Quantidade) x Custo Unitário de Recibo]} ÷ [Quantidade do Recibo Anterior Na Mão + (Quantidade do Recibo Na Mão - Quantidade Retornada)]

    Observação

    • Se o valor quantity On Hand do Recibo Anterior for negativo, o Microsoft Dynamics GP usará zero para esse valor na fórmula.
    • O valor Quantity On Hand do Recibo é específico da data e é o valor total para todos os sites. Para um recibo de compra, o valor Quantity On Hand do Recibo reflete a quantidade total em mãos após a publicação desse recibo. Ou seja, o valor Quantity On Hand do Recibo inclui a quantidade desse recibo.
    • Se o valor Retornado de Quantidade for subtraído do valor Recebido da Quantidade quando você postar uma transação retorno de PO, o Microsoft Dynamics GP aumentará o valor de Venda de Quantidade do recibo de compra em vez de reduzir o valor Recebido pela Quantidade . Portanto, para obter um valor recebido em quantidade real, o Microsoft Dynamics GP deve examinar a nova tabela de detalhes da Quantidade Vendida para transações de retorno de PO e subtrair o valor Quantity Returned do valor Recebido em Quantidade .

  • Se houver um recibo de compra datado mais tarde do que o recibo de compra ajustado, o Microsoft Dynamics GP recalculará o custo atual (médio) para o próximo recibo de compra para calcular o novo custo ajustado para o próximo registro de recibo. Esse processo continua para cada recibo de compra subsequente. Esse processo continua por meio da pilha para determinar o custo ajustado a partir da data do usuário. Esse novo valor torna-se o custo atual. À medida que o processo continua para cada recibo de compra subsequente, o Microsoft Dynamics GP atualiza o custo ajustado para cada recibo de compra. Além disso, o Microsoft Dynamics GP atualiza o valor de custo ajustado para cada transação quantity sold que é datada mais tarde do que um recibo de compra ajustado e anterior ao próximo recibo. Essa ação é baseada na data de recebimento. Essa ação também usa o custo ajustado do recibo de compra anterior.

    Observação

    Quando um recibo de compra é registrado, o Microsoft Dynamics GP preenche o valor de Quantidade de Inventário à Mão para um recibo de compra usando um valor igual à soma da seguinte equação:
    (Quantidade de Inventário à Mão para o recibo anterior) + (Qty Recebido para o recibo anterior) - (Transações Qty Sold que ocorreram após esse recibo de compra foram registradas, mas antes do próximo recibo de compra, com base na data)
    O exemplo a seguir pressupõe que as seguintes condições são verdadeiras:

    • A quantidade inicial em mãos é zero
    • Não houve transações de Retorno de Ordem de Compra

    Tipo de transação	Inventário na mão Qty	Qty Recebido	Qty Vendido	Custo Unitário	Custo ajustado
    Recibo nº 1	100	100		$1,00	$1,00
    Recibo nº 2	125	100		$1,50	$1,25
    Venda nº 1			50	$1,25	$1,25
    Venda nº 2			25	$1,25	$1,25
    Recibo nº 3	200	100		$1,20	$1,23
    Venda nº 3			25	$1,23	$1,23
    Recibo nº 4	250	100		$1,30	$1,25
    Venda nº 4			50	$1,25	$1,25

    O cálculo para Recibo nº 1 usa a seguinte fórmula:[(0 x $0,00) + (100 x $1,00)] ÷ [0 + (100 - 0)] = $1,00

    O cálculo para Recibo #3 usa a seguinte fórmula:[(125 x $1,25) + (100 x $1,20)] ÷ [125 + (100 - 0)] = $1,227

    Observação

    A soma desse cálculo é arredondada para US$ 1,23.

• Quando o custo unitário de um recibo de compra existente é atualizado, o Microsoft Dynamics GP recalcula o custo ajustado do recibo de compra usando os seguintes valores na fórmula de cálculo de custo médio:

  • Valores de quantidade de inventário salvos na mão
  • Valores de custo ajustados do recibo anterior
  • Valores recebidos de quantidade salva
  • Novos valores de Custo Unitário

  Um exemplo de situação em que um recibo de compra existente é atualizado é a seguinte situação:

  • Você reavalia o inventário para uma variação de preço de compra em uma fatura de pedido de compra.
  • A fatura é para uma variação de material ou para uma variação de custo desembarcada.

  Se houver um registro de recibo que seja datado mais tarde do que o recibo atualizado, o Microsoft Dynamics GP recalculará o custo ajustado para o registro de recebimento usando as etapas e a fórmula de cálculo de custo média mencionada anteriormente nesta seção. O Microsoft Dynamics GP atualiza o campo Custo Atual na janela Manutenção de Item usando o novo custo ajustado para o registro final de recibo de compra. Além disso, neste exemplo, as alterações feitas pelo custo ajustado são mostradas na tabela a seguir.

  Observação

  Esta tabela pressupõe que as seguintes condições sejam verdadeiras:

  • Você posta uma fatura de pedido de compra para o Recibo nº 3 a um custo unitário de US$ 1,28.
  • Você escolhe reavaliar o inventário.
  • A remessa foi postada anteriormente a um custo unitário de US$ 1,20.

  Quando essas condições são verdadeiras, o Microsoft Dynamics GP atualiza o custo unitário na pilha de recibos para US$ 1,28. Em seguida, o programa recalcula o custo ajustado para cada recibo subsequente começando nesse registro de recebimento.

  Tipo de transação	Inventário na mão Qty	Qty Recebido	Qty Vendido	Custo Unitário	Custo ajustado
  Recibo nº 1	100	100		$1,00	$1,00
  Recibo nº 2	125	100		$1,50	$1,25
  Venda nº 1			50	$1,25	$1,25
  Venda nº 2			25	$1,25	$1,25
  Recibo nº 3	200	100		$1,28	$1,26
  Venda nº 3			25	$1,23	$1,26
  Recibo nº 4	250	100		$1,30	$1,27
  Venda nº 4			50	$1,25

  O cálculo para Recibo #3 usa a seguinte fórmula:[(125 x $1,25) + (100 x $1,28)] ÷ [125 + (100 - 0)] = $1,263

  Observação

  A soma desse cálculo é arredondada para US$ 1,26.

  O cálculo do Recibo nº 4 usa a seguinte fórmula:[(200 * $1,26) + (100 * $1,30)] ÷ [200 + (100 - 0)] = $1,273

  Observação

  A soma desse cálculo é arredondada para US$ 1,27.

  • O Microsoft Dynamics GP gera algumas transações de ajuste para as transações detalhadas do Quantity Sold que são atualizadas com base no custo ajustado do recibo de compra. As transações de ajuste usam os números da conta que foram usados para a transação original e que são armazenados na tabela IV10201.

• As alterações a seguir se aplicam se você criar e postar uma transferência de inventário de um item de custo médio:

  • As transferências do tipo de quantidade On Hand para qualquer outro tipo de quantidade usam o custo atual do item.
  • As transferências de tipos de quantidade diferentes de On Hand usam o custo FIFO em vez do custo atual do item. Se você criar a transferência, o custo unitário do item usará o valor de custo atual. No entanto, quando a transferência é postada, o Microsoft Dynamics GP obtém o custo FIFO da pilha de recibos de compra.
  • Se o custo unitário da transação difere do custo atual de um item, o Microsoft Dynamics GP recalculará o custo atual (médio) do item após uma transferência de inventário para o tipo de quantidade On Hand .