André Ferreira de Moraes

Este campo é gerado da mesma forma pelo ACBr desde 2015. A mensagem q vc cita, se foi gerada pelo ACBr é apenas um alerta, e se for da SEFAZ provavelmente eles passaram a validar esse campo agora.

Pq existe uma regra no manual para não gerar esse grupo qdo for NFC-e. Enquanto o campo vIPI no total tem ocorrência 1-1, ou seja, deve sempre ser gerado.

Essa imagem é da NT 2016.002 - v1.60.

Não.

Provavelmente a SEFAZ não está preparada. A NT 2016.002 v1.60 alterou os prazos para o ambiente de homologação e produção. Fonte: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=Y6Lj7G0uHwc=

Já atualizaram:

Qual o erro?

Ainda não foi colocado no ACBrMonitorPLUS a opção para configurar a versão doQrCode.

Provavelmente seu 407 Proxy Authentication Required Provavelmente seu proxy está bloqueando os endereços da nova versão.

Está no SVN e disponível tbm no portal da NFe.

Vc deve verificar se seu estado já aceita versão 2 do QrCode. Atualmente apenas alguns estados estão aceitando em ambiente de homologação.

Basta vc não informar o valor do IPI

Os endereços do ACBrNFeServicos.ini estão seguindo os disponibilizados em http://nfce.encat.org/desenvolvedor/url-por-uf-utilizada-para-consulta-chave-qr-code-versao-2-0/ Provavelmente a SEFAZ PE não está preparada para a versão 2.00 do Qr-Code.

Este arquivo anexado não é oq deve ser enviado a SEFAZ.

Esses são apenas os endereços dos webservices, o SOAP Action está dentro do envelope. Anexe um arquivo que contenha todo o envelope SOAP.

Atualize sua pasta schemas.

Não sei, sem um passo a passo pra simular não tenho como analisar. Se vc está com os fontes atualizados, o grupo ICMSST só deveria ser gerado se o campo ICMS.CST = cstRep60, caso esteja informado cst60 deveria gerar o grupo ICMS60.

Provavelmente seu SoapAction não está correto.

Vc precisa incluir os novos campos da versão 4.00. Veja a NT 2016.002 - http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=qsg ostnbKY=

Em ambiente de homologação nem na versão 3.10 funciona OpenSSL em Goiás.

Windows XP não possui suporte oficial ao TLS 1.2 - https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/ Vc deve usar OpenSSL ou tentar uma das atualizações não oficiais - https://sockettools.com/kb/support-for-tls-1-2-on-windows-xp/

A openssl deve funcionar em qualquer um dos SOs citados acima, a WinCrypt só é necessária qdo for utilizar certificado A3.

Vejam as funções abaixo para entender quando o arquivo ACBrNFeServicos.ini será lido: procedure TWebServicesConf.LerParams; var ConteudoParams: AnsiString; begin ConteudoParams := LerParamsIniServicos; if ConteudoParams = '' then ConteudoParams := LerParamsInterno; FParams.Text := ConteudoParams; end; function TWebServicesConf.LerParamsIniServicos: AnsiString; var SL: TStringList; begin Result := ''; if (fpConfiguracoes.Arquivos.IniServicos <> '') and FileExists(fpConfiguracoes.Arquivos.IniServicos) then begin SL := TStringList.Create; try SL.LoadFromFile(fpConfiguracoes.Arquivos.IniServicos); Result := SL.Text; finally SL.Free; end; end; end; Ou seja, o arquivo será lido apenas se a propriedade ACBrNFe1.Configuracoes.Arquivos.IniServicos estiver preenchida e o arquivo existir no disco, caso contrário será chamada a função LerParamsInterno que irá obter o conteúdo do Resource embutido automaticamente na aplicação.

Reverti alterações do commit 15264. Não será possível usar LT_ALL na versão 4.00 com HttpWinApi sendo necessário configurar para LT_TLSv1_2

Apenas na última versão funciona.