Gr@c@

Pelo jeito, novas alterações: 18/06/2018 - ATENÇÃO: Publicada versão 1.60 da NT 2016.002 e pacote de schemas XML correspondente A versão 1.60 da NT 2016.002 posterga o prazo de desativação da versão 3.10 em 30 dias, define novos prazos para validação do QR-Code da NFC-e, entre outras alterações.Assinado por: Coordenação Técnica do ENCAT

Perfeito. Consegui enviar sem erro com timeout = 20 segundos (timeout menor ocorreu erro). E com esse timeout consultei e cancelei sem nenhum erro.

Depois de muitas tentativas a minha NF-e foi autorizada. Mas ao tentar cancelar deu novamente o erro 12002-timeout. Na terceira tentativa consegui cancelar.

Ainda continuo tentando enviar uma NF-e da minha empresa mesmo (em produção) versão 4. Continua o erro 12002-timeout. E eu já enviei outras notas hoje com o mesmo aplicativo. Clientes que ainda estão com a versão 3.10 estão enviando notas normalmente. O problema é só com a 4.00 mesmo e ainda acredito ser no SEFAZ/MG. Em um outro aplicativo que não usa ACBr instalado em numa empresa aqui na cidade também está ocorrendo o mesmo retorno.

Esse erro está ocorrendo aqui em MG. Cliente acabou de me ligar e até hoje de manhã estava emitindo notas. Então parece ser problemas no SEFAZ/MG.

Qual(is) ferramenta(s) vocês utilizam para armazenamento de dados na nuvem (com criptografia de dados)? Existe alguma opensource que ofereça facilidade de upload e download? Google Drive é seguro? E para fazer a criptografia antes do armazenamento? Qual ferramenta mais indicada?

Pessoal, acompanhem o link

Vou por tentativas 1a tentativa (essa até agora está funcionando 100% em micros com windows 7 ou superior "original" atualizado) SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsLibXML2 SSLType = LT_TLSv1_2 2a Tentativa SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsMSXML SSLType = LT_TLSv1_2 3a Tentativa SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsLibXML2 SSLType = LT_ALL 4a Tentativa SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsMSXML SSLType = LT_ALL

Nos meus clientes onde deu esse erro foi problema no TLS1.2. Máquinas que não foram atualizadas completamente, windows não original. Nelas tive que usar o LT_All. Porém não uso essa opção "SSLXmlSignLib: xsXmlSec" e xsLibXml2 ou xsMsXml

Vc não precisa migrar para win 10. Meus micros com win7 sp1 licenciados estão funcionando normalmente. Somente máquinas com windows 7 não original estão dando problemas. Mesmo atualizando tudo. E mesmo assim, apenas algumas não funcionam.

Tem alguns micros que não funcionam com xsLibXML2 embora estejam com o windows atualizado e até mesmo foram formatadas antes. Por isso tive que usar o xmMsXml. Você disse "não precisam do ajuste". Mas se fizer o ajuste irá funcionar com o xmMsXml?

Uma dúvida: Tem que renomear o arquivo mesmo quem não usa SSLXmlSignLib = xsXmlSec ou xsLibXML2?

Já encontrei o motivo. O cliente não pode mais comprar nessa inscrição estadual, mas nem o Sintegra nem a Receita Estadual atualizaram a nova inscrição. 303 - Uso Denegado: Destinatário não habilitado a operar na UF: Esta rejeição retorna nos casos em que a Inscrição Estadual do destinatário não corresponde a UF que foi informada na nota. Para prosseguir com a emissão de outras NF-e para este destinatário é necessário que seja feita a verificação correta do cadastro junto à Receita Federal deste destinatário. A nota ficará com o status de denegada, não podendo mais realizar alterações e/ou reenviar, devendo emitir uma nova numeração após verificação dos dados corretos do destinatário.

cliente tentando enviar uma nota NFe 400 - Emitente MG Destinatario PI , mas está ocorrendo esse erro (Destinatario bloqueado na UF). Porém o destinatario está habilitado no sintegra Piaui e na receita estadual.

Minas ainda não liberou o ambiente de testes. Se MG seguir o exemplo de alguns estados como Maranhão, a partir do momento da obrigatoriedade da NFC-e os ECF´s terão que ser encerrados.

Fiz uma nfe pela minha empresa Simples Nacional, usando o mesmo CSOSN = 500 e a nfe foi enviada. Comparando a meu xml com o xml do cliente estão absolutamente iguais. Mesmo cliente, mesmo produto, vBCSTRET /vICMSSTRet/pST não apareceram porque estavam zerados. A unica diferenca entre os xmls é o emitente, mas o enquadramento é o mesmo (CRT=1). Fiz uma outra nfe informando os valores vBCSTREt/vICMSSTRET mas deixei o pST = 0. A NFe foi autorizada gerando a tag pST.

atualizei subversion 15269 20:03:45, quarta-feira, 6 de junho de 2018 mas também não gerou a tag pST para o CSOSN 500 (testei pST = 0 e pST = 20)

Atualizei SVN subversion 15268 de 06/06/2018. O erro persiste. No meu caso é CSOSN 500 e a tag pST estou informando = 0.

Falha na validação dos dados da nota 1871 - Element {http://www.portalfiscal.inf.br/nfe}vICMSSTRet: this element is not expected. Expected is ..... pST} Estou informando o pST = 0 mas a tag não aparece 31180608182726000102550050000017891000017890-nfe.xml

Como ficou essa questão?

Ainda estou com esse problema da tag pST não estar sendo gerada. Como foi solucionado? Meu componente está atualizado.

Italo, há uma mistura de assuntos aqui. O meu problema de Schema inválido está ocorrendo na NFe 4.00.

sim. Em alguns clientes uso o TLS 1.2, mas em vários só aceitou o LT_ALL. Um detalhe: enviei ao Fale Conosco de MG uma solicitação de adiamento do prazo da obrigatoriedade da NFe 4.00 alegando intermitência nos serviços da NFe 4. Já me responderam dizendo que não há nenhuma previsão de adiamento até o momento. Mas creio que quanto mais desenvolvedores solicitarem isso, melhor. E enviar NFe com tantos problemas de intermitência está me parecendo inviável.

Estou com esse erro em vários clientes depois que passei a usar o wincrypt. Todos os responsáveis pelas redes nesses usuários alegam ser problema no aplicativo. Já tentei várias opções de configuração.