PC Toledo

Não se preocupem, não é mudança, só estou mostrando motivos de confusão que aconteceram.
A Sefaz é culpada de muita confusão.

Pela primeira vez comecei a olhar a nota técnica devagar.
Isto está logo no início, numa das alterações que aconteceram.

Alterada a denominação do termo descrito na versão anterior de “ICMS de Partilha” para “ICMS
em Operações Interestaduais”

Essa alteração significa simplesmente que inverteram os nomes.
Cada um acostumou a chamar a mesma coisa com um nome diferente.

Quando um dizia ICMS de partilha, outro estava pensando no ICMS Interestadual, e vice-versa.
O resultado deste erro da Sefaz seria partilhar o valor errado.

Outro erro da Sefaz, que foi corrigido depois

Apresenta a sistemática de cálculo aplicada nas operações e prestações que destinem bens e
serviços a consumidor final, conforme definido na 162ª reunião ordinária da Comissão Técnica
Permanente do ICMS – COTEPE, com fundamento na cláusula 2ª do Convênio ICMS 93/2015

Ela mostrou os exemplos de cálculo ERRADOS, diferentes da lei. o erro saiu na v.1.40, e corrigido na 1.50

Outro erro da Sefaz corrigido

Alterada a observação do campo NA15 para que o valor do ICMS relativo ao Fundo de Combate
à Pobreza (FCP) não seja somado ao valor do ICMS Interestadual para a UF de destino;

Colocou que era pra somar impostos que não deveria somar.
Foi corrigido na versão 1.60

E mais outro

Foi alterado o prazo limite para implantação em produção das seguintes regras de validação:
E16a-30, N12-70, N12a-70, N16-04, N16-20, NA01-20, NA09-10, NA09-20 e NA09-30, e, a
critério da UF, a regra N12-80.

A Sefaz tinha implementado regras que pela lei ainda não são obrigatórias.

Como deu pra perceber, a própria Sefaz é que causou muita confusão.
E ainda estou na parte de alterações entre as NTs.... rs
Nem começou o manual propriamente dito.

Então com essa prorrogação se estivermos calculando errado mas a soma dos totais baterem vai passar correto?

Caso a resposta anterior for SIM isto pode gerar problemas para os emitentes q no prazo janeiro a junho emitirem errado?

Cara q louco... se for isso é mais pano pra manga... tipo poderiam o webservice corrigir os cálculos e evitar problemas...

Tá certa esta mudança??????????

Valor Total Bruto dos Produtos ou Serviços

O valor do ICMS faz parte do Valor Total Bruto

NT 1.60 página 8

Deixei passar sua mensagem.
Realmente é complicado, principalmente por causa desta parte: "desde que o imposto seja recolhido".
Se aceitar errado e recolher errado.... fu...

Até que não deu o trabalho que eu pensava pra totalizar no XML.
Segui o manual, mas não testei ainda.
Lembrando que só deixei o cálculo/totalização da partilha pra fase do XML. O resto é calculado no pedido, naquelas linhas que já postei aqui.
Ainda gero TXT e XML ao mesmo tempo - pode ser uma referência pra quem gera só txt

Código: Selecionar todos

   LOCAL nTotIcmFcp := 0, nTotIcmRem := 0, nTotIcmDes := 0
...
      NfeBlocoProduto( @cTxt, @cXml, nNumItem, nTotIcmFcp, nTotIcmRem, nTotIcmDes )
...
   NfeBlocoTotais( @cTxt, @cXml, nTotIcmFcp, nTotIcmRem, nTotIcmDes )
...
   NfeBlocoProdutoIcms( @cTxt, @cXml, nTotIcmFcp, nTotIcmRem, nTotIcmDes )
...   
   NfeBlocoProdutoIcmPartilha( @cTxt, @cXml, nTotIcmFcp, nTotIcmRem, nTotIcmDes )
   cXml += [</ICMS>]
...
STATIC FUNCTION NfeBlocoProdutoIcmPartilha( cTxt, cXml, nTotIcmFcp, nTotIcmRem, nTotIcmDes )

   LOCAL nIcmRem, nIcmDes

   IF jpitped->ipIcdAli == 0 .AND. jpitped->ipFcpAli == 0
      RETURN NIL
   ENDIF
   nIcmRem    := Int( jpitped->ipIcdVal * PartilhaAli( "R" ) ) / 100
   nIcmDes    := Int( jpitped->ipIcdVal * PartilhaAli( "D" ) ) / 100
   nTotIcmRem += nIcmRem
   nTotIcmDes += nIcmDes
   nTotIcmFcp += jpitped->ipIcmFcp

   cTxt += "NA" + SPED_SEPARADOR
   cTxt += NumberXml( jpitped->ipIcmBas, 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( jpitped->ipFcpAli, 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( jpitped->ipIcdVal, 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( jpitped->ipIcmAli, 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( PartilhaAli( "D" ), 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( jpitped->ipFcpVal, 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( Int( jpitped->ipIcdVal * PartilhaAli( "D" ) ) / 100, 2 ) + SPED_SEPARADOR
   cTxt += NumberXml( Int( jpitped->ipIcdVal * PartilhaAli( "R" ) ) / 100, 2 ) + SPED_SEPARADOR

   cXml += "<ICMSUFDest>"
   cXml += XmlTag( "vBCUFDest", NumberXml( jpitped->ipIcmBas, 2 ) )
   cXml += XmlTag( "pFCPUFDest", NumberXml( jpitped->ipFcpAli, 2 ) )
   cXml += XmlTag( "pICMSUFDest", NumberXml( jpitped->ipIcdVal, 2 ) )
   cXml += XmlTag( "pICMSInter", NumberXml( jpitped->ipIcmAli, 2 ) )
   cXml += XmlTag( "pICMSInterPart", NumberXml( PartilhaAli( "D" ), 2 ) )
   cXml += XmlTag( "vFCPUFDest", NumberXml( jpitped->ipFcpVal, 2 ) )
   cXml += XmlTag( "vICMSUFDest", NumberXml( nIcmDes, 2 ) )
   cXml += XmlTag( "vICMSUFRemet", NumberXml( nIcmRem, 2 ) )
   cXml += "</ICMSUFDest>"

   RETURN NIL
...
   IF .F.
      cTxt += NumberXml( nTotIcmFcp, 2 ) + SPED_SEPARADOR
      cTxt += NumberXml( nTotIcmDes, 2 ) + SPED_SEPARADOR
      cTxt += NumberXml( nTotIcmRem, 2 ) + SPED_SEPARADOR
   ENDIF
...
   IF .F.
      cXml += XmlTag( "vFCPUFDest", NumberXml( nTotIcmFcp, 2 ) )
      cXml += XmlTag( "vICMSUFDest", NumberXml( nTotIcmDes, 2 ) )
      cXml += XmlTag( "vICMSUFRemet", NumberXml( nTotIcmRem, 2 ) )
   ENDIF
   cXml += XmlTag( "vBCST", NumberXml( jppedi->pdSubBas, 2 ) )
...

STATIC FUNCTION PartilhaAli( cRemetenteDestinatario )
   IF cRemetenteDestinatario == "D"
      DO CASE
      CASE Year( Date() ) == 2016 ; RETURN 40
      CASE Year( Date() ) == 2017 ; RETURN 60
      CASE Year( Date() ) == 2018 ; RETURN 80
      CASE Year( Date() ) >= 2019 ; RETURN 100
      ENDCASE
   ELSE
      DO CASE
      CASE Year( Date() ) == 2016 ; RETURN 60
      CASE Year( Date() ) == 2017 ; RETURN 40
      CASE Year( Date() ) == 2018 ; RETURN 20
      CASE Year( Date() ) >= 2019 ; RETURN 0 // nem precisa
      ENDCASE
   ENDIF
   RETURN 0

As funções são autoexplicativas.

Nota: após postar percebi que faltaram algumas arrobas ( @ ), aliás... todas elas.

Aproveitando:
a vantagem de compilar usando -w3 -es2, e a necessidade adicional se percebe nesse fonte.
Passei as variáveis por referência, e cada rotina pode ser alterada de forma independente.
Ao compilar com -w3 -es2 já garanti que as variáveis existem, foram declaradas, e 99% de chance de não dar erro depois.
Ao NÃO USAR private, tudo garantido.

Apesar de rotina que chama rotina, que chama rotina, que chama rotina... é iniciar variáveis com zero, somar, e mostrar conteúdo. Cada coisa no seu bloco.

Amiguinhos,

O tratamento da operação com DIFAL e a inclusão das tags, cálculos e criticas só deverá ocorrer quando a Natureza de Operação for >= 6000) e <= 6999.

Ou seja poderemos até fazer os cálculos mas as tags só farão parte do XML da NF-e quando ocorrer o fato acima.

Outro adicional é que deveremos apresentar de forma explicita na nota tais informações, para cada na nota que tiver estes cálculos. Portanto deveremos acionar a tag infAdProd e detalhar tudo.

Como eu disse meus cálculos são no pedido, então coloquei na geração de XML esta parte, pra só gerar se tiver valores.

Código: Selecionar todos

IF jpitped->ipIcdAli == 0 .AND. jpitped->ipFcpAli == 0
      RETURN NIL
   ENDIF

Mas está errado. Pode ter produto que é obrigado a informar mesmo sendo zero.
Mas o lembrete do Rochinha acabou dando uma idéia.

Código: Selecionar todos

IF Left( jpitped->ipCfOp, 1 ) != "6" // se não for interestadual, não sai
      RETURN NIL
ENDIF
IF .NOT. jpitped->ipCst $ "??????" // talvez precise limitar só pra alguns CSTs
   RETURN NIL
ENDIF

Vou ter que repassar o manual/lei pra ver essa parte de informações adicionais.

IMPORTANTE:
E se for base de ICMS com redução?
Não lembro se a base de cálculo indicada na nota é com ou sem redução, e pode afetar os cálculos.
Vou revisar essa parte (as linhas de cálculo)

Nota: todos esqueceram disto nos textos

Mostrar as informações das TAGs no infadprod? Se mostrarmos somente nos dados adicionais da nota totalizado não resolve? (Estou fazendo assim)

Em informações adicionais de cada produto já fica vinculado ao produto, pode ser mais interessante.
Pra colocar em informações adicionais gerais, vai ter que informar qual é o produto, a não ser que bastem os totais da nota.

MAIS UMA DÚVIDA:

No caso de consumidor ou não contribuinte, faz os cálculos OK.

Mas só vai recolher adiantado se for não contribuinte, caso contrário é o próprio destinatário que recolhe.

Como fica isso na nota?
É o mesmo valor para os dois, e a nota vai ficar igual?
Como o faturista vai identificar a nota pra recolhimento antecipado ou não, se são iguais?

Vai ter que destacar lá?: o destinatário é responsável pelo recolhimento conforme lei...
Nessa daí os não contribuintes vão levar vantagem, porque é difícil identificá-los.

Isso não alteraria o valor da nota?
Raciocinando: se contribibuinte, ele que recolhe, então porque cobrar dele o valor do ipposto?
Ou porque não cobrar em separado do não contribuinte/consumidor, como sempre foi feito com ST?

Tá confuso aonde vai aparecer esse imposto, tem horas que dá a impressão que ele não vai existir, mesmo sendo pago.

AGORA UMA SUPER DÚVIDA

Quem disse que essa merd. é pra fazer assim?

Se a venda é com substituição tributária, então é CFOP de venda com substituição tributária

Tratando como substituição tributária, todos os cálculos ficam certos, inclusive a cobrança do valor na nota.

Não é obrigatório o percentual de IVA, então a base de cálculo pra SUBSTITUIÇÃO TRIBUTÁRIA será a normal.

O imposto será somado na nota, e tudo fica resolvido, todos os cálculos batidos.

E para isso dar certo, a alíquota de ST seria com FCP, e depois seria extraído o valor de FCP dessa substituição.

Nada mais justo que isso, está tudo dentro da lei.

- O cálculo da substituição, conforme manda a lei
- O cálculo da ST com FCP incluso, conforme manda a lei (é um percentual ADICIONAL de ICMS)
- Os valores separados, conforme manda a lei - separar FCP, o imposto ST a ser rateado
- A cobrança do imposto adicional na nota, conforme faz-se necessário para o emitente ser reembolsado pelo imposto que pagou atribuído ao destinatário.
- A indicácão de CFOP com substituição tributária, porque é isso mesmo

Tá todo mundo preocupado com o cálculo, mas esquece de pensar.

A parte básica é essa: Tem pagamento de ST, então não é venda comum, É VENDA COM COBRANÇA DE ST.
Isso não é nada novo, apenas o rateio é novo.

Aqueles FDPs estavam interessados no dinheiro, e esqueceram da lei.
Ou simplesmente não faz parte do manual mostrar isso.

Depois de tanta coisa, voltamos ao básico - simples e prático.

Aí vém alguém dizer... mas o manual.....
Qual deles? o 1.00, 1.10, 1.20, 1.30, 1.40, 1.50, 1.60 ou os próximos

Mais considerações nesse mesmo raciocínio:
Basta ratear sempre que houver ST. Se for dentro da mesma UF, não há o que ratear.

Agora tentem achar uma situação onde isso não se encaixe.

Por acaso é errado indicar venda com cobrança de substituição tributária, numa venda aonde passaram a cobrar substituição tributária?

Deixou de ser isso só porque paga adiantado, ou porque vão "rachar" o valor?

Pra finalizar: o manual só diz como calcular e informar o rateio. O restante, que eu coloquei aqui, talvez seja autmático e por isso não informaram.
Só resta saber se o emissor vai aceitar ST pra venda a consumidor/não contribuinte, é o único ponto pendente, a única alteração que precisa pra tudo ficar dentro da lei que já existe.

Quem tiver facilidade de fazer um teste...

Como vocês estão fazendo para o simples?
É interessante, mas isso o manual não diz.

Sobre o XML da GNRE ....

esse xml vai ser separado do xml da nfe ?
ou é parte do xml da nfe ?

Se for separado terei que sumetê-lo ao webservice e pegar resposta ? o acbrplus vai fazer isso ?
ou só iremos preencher um GNRE para pagar ??

...........
:%

PC Toledo

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha

Mudanças da partilha