Valdir Dill

Boa tarde, Na validação de MDFe está ocorrendo um erro (print anexo) ao validar o valor da IE, campo rodo.veicTracao.prop.IE. Ocorre que o proprietário do veículo é um CPF e, nesse caso, a IE deve ficar em branco, mas não aceita. Conferi no XML e a IE está mesmo em branco Veja as tag relacionados ao transporte <rodo><veicTracao><placa>JYA7662</placa><tara>3000</tara><capKG>7100</capKG><capM3>0</capM3><prop><CPF>93799918191</CPF><RNTRC>00922040</RNTRC><xNome>GILMAR DONIZETE VIEIRA</xNome><IE></IE><UF>MT</UF><tpProp>0</tpProp></prop><condutor><xNome>GILMAR DONIZETE VIEIRA</xNome><CPF>93799918191</CPF></condutor><tpRod>06</tpRod><tpCar>02</tpCar><UF>MT</UF></veicTracao></rodo> Alguma sugestão? Obrigado.

Bom dia, Eu segui a sugestão do @Daniel Simoes e fiz minha própria tela de listagem dos certificados para o usuário selecionar qual certificado deseja vincular. Aí partir daí não tivemos mais relatos desse erro do plugin de banco fechar meu sistema. Compartilho a função em anexo. Veja se lhe é útil. Abraços. functionCertDigital.txt

Boa tarde, Fiz isso e agora está dando rejeição: "erro não catalogado". Alguma dica? Obrigado.

Boa tarde, Eu estava com esse erro em GO. As configurações abaixo resolveram: SSL.SSLType := LT_TLSv1_2; Configuracoes.WebServices.TimeOut := 15000; Abraços

Boa tarde, Já tive vários problemas como esse. A causa é o plugin de algum banco instalado/ativo no computador. Muito provavelmente Warsaw. Normalmente reiniciar o micro resolve. Mas pode ser necessário desinstalar o plugin e o sistema do banco. Abraços

Boa tarde, Desculpe, mas não estou conseguindo o XML. Para poder fazer a nota passar, o usuário simplesmente resolveu mudar o CSOSN para 102, acredita? Dá erro num enquadramento e eles vão mudando o CSOSN até que um dê certo, rs... Tentei reproduzir o erro aqui em laboratório, em homologação, mas não ocorre. Vou aguardar e ver se ocorre novamente. Pode também ser que era instabilidade no WS. De toda forma, agradeço sua ajuda. Obrigado.

Não, uso TLS_All. Não tenho como dbugar aqui, mas usuário informou que o problema só ocorre quando usa CSOSN 500 e informa os dados nos novos campos do "ICMS Efetivo". Obrigado

Bom dia, Alguma ideia sobre a possível causa do erro anexo? Obs.: SEFAZ Maranhão. Obrigado.

Bom dia Italo, Beleza pura. Entendi. Obrigado.

Bom dia, Sim, é xsLibXml2. A configuração é esta: SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsLibXml2; tem que usar os esquemas com final OPENSSL. Não entendi muito bem. Vi que na pasta dos schemas tem o tiposGeralMDFe_v3.00-OPENSSL.xsd. Mas como direciono o componente para utilizar esse arquivo e não padrão? Obrigado

Boa noite, Alguma sugestão @Rafael Dias ? Obrigado.

Bom dia, Arquivo em anexo. Eu inclusive havia analisado a tag nro e parece estar correta. Obrigado. 21180705157537000264580010000002681577941147-mdfe.xml

Bom dia, Estou tendo o erro abaixo em um cliente ao emitir MDFe: falha na validação dos dados do manifesto 268 1824 - element '{http://www.portalfiscal/mdfe}nro': 'SN' is nota a valid value of the local atomic type Ao que tudo indica, o xsd não está aceitando o valor "SN", no campo do número da rua do endereço do emitente do MDFe. Mas esse valor está correto de acordo com as regras do próprio .xsd, ou seja, campo do tipo caractere de 1 a 60. O problema maior é que não consigo debugar, pois só acontece na máquina do cliente. Não parece ser erro de .xsd desatualizado, pois fiz os testes em minha máquina com os mesmos .xsd do usuário. Alguma dica? Obrigado.

Daniel, acho que você não leu direito minha resposta ou eu não fui claro, rs.. Como mencionei, não tem necessariamente a ver versão a versão do Windows (pode ser 7, 8 ou 10), mas o problema é falta algum update/pack. Vai por mim, tivemos mais de 180 usuários com esse erro. Todos, absolutamente todos foram resolvidos após a atualização total do Windows. Veja, por exemplo, se este remendo está instalado -> https://support.microsoft.com/pt-br/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows Abraços.

Boa tarde, Isso é problema de Windows desatualizado. Tive vários usuários com esse problema e, em todos os casos, a atualização do Windows resolveu. Não necessariamente a versão, mas falta algum update/pack. Logicamente que não pode ser XP. Esse já não funciona faz tempo, rs.. Abraços.

Bah, que grosseria tchê!! Será que nunca ninguém pode discordar de ti??? Eu só queria ajudar relatando o que acontece aqui. O post nem foi eu que abri. Só estava querendo ajudar o outro colega que iniciou o post. Eu uso os componentes Acbr há mais de 10 anos e Isso NUNCA ocorreu comigo também. Trabalho com instalação de softwares/Windows há mais de 20 anos. Não estou iniciando agora. Se você tivesse lido todo meu relato veria que eu NÃO tenho os fonte onde você diz. Mas tudo bem, da próxima vez não me meto mais nas tuas respostas. De toda forma, obrigado. Encerro minha participação neste post por aqui.

Bom dia, Tenho que discordar @Juliomar Marchetti. Eu fiz uma instalação com o HD formato, ou seja, sem a menor possibilidade de haver .bpls ou outros arquivos do Acbr perdidos na máquina. HD novo, Windows novo e Delphi novo. Pode até isso que você diz, mas então é o instalador do Acbr, quando executado pela segunda vez que faz isso. Veja bem, eu instalo os componentes pelo instalador. Acesso o Delphi e tudo (todos os componentes Acbr) está lá normal. Basta eu fazer um update no svn e executar o instalador novamente. Mesmo que eu não mude absolutamente nada nas configurações de instalação, nem de pasta, nem nada. Só execute o instalador. Quando entrar no Delphi ele vai dar esse erro. Abraços.

Bom dia, Meu Acbr também começou a fazer isso. Já aconteceu 3 vezes nos últimos 15 dias. Toda vez que faço um update e executo o instalador, logo que vou acessar o Delphi ele diz que alguns pacotes não estão lá, mesmo estando. A solução que encontrei foi executar os seguintes passos: - Criar uma nova pasta para os fontes (toda vez tenho que mudar a pasta); - No Delphi eliminar todos os path do Fortes no library path; - No Delphi, em Install Package, remover todos os .bpl do Fortes; - Eliminar a pasta antiga dos fontes; - Na nova pasta baixar os fontes Acbr; - Execute o apagaAcbr.bat; Fiz um teste executando todos esses passos, exceto sem mudar a pasta dos fontes e não funcionou. Instalar instalou tudo certo, mas é só entrar no Delphi que dá o erro. OBs.: não esqueça de na instalação marcar a opção "Copiar todas as dlls(...". Não sei se tem a ver, mas o problema começou depois que mudei para Windows 10. Abraços.

Bom dia, Quando se faz necessária uma reinstalação completa e "limpa" do Acbr, é recomendável executar o apagarAcbr.bat para limpar tudo o que tinha da instalação anterior, correto? Ocorre que esse bat não apaga tudo quando os fontes baixados na máquina tiverem sido gravados numa pasta hospedada em uma partição diferente de C:\. O bat também não tem como apagar esses arquivos anteriores automaticamente, pois não se sabe em qual partição (D:\, E:\, ..) cada um tem seu fontes armazenados. Por isso, estou sugerindo (novo apagarAcbr.anexo) para que se mostre uma mensagem recomendando para que cada um faça essa deleção manualmente. Obrigado. apagarAcbr.bat

Bom dia, No componente ACBrNFe, a configuração default para a propriedade SSLType é LT_all, certo? Vamos supor que, sem mudar nada em SSLType, eu sete meu componente para ACBrNFe1.Configuracoes.Geral.SSLLib = libWinCrypt, ok? Essa configuração fará com que automaticamente: - CryptLib fique igual a CryWinCrypt - HttpLib fique igual a httpWinHptt - XMLSignLib fique igual a xsLibXml2 Certo? Muito bem, agora vem minha pergunta: Supondo que nas opções de internet o usuário tenha habilitado todos os TLS, quem é que vai "decidir" qual TLS (1.1, 1.2, ...) será usado pela conexão no momento de transmitir a nota? É a SSLType? ou a é CryptLib? ou a é HttpLib? ou a é XMLSignLib? ou é o Windows? Obrigado.

Bom dia, Certo. Mas tem um detalhe: dependendo do NCM, tem vários CNAEs que já teriam obrigação de informar o "SEM GETIN", alguns deles desde Jan/18. Contudo, o schema da 3.10 (leiauteNFe_v3.10.xsd) não aceita esse literal. Apenas o layout 4.0 (leiauteNFe_v4.00.xsd) que aceita. Então, no caso, por exemplo, do CNAE 324 e NCM 9503 a 9505, obrigatoriamente o emitente teria que já estar na NFe 4.0 desde janeiro/18, é isso? Obrigado.

Boa dia, É constante. Ele ocorre algumas máquinas. Não consegui estabelecer o padrão ainda. Mas quando ocorre, ocorre sempre. Vou tentar fazer debug na máquina do usuário para ver quando ocorre. Obrigado

Bom dia, Também estou enviando sem nada em cEan e cEanTrib e não gera nenhuma rejeição. Será que houve algum adiamento dessa regra de validação? Obrigado.

Bom dia Italo, Obrigado pela ajuda. Na verdade, meu problema começou esta semana em alguns usuários quando atualizei o sistema para usar TLS 1.2. Na SSLHttpLib eu tinha configurado = httpWinHttp, mas em alguns usuários com Windows 7, começou a dar erro "12175..". Aí mudei SSLHttpLib para httpWinINet. Isso resolveu na maioria da máquinas. Mas algumas poucas máquinas, essa mudança para httpWinINet começou a dar esse erro de A.V. Obrigado.

Bom dia, - AcbrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; - AcbrNFe1Configuracoes.Geral.SSLHttpLib := httpWinINet; - AcbrNFe1Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Quando utilizo esta configuração (acima) dá erro de access violation. Ainda não consegui debugar para ver onde exatamente ocorre o erro, pois só acontece em algumas máquinas de usuários. Já com esta configuração (abaixo), o erro não acontece. - AcbrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; - AcbrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; - AcbrNFe1Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Alguma sugestão? Obrigado.