Fabrício G. Araújo

Só um esclarecimento... a Capicom está funcionando normal em GO na versão 4.00 (tanto homologação quanto produção), foi só manezada minha mesmo que esqueci que a Capicom tem as dependências das configurações das Opções da Internet. Agora terei que decidir se utilizarei a Capicom ou a WinCrypt na versão 4.00. WinCrypt: Como já falei em outras postagens, com a WinCrypt pode funcionar de primeira em alguns clientes, mas em outros que estão com Windows desatualizados tem que atualizar até o fim para funcionar, não basta ter, por exemplo, um Win7 com SP1, tem que ter todas as atualizações após o SP1 para funcionar. Em um cliente demorou dois dias para conseguir preparar um computador e ver funcionando com WinCrypt. A grande vantagem é que após a atualização tudo funciona, sem ter que configurar nada. Capicom: Já com a Capicom percebi que, por exemplo, um Win7 com SP1 já funciona, sem as últimas atualizações. Mas aí tem todo o transtorno de instalar Capicom, registrar dlls e alterar as configurações das Opções da Internet. Enfim, agora teremos que tomar a decisão aqui na empresa que caminho seguir para a versão 4.00, pois ambos tem os prós e contras.

Hummm... que estranho, para mim só ocorre o erro 495 (ou 403) em GO se tentar utilizar Capicom. No geral funciona com WinCrypt, mas existem muitos clientes com Windows desatualizados e bugamos, que estou quase desistindo de utilizar a WinCrypt e voltar a utilizar a Capicom, mas infelizmente só em GO não funciona a Capicom na 4.00, em outros estados funciona normal. Nem sequer o ambiente de homologação funciona em GO com Capicom na versão 4.00 (na 3.10 normal). Estou em uma sinuca de bico, pois estou acreditando ser inviável atualizar todos os computadores de todos os clientes para manter o uso da WinCrypt, mas a Capicom não funciona em GO sei lá por quê.

@GILBERTO FARIA, erro erro que acontece com você em GO é porque está utilizando Capicom, certo?

Conseguiu resolver o erro "12175 - um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor"? Estou começando a liberar o meu sistema em produção em GO na versão 4.00 e até estava indo muito bem, funcionando de primeira em alguns clientes, até que surgiu um bendito com com esse erro (vale lembrar que é o mesmo executável, com as mesmas configurações), ainda vamos investigar, mas a princípio deixamos fazendo as atualizações do Windows para ver no que dá. Estamos utilizando as mesmas configurações que você (WinCrypt (do print) e SSLType LT_TLSv1_2).

Pessoal, gostaria de sugerir aos moderadores, se possível, fixar um tópico para ter o feedback da comunidade, com a informação de quem já está emitindo em PRODUÇÃO a versão 4.00 tanto para NF-e quanto NFC-e. Acredito que assim possa encorajar mais pessoas a ativar a nova versão ao saber que outros já estão utilizando com sucesso. A princípio já consegui ativar em dois estados com sucesso e ainda não tive problemas, que foi em GO e MA, então vou criar uma listinha, se os moderadores acharem interessante, poderão editá-la com o feedback do pessoal. Seque uma sugestão simplificada da lista: Quais estados estão aceitando em PRODUÇÃO a versão 4.00? AC= AL= AM= AP= BA= CE= DF= ES= GO=NF-e/NFC-e MA=NF-e/NFC-e MG= MS= MT= PA= PB= PE= PI= PR= RJ= RN= RO= RR= RS= SC= SE= SP= TO= Fabrício Gomes Araújo

@carlosinfoteen Veja a documentação, a tag ICMSSN102 aceita: Tributação ICMS pelo Simples Nacional, CSOSN=102, 103, 300 ou 400. Provavelmente está informando 103. Aqui tem um resumo em pdf com diagramas das tributações aceitas:

A única coisa que posso dizer é que é a opção 1, o resto é maluquice de contador ou sei lá o quê. Digo isso por seguir a mesma regra que era aplicada para medicamentos, onde os lotes ficavam na tag med e agora foram para o rastro, e todos os grandes distribuidores faziam na tag med exatamente como a opção 1 que agora será a tag rastro. Que com certeza é a mais lógica. A estrutura foi criada justamente para aceitar mais de 1 lote por produto.

Estou utilizando WinCrypt com essas configurações: Para versão 4.00 utilizei ACBrNFe.SSL.SSLType := LT_TLSv1_2; Para versão 3.10 utilizei ACBrNFe.SSL.SSLType := LT_all; Lembrando que os testes que fiz foram em homologação.

Olha pessoal, a única coisa que posso dizer é que estou testando agora à tarde em GO em Homologação e está funcionando tudo normal, tanto NF-e (3.10 e 4.00) quanto NFC-e (3.10 e 4.00).

@Claudiomir, não sei que prazo é esse de 01/04/2018 que te passaram... mas só para te deixar ainda mais confuso em relação à NFC-e, olha esse post:

No meu entendimento, NFC-e 4.0 já está em produção a muito tempo (NT_2016_002_V1.41, produção 04/12/2017), apesar das SEFAZ não estarem cumprindo o prazo estipulado pelo próprio governo. Mas houveram pequenas modificações como a NT_2016_002_v1.42, onde essas modificações entraram em vigor em produção em 22/01/2018, agora estão modificando novamente a versão da NFC-e 4.0 (que já está em produção), com essa questão do QR-CODE 2.0, com novos prazos para essas modificações que é para entrar em produção em 02/07/2018, e ainda adiando o término da versão da NFC-e 3.10 para 01/10/2018. O complicado que vejo nessa confusão toda é que a SEFAZ de MT já está se abraçando com a nova nota técnica para ter a desculpa que não tem ambiente de produção funcionando atualmente, que é um absurdo. Conforme esse entendi nesse post:

@carlosinfoteen, sobre o que gerar para os contadores, pode até variar pelo sistema que eles utilizam, por exemplo, no meu caso, para notas canceladas, estava gerando apenas o arquivo xml do evento de cancelamento, mas o contador não conseguia importar no sistema deles, então a equipe técnica informou que teria que gerar também o xml da nota original autorizada e também o xml do evento de cancelamento de cada nota cancelada, então funcionou para eles.

@alexandrebarbosa, veja o que diz a nota técnica NT_2016_002_v1.42, na última página (60). 6 Campos do DANFE Nesta nova versão não haverá alteração no leiaute do DANFE. As informações relativas ao Fundo de Combate à Pobreza (FCP) devem ser informadas: No campo de "Informações Adicionais do Produto, tag: indAdProd", os valores informados por item nos campos (vBCFCP, pFCP, vFCP, vBCFCPST, pFCPST, vFCPST), quando existirem. Os valores de totais do FCP (id: W04b e W06a) devem ser informados em "Informações Adicionais de Interesse do Fisco, campo “infAdFisco", quando existirem."

Chegou a testar? Valida isso primeiro... as vezes as mensagens de rejeição da SEFAZ são meio sem noção.

Pelo que vi, o seu valor da forma de pagamento da duplicata não confere, não deveria ser 133,57?

@systronic, para NF-e/NFC-e não existe o conceito de dar desconto no Valor Total, o desconto total nada mais é que a soma de descontos de todos os itens da nota, ou seja, se a sua aplicação existe a opção de dar um Desconto no Valor Total, então você terá que ratear e somar esse desconto adicional nos seus itens, de modo que a soma de descontos dos seus itens dê o desconto total da nota. Sobre qual melhor estrutura de armazenamento você decide, mas na prática do ponto de vista da nota é um desconto só no item.

Resolvi dar uma pesquisada e realmente existe um ACBrNFe1.NotasFiscais.ValidarRegrasdeNegocios, que é o que deve estar falando. Eu não utilizo ele, mas o que falou realmente procede, não existe ajustes na programação para o vFCPST, conforme o print dos fontes abaixo: O que sugiro a você, é implementar os ajustes e então anexar aqui a ACBrNFeNotasFiscais.pas com as modificações, para que os moderadores possam subir para o svn. Ok? Inté... Fabrício Gomes Araújo

@edvaldo, não tenho muito conhecimento do funcionamento interno do componente, acreditava que esse tipo de restrição vinha diretamente da SEFAZ, que apenas existiam as validações básicas dos schemas XML antes do envio... infelizmente não consigo ajudá-lo. Espero que alguém do fórum com mais conhecimento possa ajudá-lo. Boa sorte.

@edvaldo Se for possível, posta o xml para que o pessoal possa ajudar a identificar o que pode estar sendo preenchido incorretamente.

Se for olhar a documentação, realmente o FCP não compõe o valor total da nota:

O seu vProd no item você colocou o líquido (77.03), sendo que tem que ser o bruto (81.95).

Todas essas informações podem ser obtidas no próprio "Manual de Orientação do Contribuinte - versão 6.00", e nas notas técnicas que o atualizam. Aqui mesmo no grupo tem um resuminho das tags de tributações para o regime normal e simples: Acredito que irá ajudar. Fabrício Gomes Araújo

Caramba @BigWings, de certa forma o prazo final para uso da versão 3.10 já está até próximo (02/07/18) e ainda tem SEFAZ que não se adequou à versão 4.00 em produção? Inacreditável... Os prazos da SEFAZ em produção já expiraram a muito tempo (versão 4.00: 04/12/2017, e novas regras: 22/01/2018). Será que o prazo da versão 3.10 será adiado novamente? Já estava preparando uma versão do meu sistema para deixar fixo a versão 4.00 e ter um marco para que todos os clientes migrem, agora fiquei na dúvida. Valeu pela informação @BigWings, obrigado. Fabrício Gomes Araújo

Independente de qualquer coisa @Marcelo França_1209, se por exemplo, ocorreu uma queda de conexão no momento de você receber os dados da Inutilização, infelizmente não tem o que fazer, não existe como recuperar os dados do protocolo e tudo mais, não é como uma nota onde existe a consulta para nos salvar, a Inutilização tem essa limitação mesmo. Até onde sei não tem o que fazer... infelizmente. Fabrício Gomes Araújo

Pessoal, Acabei de adicionar as urls de NFC-e 4.00 para MT. Adicionei tanto de homologação quanto de produção, mas só tinha como testar em homologação, até onde testei está ok, autorização, consulta, cancelamento e inutilização. Peguei as urls em: http://nfce.encat.org/desenvolvedor/webservices/ O próprio site de MT ainda nem sequer atualizaram (https://www.sefaz.mt.gov.br/portal/nfce/?pg=cGdJbmZvcm1hY2Fv). Segue o arquivo ACBrNFeServicos.ini em anexo ACBrNFeServicos.ini Fica a dica para os moderadores, para subir para o svn. Fabrício Gomes Araújo