ICMSUFDest - Rejeição 694

[Jairo Maia]

Olá Pessoal,

acredito que ai é que estamos nos confundindo

Podemos ter confundido mesmo!

Ontem passei boa parte do tempo bolando como iria colocar esses controles no sistema, e relendo o manual de leiaute e pesquisando dicas de vários contabilistas na internet. Parece que estamos no caminho certo, ou todos nós estamos errados. O que não me parece...

Quanto a questão de Isento e Não Contribuinte, parece que já está funcionando, e nessa questão não há dúvida, e é em função da legislação do estado destino que vale, não a origem. A questão agora é fazer a validação nos campos de ICMS nas operações interestaduais. É nesse ponto que segundo o HASA está empacando.

o manual fala de mandar de uma forma para algumas uf´s e de outra para as demais

Esse diferencial se refere a alíquota interestadual a ser usada de acordo com o estado origem-destino, e pode ser de 4, 7 ou 12%.

1 - Deve-se usar 4% na alíquota interestadual para produtos importados. Aqui já decidi que se houver a situação em que para um mesmo destinatário houver produtos importados e nacionais numa mesma entrega (e no meu caso haverá), emitir-se-a uma nota para os produtos importados e outra para os nacionais. Isso não tem nenhum impedimento, e resolve o problema.

2 - Deve-se usar 7% na alíquota interestadual quando o estado de origem estiver na região Sul ou Sudeste (exceto ES), e o estado de destino estiver nas regiões Norte, Nordeste, Centro-Oeste ou Espírito Santo.

3 - Deve-se usar 12% na alíquota interestadual nos demais casos.

Exemplo 1: Uma nota com origem em SP para destino RJ ou MG ou RS: usa-se 12%, pois o estado origem está no Sudeste, e o estado destino não está no Norte, Nordeste, Centro-Oeste ou Espírito Santo.

Exemplo 2: Uma nota com origem em SP para Bahia ou Tocantins: usa-se 7%, pois o estado origem está no Sudeste e o estado destino respectivamente no Nordeste (Bahia) e Norte (Tocantins).

Exemplo 3: Uma nota de Tocantins para SP ou SP para Tocantins ou Acre somente com produtos importados, usa-se 4%, ou seja, em se tratando de produtos importados, não importa a origem ou destino, é 4%.

Quanto ao preenchimento das tags interestaduais, que é a rejeição que está dando (dizendo que o grupo não foi definido), o manual parece bem claro. Quando há erro no preenchimento de alguma delas, cada caso tem uma rejeição específica, não a de que o grupo não foi definido como está ocorrendo: 694/Rejeição Não informado o grupo de ICMS para a UF de destino.

[JoséQuintas]

Aqui por exemplo, parece que o bloqueio é por parte da UF autorizadora, e não da UF destinatária.

[JoséQuintas]

Além da parte do descritivo, tem que olhar a parte das regras de validação.
Há muitas exceções descritas lá.

[JoséQuintas]

Agora que vi, deixei passar esta parte:

São muitos, aí apenas um pedacinho.

[lugab]

Valeu, Rubens, seu link ajudou bastante

[HASA]

:))
Srs. no meu caso sucesso, e acredito que para os colegas do hbnfe minha solução poderá resolver, os clientes que deram esses erros estavam com o monitor muito antigo, ou seja, seus shemas estavam desatualizados, atualizei e os problemas sumiram sozinhos, ou seja, continuo enviando as notas como antes mas... com shemas novos, se errei escrever esse nome horrível me Perdoem, shemas...
:)Pos
HASA

[JoséQuintas]

seus shemas estavam desatualizados

Por isso achei melhor na classe não validar o XML, assim não prende a atualização de schemmas.

Sobre o simples nacional: tem gente passando a partilha com valores zerados e outros com valores preenchidos por causa do emissor.
Mesmo com valores zerados, os percentuais precisam ser informados, só percentuais, com base zero e valores zero.
Em ambos os casos, com a mensagem sobre o que originou a "não tributação".

Naquele meu esquema de regras de tributação, acrescentei a opção de informar mesmo quando zerado, que antes não tinha.
Mas deixo todo preenchimento por conta do usuário/contador.

Foi até curioso:
O usuário não queria apagar as regras pra não ter trabalho.
Mas a cada pedido, iria reaproveitar regras, o que é perigoso e dá até mais trabalho.
Apaguei todas, e o usuário ficou feliz em ver que assim ficou melhor pra ele.... rs
Basta ir cadastrando as novas regras, conforme forem aparecendo, e agora não corre o risco de usar regra errada.

[rubens]

Bom dia ....

Quanto mais reza mais assombração aparece...

Passei os ultimas 4 dias estudando e pesquisando e cheguei a essa conclusão:
Venda para consumidor com inscrição e sem ST: CFOP 5102 e CSOSN: 900 (Há algum tempo contador instruiu a não usar 102)
Venda para consumidor com inscrição e com ST: CFOP 5102 e CSOSN: 500

Com nova regra:
Venda para consumidor com inscrição e sem ST: CFOP 5102 e CSOSN: 900 (Há algum tempo contador instruiu a não usar 102)
Venda para consumidor com inscrição e com ST: CFOP 5102 e CSOSN: 500

Venda para consumidor sem inscrição e sem ST: CFOP 5102 e CSOSN: 102
Venda para consumidor sem inscrição e com ST: CFOP 5102 e CSOSN: 500

Beleza... em todos os testes foram autorizados certinho...
Daí questionei o contador se ia passar a utilizar o 102 padrão e o 900 ficaria só para alguma nota que permitisse crédito de Icms como o Kiko falou numa postagem anterior..
Olha a pergunta:

Bom dia Leandro...
Com as novas regras de 01-07 não posso mais enviar nota para Não contribuinte com o 900 daí tive que passar a usar o 102. Como é que fica posso usar 102 para todas as vendas e deixar o 900 só quando for uma devolução que tem permissão de crédito ?

Olha a resposta:

Bom dia Rubens, eu liguei na Sefaz e FTE Tania me orientou a usar o CSOSN 500 e o CFOP 5108.

De onde saiu esse 5108 ???
Não vi referência nenhuma dele nas NT ....
é pa caba o piqui do Goiás... um trem desse...

Fui pesquisar e existe mesmo uma porcaria dum CFOP 5108... e agora???

Rubens

[JoséQuintas]

É por isso que gosto das minhas regras, são simples mas me tiraram esse problema.

1. Transação, tem um código, por exemplo, 1 - vendas
2. Cadastro, tem um código, por exemplo, 1 - PJ contribuinte, 2 - PJ não contribuinte, 3 - Pessoa Física
3. Produtos, tem um código, por exemplo, 1 - produto de alumínio
4. UF, tem um código, por exemplo, 1 - interno, 2-nordeste ou 2-Bahia

No pedido o aplicativo procura a regra com essa combinação: "000001" + "000002" + "000001" + "000002"
Se não existir, aparece pro usuário:
"Falta regra pra vendas, pra não contribuinte, de produto alumínio, para a UF Bahia"

Então o usuário liga para o contador e pergunta:
"Como eu preencho uma venda, pra não contribuinte, de produto alumínio, para a UF Bahia?"

O usuário vai em regras e cadastra:
vendas (1)
pra não contribuinte (2)
de produto alumínio (1)
pra bahia (2)
E coloca tudo que o contador falar.

Até já aviso:
"posso orientar, mas a palavra final é do contador, porque cada empresa é de um jeito, cada produto é de um jeito, às vezes nem um contador sabe daquilo porque não acontece com os clientes que costuma atender, então não posso afirmar que isso é o correto, apenas me baseio em outro cliente, que pode ser diferente da sua empresa. Consulte o contador que é melhor"

Se quiserem até colocar o NCM como sendo o código, ou CFOP como sendo a transação, tudo bem, é só cadastrar.
Eu apenas procuro fazer essa classificação de como agrupar o que é semelhante, e na "linguagem" deles, de um jeito que reduza a quantidade de regras.
A partir daí, é com eles.

Se num caso extremo fizer por produto, também poderia ser assim, porque o usuário e o contador poderão falar na mesma língua.

Pelo menos o aplicativo está "na linguagem deles", então eles não podem falar que é complicado preencher.

Pode entrar lei, sair lei, que basta colocar lá na regra como fazer.

Outro exemplo:
Se inventarem que quando destinatário for empresa do simples vai ser tudo diferente? o que eu faço?
Vou lá na tributação de cadastros, e crio um código pra empresas do simples, só isso.
O usuário ao criar um cadastro vai dizer se o cadastro é empresa simples.
E quando for: venda, pra cadastro do simples, produto alumínio, pra Bahia.... tudo se repete, liga pro contador, e preenche a regra.

Na geração do XML, eu apenas preencho conforme o que foi definido.
A regra já vai ter informado o CFOP, CST ou CSON, e tudo mais.
Nem preciso mexer na geração do XML.

Ah sim.... fica tudo gravado já no pedido.
É muito campo no pedido, mas mostrar o pedido já calculado, exatamente como sai na nota é ótimo.
O usuário pode corrigir ainda na digitação.
Emitir a nota e gerar o XML, não tem cálculo nenhum, é só usar do jeito que já está gravado.

Cada vez me convenço mais que acertei ao criar desse jeito.
Não preciso mexer no aplicaitvo, só precisa que o contador passe as informações corretas.
Se a Sefaz não aceitar, o usuário liga pro contador, e diz que passou errado e o que aconteceu.
Aí eles vão lá na regra: venda, pra cadastro não contribuinte, produto alumínio, pra bahia, e corrigem.

Nem tem porque ligar e dizer que o aplicativo fez errado.... rs

Pra ficar melhor ainda, só implementando as mesmas validações da Sefaz na confirmação do pedido.
Qualquer dia faço isso.

Desse jeito, a briga fica entre o usuário e o contador !!!! Não preciso me meter na briga !!!!

[Kiko Fernandes]

Olha a resposta:

Bom dia Rubens, eu liguei na Sefaz e FTE Tania me orientou a usar o CSOSN 500 e o CFOP 5108.

De onde saiu esse 5108 ???
Não vi referência nenhuma dele nas NT ....
é pa caba o piqui do Goiás... um trem desse...

Fui pesquisar e existe mesmo uma porcaria dum CFOP 5108... e agora???
Rubens

Boa Noite!

Rubens vai com calma que deve ter algo errado ai.
Se vc procurar o arquivo SPEDFISCAL_GLOBAL$CFOP$5$2 (Tabela dos CFOP's válidos) que pertence ao Validador SPED, que no meu caso fica em:
C:\Program Files (x86)\Programas_SPED\Fiscal2\recursos\TabelasExternas
Você notará que não existe CFOP 5108. (6108 existe)
Caso tenha o SPED tente informar pelo próprio validador CFOP 5108 e verá que não será possível.

Anexei duas telas para facilitar a explicação, caso não tenha o validador sped instalado.
Em um verá que não existe 5108 e em outro verá que 6108 existe.

Então acredito que se a informação veio do SEFAZ eles devem estar confundindo alguma coisa.

[JoséQuintas]

Então a confusão é feia...
Pesquisando no google:

4. Serão considerados para efeito de cálculo os códigos de operação abaixo (padrão do sistema, podendo ser configurado através dos parâmetros MV_DSVIC e MV_DSVEC):

Considerar para cálculo dos débitos fiscais não vinculados ao projeto aprovado (DNVP) as seguintes operações :

1) Venda de mercadoria adquirida ou recebida de terceiros - 5.102 e 6.102;

2) Venda de mercadoria adquirida ou recebida de terceiros, efetuada fora do estabelecimento - 5.104 e 6.104;

3) Venda de mercadoria adquirida ou recebida de terceiros, que não deva por ele transitar - 5.106 e 6.106;

4) Venda de mercadoria adquirida ou recebida de terceiros para comercialização, destinada a não contribuinte - 5.108 e 6.108;

5) Venda de mercadoria adquirida ou recebida de terceiros, destinada à Zona Franca de Manaus ou Áreas de Livre Comércio - 5.110 e 6.110;

6) Venda de mercadoria adquirida ou recebida de terceiros remetida anteriormente em consignação industrial - 5.112 e 6.112;

7) Venda de mercadoria adquirida ou recebida de terceiros remetida anteriormente em consignação mercantil - 5.114 e 6.114;

8) Venda de mercadoria adquirida ou recebida de terceiros, recebida anteriormente em consignação mercantil - 5.115 e 6.115;

9) Venda de mercadoria adquirida ou recebida de terceiros, originada de encomenda para entrega futura - 5.117 e 6.117;

10) Venda de mercadoria adquirida ou recebida de terceiros entregue ao destinatário por conta e ordem do adquirente originário, em venda à ordem - 5.119 e 6.119;
...

https://www.totvs.com/mktfiles/tdiportais/helponlineprotheus/portuguese/fisr0400_gerando_parcela_incentivo.htm

[JoséQuintas]

Caso seu cliente não tenha IE deve utilizar a CFOP 5108 ( Venda a não contribuinte ) . Caso o mesmo possua IE,seguir a orientação do colega Thiago.

http://www.contabeis.com.br/forum/topicos/86595/cfop-consumidor-final/

[Kiko Fernandes]

Caso seu cliente não tenha IE deve utilizar a CFOP 5108 ( Venda a não contribuinte ) . Caso o mesmo possua IE,seguir a orientação do colega Thiago.

http://www.contabeis.com.br/forum/topicos/86595/cfop-consumidor-final/

José a informação do TOTVs eu não consegui descobrir a data de postagem. (Porém sempre procuro algo oficial. Esta informação é de um desenvolvedor e com isto existe a possibilidade de erro, igual a gente comete)

Quanto ao post que está citado acima a data é de [19 de novembro de 2012.]

[rubens]

Bom dia...

Kiko realmente existe esse 5108 e tô usando ele e tá validando as notas... Vamos ver na hora de gerar o SPED... Vou argumentar isso com o Contador hoje...

Minhas validações ficaram na gambiarreichon assim:

         IF PERS->CRT = '1'  // SIMPLES
            IF cINDIEDEST == '1' 
                      cCSOSN := IF( (cCFOP="5405" .OR. cCFOP="6404"),"500","900")
             ELSE
                    cCSOSN := IF( (cCFOP="5405" .OR. cCFOP="6404"),"500","102")
      ENDIF   
         ELSE
            IF cINDIEDEST == '1' 
                       cCSOSN := IF( (cCFOP="5405" .OR. cCFOP="6404"),"60","90" )
             ELSE
                cCSOSN := IF( (cCFOP="5405" .OR. cCFOP="6404"),"60","00" )
           ENDIF
         ENDIF

         ***********************************************************************
         // Escolhe CFOP
         // CFOP 5108 conforme o Leandro passou 
         If cINDIEDEST = '9'
            cCfop := Left( INF->CFOP,1 ) + '108'
        EndIf

         // CEST - por enquanto vou lancar por aqui... 
         If PRO->CSOSN_ $ '\60 \900\500\'
            @ PRow()+1,00 Say 'CEST='+ TiraPonto( PRO->CEST )
         EndIf  

         @ PROW()+1,00 SAY IF( cCRT='3','CST=','CSOSN=')+cCSOSN

        //
        @ PROW()+1,00 SAY'[ICMSUFDest'+STRZERO(Y,3)+']'
   @ PROW()+1,00 SAY'vBCUFDest=0'
   @ PROW()+1,00 SAY'pFCPUFDest=0'
   @ PROW()+1,00 SAY'pICMSInter=12.00'
   @ PROW()+1,00 SAY'pICMSInterPart=40.00'
   @ PROW()+1,00 SAY'vFCPUFDest=0'
   @ PROW()+1,00 SAY'vICMSUFDest=0'
   @ PROW()+1,00 SAY'vICMSUFRemet=0'      

E tá validando...
Por enquanto vai ficar assim até surgir novidades...

Obrigado

Rubens

[Jairo Maia]

Olá Pessoal,

Só acrescentando mais uma coisa:

Rubens vai com calma que deve ter algo errado ai.

Ontem tive a oportunidade de estar num cliente e encontrar a responsável pelo departamento de notas fiscais do escritório contábil desse cliente. Como já nos conhecemos, em determinado momento citei essa informação do Rubens, e disse que esse colega havia recebido essa informação da contabilidade após consulta no posto fiscal de MT.

Como ela ficou curiosa, fizemos algumas pesquisas na internet, mas esse CFOP não aparece em nenhuma tabela oficial. Enfim, também recebi a orientação como foi colocada pelo Kiko: Não mude nada até que tenhamos essa confirmação. Ficou combinado que o primeiro a ter a informação oficial fará contato.