bsoft

Estamos recebendo o erro "O valor do campo 'numeroRecibo' está inválido. O valor deve possuir 10 caracteres numéricos!". Isso acontece porque, durante a leitura do retorno, o ACBr interpreta o número do recibo como inteiro. Aparentemente nessa virada de ano o n° recibo ficou tão grande que não consegue ser mais interpretado como inteiro. Segue em anexo a correção. Foi somente a troca de Leitor.rCampo(tcInt, 'ns1:numero'); para Leitor.rCampo(tcStr, 'ns1:numero'); pgnreRetEnvLoteGNRE.pas

Com a adesão do RJ à GNRE, há uma situação que precisa ser contemplada. Com o cód. receita 10030, é possível enviar o Valor Principal e o FCEP, ou apenas o FCEP. Nesta última situação o ACBr não está gerando a tag valorGNRE, ocasionando erro de validação. Segue em anexo a sugestão de correção para que o total seja preenchido corretamente no XML quando apenas o FCEP for informado. pgnreGNREW.pas

Perdão, esquecemos de anexar o arquivo fonte que foi modificado foi na unit ACBrGNREGuiasRetorno.pas ACBrGNREGuiasRetorno.pas

Identificamos dois problemas na impressão da GNRE v2.00. 1. NumDocOrigem deveria ler todos, não só do tipo "10". 2. InfoComplementares -> atualmente lê das tags "informacoesComplementares" e "campoExtra", concatenando os valores. O problema é que algumas UFs retornam a mesma informação, que foi enviada no "campoExtra", em ambas as tags. Na impressão a informação fica repetida. E outras UFs somente retornam na tag "informacoesComplementares". A alteração proposta para corrigir foi adicionar a string somente se ela não existir no "informacoesComplementares". Também foi adicionada uma quebra de linha para haver uma separação. Em anexo segue um XML de exemplo e a respectiva guia de impressão, onde é possível ver as duas situações. gnre.pdf gnre-impressao.xml

Aqui é a alteração que ficou faltando. Segue em anexo o mesmo arquivo, desfazendo as correções de indentação. ACBrMDFeDAMDFEFR.pas

Verificamos que a versão que anexamos aqui na primeira mensagem não foi exatamente a mesma que foi commitada na revisão 20492. Tudo bem que a maioria das alterações que foram descartadas são apenas ajustes de indentação, mas na unit ACBrMDFeDAMDFEFR.pas, ficou de fora a alteração para String dos campos no cdsModalAereo, na procedure CriarDataSetsFrx, que é essencial para o funcionamento correto. Por favor, pedimos que reavaliem o arquivo citado.

Pessoal, estamos atualizando o nosso sistema para a GNRE 2.0, e identificamos algumas correções necessárias para se fazer no ACBr. As três primeiras modificações do pgnreGNREW.pas são para evitar o preenchimento incorreto de tags que não são obrigatórias, similar ao que é feito na função GerarXML1. A última é relacionada com a tag valorGNRE, onde criamos uma property na pgnreGNRE.pas com este nome para informar o total de serviços. Hoje é enviado ou o campo c06_valorPrincipal ou o campo c10_valorTotal na tag valorGNRE. Porém, se for informado também o campo ValorFECP, será retornado o erro "O valor da GNRE diverge do somatorio dos valores dos itens". Esse comportamento pode ser visto também no site de homologação, ao gerar uma guia para RO, receita 100030, e informar o Valor Principal e o Valor do FECP. Segue os arquivos mencionados em anexo para verificação. pgnreGNRE.pas pgnreGNREW.pas

Pessoal, gostaríamos de contribuir com um ajuste na emissão de MDF-e Aéreo, para o preenchimento correto das tags "nac" (Marca da Nacionalidade) e "matr" (Marca de Matrícula). Atualmente elas estão definidas como Integer, mas na verdade são códigos alfanuméricos, e seguem a expressão regular ER35, igual aos demais campos deste grupo, conforme a página 24 do Layout v3.00a. Um explicação de como funciona na prática estas informações pode ser encontrada na Wikipédia: https://pt.wikipedia.org/wiki/Prefixo_aeronáutico Segue em anexo as modificações necessárias (só não testamos com a impressão em Fortes porque não utilizamos este componente), com os seguintes caminhos a partir do Fontes/ACBrDFe/ACBrMDFe/: ACBrMDFeManifestos.pas DAMDFE/Fast/ACBrMDFeDAMDFEFR.pas PCNMDFe/pmdfeMDFe.pas PCNMDFe/pmdfeMDFeR.pas PCNMDFe/pmdfeMDFeW.pas Obs: incluímos algumas correções de indentação, principalmente na unit pmdfeMDFeW.pas a alteração que interessa é na procedure TMDFeW.GerarAereo; ACBrMDFeDAMDFEFR.pas ACBrMDFeManifestos.pas pmdfeMDFe.pas pmdfeMDFeR.pas pmdfeMDFeW.pas

Boa noite, Ítalo Vimos que você commitou este arquivo aqui, ACBrCTeWebServices.pas, que foi anexado neste tópico na revisão 18495 do Trunk2, mas ficou faltando algo bem importante: na segunda chamada para o procedimento SalvarEventos, no else, não está sendo verificada a configuração do Arquivos.Salvar, gerando assim uma pasta "Docs" com o "-procEventoCTe.xml" a cada emissão, por mais que esteja tudo desabilitado no salvamento de arquivos. Segue em anexo a sugestão de correção com o arquivo já atualizado para a revisão 18566. Obs: o histórico no SVN da revisão 18495, "Removido de Uses as units não utilizadas.", nos confundiu para encontrar que atualização exatamente havia impactado no comportamento do programa.ACBrCTeWebServices.pas

Na sexta-feira, dia 11/10, enviamos a seguinte consulta para a SEFAZ de SP através do Fale Conosco (https://www.fazenda.sp.gov.br/email/default_nfe_cte.asp) : E hoje obtivemos a seguinte resposta: Portanto, está confirmada a mudança na regra no uso do SVC-SP.

Com certeza eles alteraram. Até a validação em ambiente de homologação do link do QRCode passou a acontecer no dia 18/09, mas não duvido que eles tenham "esquecido" da contingência, e resolveram mudar a regra neste meio tempo. Mas é fato que agora não dá para emitir pro SVC-SP enviando link para o homologacao.nfe.fazenda.sp.gov.br ... e só temos que lamentar a falta de transparência por parte deles de não anunciarem esta mudança.

Boa noite, Italo! Desculpe a demora na resposta, não tive tempo de lidar nisso durante o dia de hoje. E negativo: fiz um teste usando um certificado de MG, e recebi rejeição quando tentei enviar para o SVC-SP preenchendo o link do QR-Code com o endereço de SP: <qrCodCTe><![CDATA[https://homologacao.nfe.fazenda.sp.gov.br/CTeConsulta/qrCode?chCTe=31191003169658000110570040000003158002431302&tpAmb=2]]></qrCodCTe> 851-Rejeição: Endereço do site da UF da Consulta via QR Code diverge do previsto Em compensação, enviando o mesmo CT-e para o SVC-SP preenchendo o link do QR-Code com o endereço de MG, foi autorizado: <qrCodCTe><![CDATA[https://hcte.fazenda.mg.gov.br/portalcte/sistema/qrcode.xhtml?chCTe=31191003169658000110570040000003158002431302&tpAmb=2]]></qrCodCTe> O mesmo comportamento acontece no PR, que também recebe a contingência pelo SVC-SP: <qrCodCTe><![CDATA[https://homologacao.nfe.fazenda.sp.gov.br/CTeConsulta/qrCode?chCTe=41191009913033000105670000000016118002431299&tpAmb=2]]></qrCodCTe> 851: Rejeição: Endereço do site da UF da Consulta via QR Code diverge do previsto E o mesmo CT-e OS autorizado com o link para o PR: <qrCodCTe><![CDATA[http://www.fazenda.pr.gov.br/cte/qrcode?chCTe=41191009913033000105670000000016118002431299&tpAmb=2]]></qrCodCTe> O mais absurdo disso tudo é que os dois links de download que foram rejeitados (de SP) são os únicos válidos, que podem ser consultados. E ao fazer o download do XML a partir desta consulta, está lá dentro o link furado (até este momento, inválido) de cada um. 31191003169658000110570040000003158002431302-cte.xml 41191009913033000105670000000016118002431299-cte.xml

A sugestão do @Eduardo Vismara atendeu corretamente a situação do MS (e legal que já está tratando para o PR, MG e MT), mas fazendo testes de emissão em Contingência para UF's que emitem normalmente para o SVRS - e que portanto enviam a contingência para o SVC-SP - continuamos recebendo a rejeição 851 - Endereço do site da UF da Consulta via QR Code diverge do previsto. Para resolver, complementamos a alteração do Eduardo assim: if ( (TipoEmissao in [teSVCRS]) and (CUF in [31,41,50,51]) ) or (TipoEmissao in [teSVCSP]) then Claro, todos os testes foram feitos em Homologação, e por enquanto apenas para as UF's RJ e BA (podemos testar outras, mas não acreditamos que haverá diferença), mas fica a sugestão/alerta de que podem acontecer mais problemas se a Contingência for ativada para quem emite no SVRS. Obs: outra solução seria reverter a alteração do @Italo Jurisato Junior na revisão 17673 do SVN, na qual foram alteradas as URL's do QR Code do SVC-SP, o efeito seria o mesmo. É uma pena não podermos fazer testes em Produção (não sei quanto aos demais, mas para nós está cada vez mais difícil confiar na SEFAZ), mas quanto ao que está acontecendo em Homologação, será necessário realizar uma destas alterações apontadas.

Gostaríamos de reforçar o pedido da @flaviageisler e do @marcioereno de colocar em produção esta alteração. Entendemos bem o argumento que os campos não estão marcados como obrigatórios no manual, mas não há nenhum efeito negativo em mandar esta informação - não lembramos de ter visto a SEFAZ recusar algum documento fiscal por ter sido enviada uma informação que não era obrigatória. Analisando a sugestão de alteração do @marcioereno, ele acabou inutilizando a verificação dos percentuais igual a 0 (if (nfe.Det.Imposto.ICMS.pICMS = 0) and (nfe.Det.Imposto.ICMS.pDif = 0) then), então estamos anexando aqui uma versão mais limpa do mesmo código. Pelos nossos testes, esta verificação não é mais necessária; todas as SEFAZ que testamos aceitam que as tags sejam enviadas zeradas sem problema algum, assim: <ICMS51> <orig>0</orig> <CST>51</CST> <modBC>0</modBC> <pRedBC>0.0000</pRedBC> <vBC>0.00</vBC> <pICMS>0.0000</pICMS> <vICMSOp>0.00</vICMSOp> <pDif>0.0000</pDif> <vICMSDif>0.00</vICMSDif> <vICMS>0.00</vICMS> </ICMS51> E em outras, como RJ e PR, é obrigatório enviar desta maneira mesmo quando está zerado. Segue em anexo a unit pcnNFeW.pas para avaliação. pcnNFeW.pas

Apenas atualize os arquivos ACBrNFeServicos.ini e ACBrNFeServicos.rc da pasta ACBr\Fontes\ACBrDFe\ACBrNFe e recompile seu programa.

Prezados, Com a ativação do SVC para as emissões em MG no ambiente de Produção, o servidor SVC-SP está gerando o seguinte retorno: --------------------------- Versão Layout: 3.00 Ambiente: 1 Versão Aplicativo: SP-CTe-28-05-2019 Status Código: 113 Status Descrição: Serviço SVC em operação. Desativação prevista para a UF em 01/08/2019 às 12:00 horas UF: MG Recebimento: 30/07/2019 15:19:58 Tempo Médio: 1 Retorno: Observação: --------------------------- Este código de retorno, 113 - Serviço SVC em operação, não é esperado na função TCTeStatusServico.TratarResposta da ACBrCTeWebServices.pas, fazendo com que o resultado seja Falso, como se a comunicação tivesse falhado. Para resolver isso, sugerimos incluir este código 113 na verificação, substituindo esta linha: Result := (FcStat = 107); Por esta: Result := (FcStat in [107, 113]); Segue em anexo a unit ACBrCTeWebServices.pas com a modificação sugerida para avaliação, atualizada com a revisão 17399. ACBrCTeWebServices.pas

Estamos com o mesmo problema, e é culpa da SEFAZ de PE que não está retornando estas informações. O mais estranho é que só está acontecendo para clientes de MG...

Identificamos algumas correções necessárias na unit "ACBrEFDBloco_B_Class.pas" para geração do Bloco B: - Os campos de Valor do Registro B020 são obrigatórios (removido o True para permitir que venha null); - O segundo campo do Registro B440 (IND_OPER) deve ser preenchido com 0 ou 1, sem decimais (o manual está errado); - Ficou faltando o preenchimento do campo VL_SUB do Registro B470. Segue em anexo o arquivo para avaliação. ACBrEFDBloco_B_Class.pas

Sim, verificamos em todos os fontes do ACBr, o uso é exclusivo no DACTE.

Então, @Italo Jurisato Junior , pesquisando nos fontes do ACBr, as únicas units que fazem referência a esta função são estas: Fontes\ACBrDFe\ACBrCTe\DACTE\Fast\ACBrCTeDACTEFR.pas Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes\ACBrCTeDACTeRLRetrato.pas Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes\ACBrCTeDACTeRLRetratoA5.pas Apesar de ser uma função genérica, ela não é usada no DANFE. Uma alternativa para isso seria transferir esta função para a unit pcteConversaoCTe.pas, específica do CT-e, o que acha? Se concordar, podemos realizar esta alteração.

Estamos enviando em anexo uma sugestão de mudança bem pequena, praticamente insignificante, mas que gerou transtorno para um dos nossos clientes. No manual do CT-e versão 3.00, página 165, foi removido o termo "anteriormente" da descrição da tag CST, dentro do grupo ICMS60. Obs: este procedimento CSTICMSToStrTagPosText é usado apenas nas impressões de DACTE. Segue em anexo a unit pcnConversao.pas com a modificação mencionada. pcnConversao.pas

@anderson.mendonca, este erro é apenas falta de atualização dos Schemas da NF-e. Basta atualizar para a última ("Esquemas XML NF-e - Pacote de Liberação No. 9 (Novo leiaute da NF-e, NT 2016.002 v.1.60 - b). Publicado em 02/07/2018"), disponível no site da SEFAZ.

Na versão 3.00 do CT-e, o campo nDoc do grupo idDocAntPap foi alterado para tipo Caractere de tamanho 30, porém no ACBr continua como inteiro. Segue a alteração para string de 30 para avaliação. ACBrCTeConhecimentos.pas ACBrCTeDACTEFR.pas pcteCTe.pas pcteCTeR.pas pcteCTeW.pas

Atualizamos recentemente o ACBr depois de ficar quase 2 meses sem fazer isso, e constatamos um problema semelhante ao que muitos aqui estão relatando nos últimos dias aqui no Fórum, erro 12175 na consulta do Status do WS. Nós sempre usamos WinINet, setado em design. Pelo que verificamos, o problema surgiu na revisão 15267 realizada pelo DOPI, onde foi corrigido um erro de access violation ao usar a propriedade TimeOutPorThread como True. Porém, esta alteração fez com que, no momento da criação do componente, a inicialização do TACBrWinINetReqResp nunca seja chamada, porque no constructor do TDFeHttpWinHttp, o ADFeSSL.SSLHttpLib ainda está como httpNone, caindo no create do TACBrWinHTTPReqResp. Uma solução é habilitar o TimeOutPorThread, porque isso faz com que a cada criação da Thread, a inicialização do TACBrWinINetReqResp seja chamada. Mas para quem ficar com o TimeOutPorThread = False e httpWinINet setado em design, enfrentará problemas. Como sugestão para resolver o problema, e mantendo a correção do access violation que o DOPI fez, sugerimos mudar a atribuição do FSSLHttpLib := ASSLHttpLib; para antes do case. Assim, no momento do Create, o httpWinINet já estará setado e fará a inicialização correta. Segue em anexo a unit ACBrDFeSSL.pas com a correção sugerida. @Daniel Simoes, poderia por favor dar uma verificada? ACBrDFeSSL.pas

Encontramos um erro na impressão da Guia da GNRE no campo "Período de Referência" em Fast Report. Está sendo impresso somente o código da referência, ex."0" sem constar a data. Pelo que foi verificado, a impressão em Fortes já está correta. Segue a correção para Fast. GNRE_GUIA.fr3 ACBrGNREGuiaFRDM.pas