Código crédito presumido ibs cbs

Simone Moreira, seguindo sua linha de raciocínio sobre a rejeição quando o indicador está zerado, gostaria de trazer uma outra consideração sobre a validação. Quando encontramos o grupo de crédito presumido na operação com o indicador não permitido, e queremos endereçar isso corretamente, uma dica de colega, tá, é que precisamos verificar se o documento fiscal anterior possui algum detalhe que possa mitigar essa não permissão. Isso pode nos dar mais segurança ao mapear o fluxo no ECC 6.0.

Ana Nascimento, complementando o que foi dito, acho que precisamos olhar como o sistema trata o uso da tabela cCredPres. Se o indicador permite a operação, precisamos garantir que o nosso mapeamento do código de classificação tributária esteja alinhado com o que o fisco espera ao cruzar as informações. A dica é, pois é, que a coerência entre o campo de operação e o código da classificação do crédito presumido precisa ser absoluta ao gerar a NF-e. Qualquer desencontro nessa fase pode levar à rejeição por parte do órgão competente.

Entendo seu ponto sobre o indicador permitir a opção, mas acho que precisamos olhar também para o fluxo de saída. Se estamos no S/4HANA e o mapeamento do campo está correto, precisamos apenas assegurar que a geração do documento fiscal subsequente também esteja coerente com a permissão dada no momento da entrada. Pois, que eu saiba, né, a validação cruzada entre as transações é onde costumam aparecer os maiores desencontros.

Então, o custo é, o mapeamento do indicador indgCredPresOper dentro da cClassTrib é o ponto nevrálgico para habilitar a funcionalidade do crédito presumido no módulo IBS e CBS. Este parâmetro, ao receber o valor um, sinaliza que o contribuinte tem a liberdade de aplicar esse benefício sem que haja uma imposição operacional. Portanto, o custo é assegurar que este campo esteja corretamente configurado no S/4HANA para evitar rejeições durante a geração da nota fiscal eletrônica.