Retenção irrf 4 8

Concordo em parte com a Mônica, mas discordo do receio. Veja, o x da questão é a ordem do que se confere, e um caminho a avaliar no ECC 6.0 é dividir a conferência em duas etapas: na primeira, só as linhas destacadas com IRRF; na segunda, o resto. Vale quando o volume é alto e dá para olhar o crédito ao fornecedor sem pressa; se o dia é curto, o ideal vai depender de quem confere e de quanto tempo sobra.

Num projeto de e-commerce em S/4HANA 2021, o IRRF de prestadores chegava junto com outros valores na mesma nota. Larissa, concordo em separar, e agora, por experiência, acrescento um cuidado: guarde em cada registro o tributo a que a parcela pertence, senão as retenções ficam misturadas e a apuração perde o rastro. Um campo simples de classificação já ajuda na conferência antes do envio.

Será que a competência manda mesmo em tudo? Conforme o combinado, viu, aqui a gente fecha olhando a competência da nota, e no log do GUEPARDO Tax o IRRF subiu junto com a contribuição. Discordo da Larissa em deixar o IRRF para uma segunda rodada: com fechamento curto, não quero um dado ficando para depois sem ninguém lembrar.

O resultado é este: não dá para fixar uma regra única sem olhar cada caso. No meu projeto, pois é, o pagamento do IRRF às vezes vem antes do registro contábil, e é possível que dois períodos fiquem abertos por causa de uma só nota. Moisés, discordo de resolver tudo com teste de aceite; eu validaria por amostra com a área fiscal do cliente, porque a decisão tributária é do contribuinte.

Quando a nota traz retenção previdenciária e IRRF ao mesmo tempo, um caminho a avaliar é separar as duas no S/4HANA 2023, cada uma com a sua data de controle. Na prática, ó, funciona se o fechamento comporta uma conferência a mais; se a pressa é grande, vale olhar primeiro o IRRF e deixar a previdenciária para uma segunda rodada. No log do job de transmissão dá para ver qual das duas rodou antes.

Aqui na empresa, né, vale lembrar da migração. Aqui na casa, né, vindo de outro ERP, o mais difícil foi aceitar que o IRRF pode ocorrer em data diferente da nota. Kleber, no sistema antigo o que ocorreu foi uma data única para tudo. Ao passar para o SAP, mapeamos cada evento que pode ocorrer separadamente, e as diferenças que ocorrem entre notas e baixas viraram teste de aceite antes de ligar o envio.

Vinícius, obrigado pelo ponto. E aí, no meu time, o programa que lê as notas ainda amarra tudo numa data só, e já perdi horas com IRRF divergente. No ECC 6.0 dá para tratar os geradores em separado sem mexer na estrutura inteira? Em que momento do lançamento você grava a data certa, e existe necessidade de criar campo novo?

Já vi relatório antecipar o IRRF porque o programa tratava a data de emissão da nota como gerador do imposto. Ano passado, no ECC 6.0, isso jogou o valor no mês errado. Por exemplo, a nota sai num dia, o beneficiário só recebe semanas depois, e a tela mostra tudo junto. Jefferson, discordo de confiar só na linha própria: sem a data certa gravada, ela organiza a informação, mas não corrige o mês.

Concordo em parte com a Helena, mas falta um ponto. Puxando o fio, pois é, uma única nota com parcelas destacadas pode gerar envios à EFD-Reinf em meses distintos, porque cada parcela segue a sua própria data. Por isso, no controle interno, exijo que o IRRF fique discriminado em linha própria no documento e no lançamento. Sem essa separação, a conciliação mistura valores de meses distintos e a auditoria não consegue reconstruir o caminho.

Quer a data? Para o IRRF vale o crédito ao beneficiário ou a saída do dinheiro, a que acontecer antes. O mês da nota não manda nele. E aí, lá onde trabalho, o que o sistema faz vai depender do evento cadastrado, então confiro no log do lançamento se o IRRF subiu pela data certa antes de transmitir. A contribuição é outro caso, porque segue a data da nota.