Cantu

Que absurdo! Não incluíram um exemplo de calculo na versao 1.50... é inacreditável! Será possível que nem eles sabem direito como calcular, por isso não querem dar exemplo?!

Mas nesse caso, as empresas no simples vão "se ferrar", não? Obrigado pelos comentários.

Esse governo está sendo tudo, menos justo. Em qualquer país de primeiro mundo, já teria ocorrido uma revolução, a começar pelos contadores, que são diretamente afetados pelas loucuras que o governo cria, mas que aceitam tudo de cabeça baixa, como se o "deles" não estivesse na reta também. Eu tenho a impressão que a intenção aqui é deixar o mais nebuloso possível, pra depois ganhar com multas.

Rodrigo, segundo me informaram, será publicada a versao 1.50 da NT ainda essa semana (será mesmo, já é quinta-feira). Eu ainda tenho algumas duvidas: 1) Como fica o preenchimento do campo (que já existia no XML) referente a alíquota do ICMS (tag pICMS)? Antes, em uma operação interestadual para não contribuinte, esse campo era preenchido com a alíquota interna do estado de origem. Agora entendo que deve ser colocado ali a alíquota interestadual (ou 4% se produto importado, etc). Mas se for assim, o conteúdo desse campo vai acabar ficando igual ao do novo campo pICMSInter, aí me pergunto porque criariam outro campo se o conteúdo dele seria igual ao de um que já existia? 2) O novo campo vBCUFDest será sempre sempre igual ao vBC? 3) Como preenche os novos campos, no caso de empresa no Simples? []s Cantu

Parece que normalizou na Sefaz SP... pelo menos foi o que um cliente me passou.

https://www.confaz.fazenda.gov.br/legislacao/convenios/convenio-icms/2015/convenio-icms-139-15

A obrigatoriedade do CEST foi prorrogada para 1/Abril/2016: https://www.confaz.fazenda.gov.br/legislacao/convenios/convenio-icms/2015/convenio-icms-139-15

No meu caso, a data de saída está preenchida com a mesma data da emissão.

Só pra constar... notas de venda estão sendo autorizadas, mas as de consignação continuam sendo rejeitadas com o mesmo erro.

Talvez vc tenha que enquadrar no CEST 2804300, que está associado ao capítulo 85 do NCM, apesar da descrição dele não ter nada a ver com "pilha". Mas eu acredito que essa tabela que eles liberaram ainda vai sofrer alteração... aí pode ser que incluam NCMs que ficaram de fora.

Aí já é outro problema que não depende de mim (esse assunto dá pano pra manga) Na verdade o destinatário não é pessoa física, e sim um hospital. Hospitais geralmente não são contribuintes do icms. PS: A data da nota está correta. Eu imagino que a Sefaz atualizou o webservice com a regra de validação errada (não está verificando a data de emissão).

Sergio, eu já verifiquei o XML gerado, e o indIEDest está 9. O problema deve ser outro. No meu caso, é uma remessa de consignação, não é venda.

Eu imaginei que fazendo isso a nota fosse mesmo autorizada, o problema é saber se isso é realmente o correto a ser feito, pois se não for, depois pode dar problema por ter usado a alíquota "errada".

No meu já estava 9

Sim, o erro é em ambiente de produção, e começou a ocorrer hoje. Sugiro que todos enviem um email pelo Fale Conosco da Sefaz, pra forçar eles a se posicionarem sobre o assunto, ou caso seja falha lá, que corrijam rapidamente.

Pessoal, Tem cliente meu que não está conseguindo autorizar NFe hoje na Sefaz SP, quando a operação é interestadual, com produto importado, e destinatário não contribuinte do ICMS. Conforme regra vigente, nesse caso a aliquota do icms usada é a interna (18%). No entanto, a sefaz está rejeitando com um erro de que a aliquota está maior que 4%. Coincidentemente, a meia-noite de hoje, a sefaz atualizou os webservices de acordo com a NT 2015.003, no entanto, entendo que a nova regra da aliquota passaria a valer só a partir de 01/jan/2016, e não a partir de hoje. Alguém sabe de algo a respeito? []s

Nem todo produto/ncm tem CEST, portanto, quando não houver CEST definido, não há nada pra ser informado (por isso a tag não é obrigatória). No entanto, quando houver CEST definido, seguindo o que diz o Convenio 92, entendo que ele deverá ser informado, independente da operação ter subst. ou não (ou seja, independente da STICMS/CSOSN).

Em que vc se baseou pra chegar nessa metodologia? []s

Não estaria indo contra o que diz no Convenio? []s

Estive dando uma olhada no Convenio 92, que implementa o CEST, e lá diz: § 1º Nas operações com mercadorias ou bens listados nos Anexos I a XXVIII deste convênio, o contribuinte deverá mencionar o respectivo CEST no documento fiscal que acobertar a operação, independentemente de a operação, mercadoria ou bem estarem sujeitos aos regimes de substituição tributária ou de antecipação do recolhimento do imposto. Dando a entender que deve-se informar o CEST em qualquer tipo de operação, e não somente as que envolvem Substituição Tributária. Mas olhando a NT 2015.003, existe uma regra (a ser implementada futuramente) que exige o cest apenas se a ST do ICMS for 10, 30, 60, 70 ou 90. Como vocês estão fazendo? Estão informando ele em todas as operações de saída, ou só para as STs que indicam substituição tributária?

Pra quem interessar, publiquei um script sql para inserção dos códigos CEST em base de dados Firebird (ou possivelmente outras) em um artigo público na FireBase: http://www.firebase.com.br/artigo.php?id=2862 Espero que seja útil. []s Cantu

Como tudo nesse país é nebuloso, eu entendo a NT da seguinte forma: A regra que exige a informação do CEST não estará ativa em 1/Janeiro/2016, portanto, se você não informar o CEST, não vai rejeitar a NFe. No entanto, não houve alteração sobre a obrigatoriedade de informar, portanto, entendo que apesar da NFe ser autorizada, a empresa que não informar estará passível de multa, etc. em uma possível fiscalização.

Daniel, minha sugestão é que apenas o XML esteja em UTF8... as demais propriedades podem ficar com a string nativa mesmo. Quem for exibir o XML no Delphi usará provavelmente um TMemo ou um TWebBrowser. O WebBroser vai mostrar perfeitamente (visto que o xml já tem a tag utf8), já o TMemo precisaria converter: Memo1.Lines.text:=UTF8ToUnicodeString(aUTF8String); Talvez ainda valha a pena armazenar o XML exatamente como foi devolvido pelo webservice do governo, em uma propriedade separada. []s Cantu

Luciano, Se você está gerando o arquivo a partir do conteúdo da propriedade XML do componente, terá que codificar ele em UTF8 antes de gravar, pois o ACBr não faz isso, tipo: ACBrStrToUTF8(NFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML) Na minha visão, já que todo XML retornado pelo governo usa UTF8, o correto seria o componente já retornar esse conteúdo formatado em UTF8. Indo mais além, acho que o XML retornado deveria ser exatamente aquele devolvido pelo governo, e não um que foi "montado/tratado" pelo componente.

Isso! Já testei de ambas as formas, o erro retornado é o mesmo... a chamada que usei foi: NFe.DistribuicaoDFe(NFe.Configuracoes.WebServices.UFCodigo, NFe.SSL.CertCNPJ, UltNSU, ''); e NFe.DistribuicaoDFe(NFe.Configuracoes.WebServices.UFCodigo, NFe.SSL.CertCNPJ, 0, ''); Não, pois não queria "zonear" a base de dados do cliente Mas quando eu implementei, há uns 2 meses atrás, funcionava normalmente no ambiente de homologação. []s Cantu