bsoft

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

Favor validar novamente. ACBrUtil.pas

Emitir um CT-e com observação contento aspas. Ex.: Observação no conhecimento "de" número 99999 No DACTe será impresso conforme o print abaixo. O mesmo também vai acontecer na DANFE para as informações complementares.

Foi feita uma alteração na geração da chave de acesso ao gerar o XML da NF-e (autoria do @Italo Jurisato Junior na revisão 14691), que causa erro na geração de chave de NF-e Avulsa, na qual o CNPJ informado na chave de acesso é diferente do CPF/CNPJ do emitente. Segue o arquivo com a reversão do trecho de código em questão. pcnNFeW.pas

Tivemos problemas na impressão da observação no DACTe devido à função AddDelimitedTextToList que é usada pela Split. Foram colocadas aspas para resolver o problema de quebrar nos espaços em branco, porém isso dá erro caso haja aspas na observação preenchida pelo cliente. Segue a proposta para correção, foi alterado somente a parte para Delphi que não tem suporte à propriedade StrictDelimiter do StringList. Testado no Delphi 10.1 e no Delphi 7. ACBrUtil.pas

Estamos enviando alterações na unit "ACBrEPCBloco_C_Class.pas" para que os campos VL_BC_IPI, ALIQ_IPI, VL_IPI do Registro C170 não sejam preenchidos na geração do arquivo quando não houver valores de IPI , ao invés de preencher com "0,00" como é feito hoje. Segundo o Guia Prático, esses campos não são obrigatórios. Segue para avaliação. ACBrEPCBloco_C_Class.pas

@MarceloPeron, também recebemos esta mensagem da SEFAZ do MS, e pelos nossos primeiros testes, é necessário setar a propriedade SSLType com o valor LT_TLSv1_2. uses blcksock; ... ACBrCTe.SSL.SSLType := LT_TLSv1_2; Com nenhuma outra opção desta propriedade funcionou a comunicação com o ambiente de Homologação de CT-e do Estado do MS. Hoje esta propriedade é definida por padrão como LT_all, isso provavelmente terá que ser alterado para LT_TLSv1_2, só não conseguimos testar/confirmar o impacto desta alteração antes dessa mudança definitiva da SEFAZ.

@elisangela carla, o problema é o código errado do tpEmis, note que no teu XML você informou 7 ao invés de 8. O correto para a emissão em contingência para o Estado de Santa Catarina (cUF = 42) é 8, deve ser enviado para o SVC-SP. Essa relação está disponível na Nota Técnica 2012.003 (ao invés de colocarem esta informação no manual 3.0.... praticidade é com a SEFAZ ) @darlananogueira, as tags dhCont e xJust só são necessárias na emissão em contingência offline FS-DA (tpEmis = 5), conforme as rejeições 586 e 587.

@Bruno_Takano e @Italo Jurisato Junior, o motivo dessa rejeição é uma atualização da Nota Técnica 2017.003, versão 1.03. Dentre as diversas mudanças, o último item do bloco 6 é: Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição)e informado indicador de CT-e Globalizado (indGlobalizado) e Tomador do Serviço for Remetente: - A quantidade de NF-e relacionadas deve ser superior ou igual a 5 E apesar de estar indicado como Facultativo, confirmamos que além de SP, esta regra também está ativa nas emissões pro RJ.