Cst de ibs cbs monofasia

O resultado que importa: o preenchimento do campo tem que bater com o produto cadastrado, senão a base sai errada na apuração. Letícia Costa, você tem razão no ponto da base, então, o cuidado é conferir o campo antes da nota sair. Em varejo a gente vê isso quando o cadastro muda no meio do mês. Recomendo checar o resultado num relatório de conferência antes de liberar o lote.

Eliane, eu não colocaria a regra no código, e sim numa tabela de parâmetros com vigência. Olhando o número, viu, a multiplicação do valor pela unidade de medida já mostra se a regra foi aplicada. Quando a obrigatoriedade muda, basta criar uma nova linha com a data de início, sem mexer no programa. Essa forma vale quando a equipe é pequena e precisa de rastreio. Para o caso municipal, a tabela também ajuda a separar a regra por local.

Discordo com educação. Em resumo, usar só o paliqmonouf como base é arriscado para quem tem tributação em dois níveis. Observação importante: o paliqmonomun precisa entrar na mesma conta, do contrário o total de IBS fica torto. Testei com um item de mineração e a diferença apareceu só no último centavo. Vale checar com o contador antes de fechar.

O risco é tratar todo item monofásico do mesmo jeito, e isso costuma gerar erro de cálculo. Pensando bem, pois é, eu discordo de tratar a legislação como um ajuste do ERP, porque quem define a regra é a norma, não a equipe. Acho que o ajuste deve ficar numa tabela de parâmetros, com a justificativa do responsável registrada. No nosso log, o resultado foi o mesmo nas duas versões.

Paulo Rodrigues, o gmonoret chega vazio? Sem pressa, pois é, eu olharia o imposto retido antes de mexer no item. O gmonoreten costuma vir em sequência, então um deles fica sem valor quando a nota chega de fora. Vale testar com uma nota de saída e outra de entrada para ver qual grupo o sistema preenche.

Se o item for de tributação monofásica, eu seguiria outro caminho: mantenho uma tabela de descrição da mercadoria e deixo a chave fiscal buscar a regra por ali. Bem, em resumo, isso funciona quando a equipe é pequena e não quer mexer no cadastro. Quando o volume cresce, a conta pesa, e a integração eletrônica dos dados de entrada passa a ser a saída mais limpa. Em todo caso, a regra precisa seguir o que o contribuinte decidiu, não o que o time acha melhor.

O resultado que importa é que o campo sai certo quando a regra está no cclasstrib, e não quando alguém mexe no cadastro. A regra fica condicionada à tabela de classes, então o cadastro sozinho não resolve. Voltando ao ponto, viu, eu confiro primeiro o cclasstrib da operação, depois o cadastro do material, e só então reprocesso a nota. Testei assim em homologação e o campo voltou a sair certo.