Gr@c@

aqui em MG está havendo lentidão nos servidores. Tem que colocar um timeout de 10 a 30 segundos.

Só para esclarecer como resolvi esse tópico: foi simplesmente formatando o prod.nItemPed para 6 algarismos (1 para 000001). Fiz os testes com prod.nItemPed = 1 e sempre retorna o mesmo erro.

Não estou usando a homologação do Amazonas, justamente porque a versão 4.00 não estava funcional para desenvolvedores de outros estados.

1-Cancelamento extemporâneo (desde que não haja impedimentos como: mdf-e emitido, registro de passagem pelo fisco) 2-CT-e de anulação

Já fez um teste colocando tudo localmente nessa máquina? Aplicativo, pasta schemas, pasta dos pdf etc...Tive um cliente que uma das máquinas não estava funcionando por problemas de configuração de rede. Só funcionou localmente até o TI solucionar o problema.

Passei por esse problema em vários clientes com A3 e todos eles só foi possível funcionar com a atualização do Windows, lembrando que é necessário o .Net Framework igual ou superior a 4.6.2 e há tópicos relatando quais as KB.... de atualização do windows para ativar a TLS 1.2. Teve uma máquina que estava com o certificado A3 para vencer a poucos dias (como o A3 tem validade de 3 anos a instalação já estava antiga) e nessa foi preciso reinstalar o certificado com o novo instalador disponibilizado pela certificadora.

Acredito que o erro 1824 atomic type é pelo uso do xsLibXML2. Substituindo pelo xsMsXML corrige.

Seu xml contém erros conf o validador do RS https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx

Tem que aumentar o TimeOut (que deve estar 5 seg) para 10 a 30. Isso está ocorrendo por lentidão ou sobrecarga nos servidores da SEFAZ.

Vamos por partes: O que fiz foi formatar o nItemPed de 1 para 000001 -> a nota foi autorizada "- SSLXmlSignLib esteja configurado como xsLibXML2" -> minha máquina está configurada para xsLibXML2, mas o cliente está com o xsMsXML "- Os arquivos de schema estejam corrompidos" -> não estão corrompidos porque notas que não tem a tag xPed e nItemPed estavam sendo autorizadas "- Os arquivos de schema contenham string de validação não compreendidas pela libxml2.dll (já vi isso em schema de NFSe, nunca da NFe)" -> aqui não sei, mas tenho tido problemas de atomic type que já havia relatado ao Italo e desconfio que seja esse o caso pq só ocorre quando o nItemPed tem 2 algarismos (10,11...). "- A configuração da pasta de schemas esteja no formato \\servidor\compartilhamento" ---> sim, está nesse formato na minha máquina (com xsLibXML2) e na máquina dos clientes. Mas outras notas são autorizadas. Não deveria ocorrer com todas as notas o erro de schema inválido? A configuração da pasta tem que ser tipo Z:\Schemas ?

Te enviei na sua caixa de mensagem

Anexe o xml que foi gerado.

por enquanto só temos isso: SEF/MG prevê implantação da NFC-e para o início de 2019 11/06/18 A Secretaria de Estado de Fazenda está finalizando a contratação necessária para adequação da área de Tecnologia da Informação (TI) a fim de viabilizar a emissão de Nota Fiscal do Consumidor Eletrônica (NFC-e) em Minas Gerais.A estimativa da SEF/MG é que no segundo semestre de 2018 seja possível dar início à homologação da funcionalidade e, na sequência, colocar em prática um piloto com algumas empresas. Concluído o piloto, será possível agregar, gradativamente, contribuintes voluntários.A legislação com o cronograma de obrigatoriedade será publicada também no próximo semestre, com previsão de início em 2019.

André, esse erro ocorre ao tentar enviar a NFe 4.00. Antes o nItemPed passava com menos de 6 algarismos, inclusive tem um tópico de alguém solicitando para remover os zeros a esquerda desse campo no ACBr. O correto agora é formatar 000001 e não 1? Nesse caso dessa nota, os itens de 1 a 9 não foram rejeitados e eles também possuiam as tags xPed e nItemPed . O erro foi só do 10 em diante. (nos itens dessa nota, o nItemPed é o mesmo numero do item porque a NF foi feita importando-se um pedido de compra). Então item 1 da nota o xPed = 2525 nItemPed = 1 item 2 da nota o xPed = 2525 nItemPed = 2..... item 10 da nota o xPed = 2525 nItemPed = 10...>>>>a partir daqui começou o erro. Seria o mesmo caso do Atomic Type, campo com 2 caracteres como vem ocorrendo com uTrib = 'Kg'? Editando: é isso mesmo. Todas as notas houve rejeição só a partir do nItemPed > 9 (não havia prestado atenção nesse fato). Terei que formatar o campo da mesma forma como tive que fazer no MDF-e com o campo cInt.

Quando tPag = fpCartaoCredito ou tPag = fpCartaoDebito estou informando tpIntegra = tiNaoInformado e não informo as tags tBand,CNPJ e cAut. Até agora não tive nenhum cliente no Maranhão com rejeição de NFC-e ou NF-e, inclusive hoje mesmo emitiram NFC-e e não houve rejeição. Não uso o tpIntegra = 1 porque acredito que seria a integração do TEF. Mas vou implementar a opção do tpIntegra = tiPagNaoIntegrado e habilitar os campos tBand,CNPJ e cAut para que o usuário informe manualmente (sendo que tenho as administradoras cadastradas com seus rescpectivos cnpj, então o usuário selecionará a administradora ao invés de informar cnpj). Só me preocupa essa Resolução Administrativa 05/2018 do SEFAZ/MA, que não está muito clara. Embora não fale em TEF e sim em NFC-e vinculada ao comprovante de Débito/Crédito. No caso do seu cliente onde houve rejeição, tentou tpIntegra = tiNaoInformado?

os campos que informam são prod.xPed e prod.nItemPed. Não estou informando a tag de compras. No entanto o erro vem como [<det nItem='10'><prod>nItemPed] Item do Pedido de Compra da DI - adição - Tamanho menor que o permitido. Antes o prod.nItemPed não precisava dos zeros a esquerda, inclusive parecem que foram removidos no ACBr. Todas as notas com as tags prod.xPed e prod.nItemPed estão sendo rejeitadas desde ontem a tarde. (18/06/2018 após as 15:00hs) -<det nItem="1"> -<prod> <cProd>27047</cProd> <cEAN>SEM GTIN</cEAN> <xProd>BOMBA COMB CORSA MPFI S10 BLAZER</xProd> <NCM>87089990</NCM> <CEST>0107500</CEST> <EXTIPI>00</EXTIPI> <CFOP>5405</CFOP> <uCom>PC</uCom> <qCom>1.0000</qCom> <vUnCom>158.2000000000</vUnCom> <vProd>158.20</vProd> <cEANTrib>SEM GTIN</cEANTrib> <uTrib>PC</uTrib> <qTrib>1.0000</qTrib> <vUnTrib>158.2000000000</vUnTrib> <vDesc>48.20</vDesc> <vOutro>1.50</vOutro> <indTot>1</indTot> <xPed>145943</xPed> <nItemPed>1</nItemPed> </prod>

Ainda não me relataram nenhum problema e estou torcendo muito que não relatem

A partir de hoje à tarde aqui em MG, começou a dar esse erro "[<det nItem='10'><prod>nItemPed] Item do Pedido de Compra da DI - adição - Tamanho menor que o permitido Em seguida Schema Inválido. Esse erro não estava ocorrendo até então. Inclusive fizemos nota igual a que foi autorizada somente mudando o numero da nota.

Depois que saiu essa NT 1.60 as notas fiscais estão sendo rejeitadas com Schema inválido, dando erro "Item do pedido de compra da DI-Adicao - Tamanho menor que o esperado) e essas tags nem estão sendo enviadas na montagem do xml. Será que os schemas já foram alterados aqui em MG e esse troço endoidou geral? E até hoje (antes de sair essa 1.60) estava tudo normal. Fizemos até uma nf igual a uma que foi autorizada mais cedo (completamente igual, só mudando a numeração) e ela foi rejeitada.

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?