Diego Foliene

Se não me engano, este curso é liberado para todos os usuários, não só os assinantes. Nele tem orientações e um exemplo prático de consumo da Lib. Curso: Introdução as Bibliotecas ACBrLib

Contextualizando. As configurações de SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType são comuns a todos as soluções de Documentos Fiscais Eletrônicos do ACBr. Aqui vamos considerar os exemplos nativos, mas essas configurações também se aplicam ao ACBrMonitorPLUS e ACBrLib. As configurações SSLLib, CryptLib, HttpLib e XMLSignLib costumam ficar na aba Certificado dos programas exemplo e podem ser definidas via código da seguinte maneira: ComponenteDFe.Configuracoes.Geral.SSLLib := libOpenSSL ou libWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.CryptLib := cryOpenSSL ou cryWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLHttpLib := httpOpenSSL ou httpWinHttp;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Se o certificado digital for A3 só vai ser possível usar as configurações do WinCrypt, por outro lado se for A1 poderá usar o WinCrypt ou OpenSSL. Recomendamos fortemente que o certificado seja A1. Desta forma podemos usar o OpenSSL e não precisamos nos preocupar com a versão Windows e suas atualizações. Além disso, o certificado não precisa ser instalado, pode ser lido de uma pasta onde esta salvo ou de um campo do banco de dados. Essas configurações influenciam comportamentos como protocolo de comunicação, assinatura, validação de schema, entre outros. Já a configuração SSLType costuma ficar na aba WebService dos programas exemplos e pode ser definida via fonte assim: ComponenteDFe.SSL.SSLType := LT_TLSv1_2; Como o nome sugere, essa configuração influencia se vai qual protocolo TLS ou SSL será usado na comunicação. Porque você está atrasado. Além de não suportar 64 bits, a Microsoft condenou a CAPICOM como obsoleta desde 2016. Então, se você ainda usa configuração de Capicom está usando algo defasado, aberto a erros e com brechas de segurança. A MsXML foi descontinuada pela Microsoft em 2014 e atualmente é considerada obsoleta. Usar essa configuração para assinatura ou validação significa usar algo ultrapassado, que não sofre manutenção e com maior propensão a erros. Se você vai usar certificado A3, não deve em hipótese alguma usar MsXML, sob risco de inutilizar a chave privada do certificado digital. Praticamente todos os DFes atuais estabeleceram que deve ser usado TLS1.2 na comunicação. Por isso, foi atualizado nos fontes para que os DFes usem como padrão TLS1.2 ao invés de LT_all. Se você mesmo assim ainda usa essa configuração, o componente vai usar o primeiro protocolo disponível e não o mais indicado. O que eu uso então? As configurações recomendadas por tipo de certificado podem ser encontradas neste tópico: Caso prefira, também pode acompanhar este vídeo com orientações e demonstração prática: Mais informações. Veja mais detalhes sobre como o ACBr deu Bye Bye para a Capicom neste tópico: No tópico abaixo foi relatado o problema com MsXML e perda da chave privada de certificados A3:

Boa tarde. A princípio a informação do Log demonstra que o processo ocorreu sem erros. Verificando nos fontes não há nada que indique uma tratativa diferente para o evento de cancelamento dos demais. No entanto, é estranho o comportamento de a Lib querer salvar o XML de evento de cancelamento mesmo quando ocorre rejeição. Eu fiz um teste usando o componente nativo, que é a base da Lib e também com o demo para C#, em ambos os casos recebendo uma rejeição de propósito. Em nenhum dos casos foi salvo XML de evento. Dito isso, por favor: No seu log não mostra, então não tenho como afirmar, pode fazer alguns testes chamando o NFE_LimparLista e o NFe_LimparListaEventos? Dessa forma nos certificamos de que não existe outra NFe carregada que possa estar gerando esse comportamento estranho. Verifique as questões de permissão dessa pasta. Para usar o ACBrLib em Linux é preciso que o mesmo tenha um ambiente gráfico instalado*. Alguns membros costumam usar o xvfb para emular um.(Veja este linkpara orientações a respeito) *isso é uma dependência do gerador de relatórios utilizado, já estamos verificando uma maneira de resolver isso através de uma biblioteca para geração de PDF nativo, fique de olho em nossos vídeos semanais para mais informações.

Boa tarde. Primeiro de tudo, mais uma vez, muito obrigado pela contribuição. Sobre a alteração na ACBrNFSeXLerXml_ABRASFv2, não foi possível testar a leitura, pela falta de um XML válido, mas revi novamente sua contribuição nessa parte e a princípio não parece que vá causar grandes impactos. Quanto a alteração no nfse.xsd e na ACBrNFSeXGravarXml_ABRASFv2, apenas uma observação. Você mudou direto na unit base, para esse caso, o correto é alterar atribuir o valor na procedure Configuracao da unit do provedor. Fiz essa alteração, editei o schema e fiz um teste de emissão. Por não ter dados válidos, recebi rejeição, mas nada que indique erro de schema ou problema com a tag OutrasInformacoes. Contribuição enviada ao SVN nas Rev-28972 e Rev-28973. Por favor, atualize seus fontes, reinstale o ACBr para fazer novos testes e reporte qualquer problema.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-3807

Bom dia. Muito obrigado pela contribuição. Por favor, pode compartilhar o manual do banco que usou como base para essa modificação?

Certo, nesse caso, vamos aguardar mais um pouco, caso eles demorem para dar um parecer, envio a alterando apenas a URL de produção mesmo.

Bom dia. Muito obrigado pelo aviso e pela contribuição, foi criada a #TK-3805 para tratar dela. Por favor, não foi informado se a URL de homologação foi alterada?

Fora esse erro que é gerado pelo programa exemplo, e não deve ser considerado por agora, os outros foram devolvidos a você pelo WebService indicando que o RPS foi enviado com informações incorretas. Acredito que o curso de ação agora é conferir junto a prefeitura se as informações estão corretas e caso estejam porque recebeu essas rejeições.

Bom dia. O arquivo 14806-rec-soap.xml é o envelope de resposta, ou seja, neste caso ele é a resposta que o webservice devolveu para você. Conferindo no conteúdo do mesmo, não vi nada que indique erro. Você recebeu um Nr. de Protocolo nele. Por favor, esses são os arquivos certos? Se sim, qual é o erro?

Bom dia. Essa tarefa é para controle interno. Fique de olho neste tópico, qualquer novidade o será comentada aqui.

Bom dia. Foi enviado ao SVN na Rev-28961 alteração das URLs e do provedor para cidade de Farroupilha/RS. As nova URLs foram retiradas do manual também disponibilizado em nosso SVN na Rev-28960. Por favor, queira atualizar seus fontes, reinstalar o ACBr para poder realizar novos testes e reportar qualquer problema.

Muito obrigado por compartilhar a resolução do problema com o resto da comunidade. No entanto, recomendo que verifique se seus schemas estão atualizados conforme os que foram disponibilizados pelo e-Social e se este for o caso abra um chamado junto a eles para notificar do problema. Devemos ter cuidado ao alterar os schemas, pois ao fazer isso, estamos assumindo um risco por alterar a documentação fornecida pelo governo.

Criada a #TK-3802 para análise e parecer do consultor responsável.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde. Foi enviado ao SVN uma alteração visando sanar essa questão. Por favor, atualize seus fontes, reinstale o ACBr, siga o que é pedido no tópico abaixo para fazer novos testes e reporte qualquer problema.

Boa tarde. Como muitos sabem, a falta de padronização é uma questão que assola a Nota Fiscal de Serviço Eletrônica. Um exemplo disso é o provedor ISSGoiania que é utilizado pela prefeitura de Goiania/GO. Conforme explicado na documentação do provedor disponível aqui: Ou seja, a tag CodigoMunicipio no XML da NFSe para esse provedor vem com um código próprio. No que diz respeito ao envio. Para aqueles que utilizam o ACBrNFSeX (Componente, Lib, Monitor), é importante observar que a Prefeitura de Goiânia espera que a aplicação já informe esse código no campo CodigoMunicipio para sua utilização adequada. Portanto é importante se atentar a esta informação no momento de realizar o preenchimento para emissão da nota. No que diz respeito a leitura do retorno. Como o componente ACBrNFSeX espera receber na tag CodigoMunicipio um código IBGE, a função de conversão que busca o nome da cidade através do código, falha e por isso a informação do município fica em branco na impressão. Para resolver essa questão, foi criada na unit ISSGoiania.LerXML uma função que usa o arquivo disponibilizado pelo provedor para buscar a informação da cidade. (Disponibilizada na Rev-28957) Portanto, basta adicionar o arquivo CidadesISSGoiania.txt(o nome do arquivo deve ser este) dentro da pasta do seu executável para que a busca pelo nome da cidade passe a usar o arquivo e não fique mais em branco no impresso.

Tópico fechado por falta de retorno do usuário

Boa tarde. Fonte: https://www.gov.br/esocial/pt-br/noticias/prorrogada-a-entrada-em-producao-dos-eventos-de-processo-trabalhista-1

Boa tarde. Foi divulgado no dia 24/03/2023 a NT2023/002 tratando do detalhamento do evento de insucesso na entrega. Resumo da Nota Técnica. Esta Nota Técnica disponibiliza novos eventos de Insucesso da Entrega e seu cancelamento conforme disposto no Ajuste SINIEF 50/2022 de 09 de dezembro de 2022. IMPORTANTE: Os novos eventos serão disponibilizados somente para a versão 4.00 do CTe. Data para Implantação Implantação para Homologação: 05/2023. Implantação para Produção: 07/2023. Evento de Insucesso na Entrega do CTe. Evento EXCLUSIVO da Versão 4.00 do CTe Função: Evento para indicar o insucesso na entrega da carga pelo transportador. Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe. Modelo: CT-e de Transporte de Cargas (modelo 57) Código do Tipo de Evento: 110190 (Este evento exige CT-e autorizado). Schema XML: evIECTe_v9.99.xsd Final do processamento Se o evento de Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat = 135. Este evento futuramente será propagado nas notas fiscais eletrônicas relacionadas de forma automática. Evento de Cancelamento do Insucesso na Entrega do CTe. Evento EXCLUSIVO da Versão 4.00 do CTe Função: Evento para indicar o cancelamento de um evento de insucesso da entrega da carga pelo transportador nas ocasiões em que ocorrer erro na geração do evento. Autor do Evento: O autor do evento é o emissor do CT-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CT-e. Modelo: CT-e de Transporte de Cargas (modelo 57) Código do Tipo de Evento: 110181 (Este evento exige CT-e autorizado) Schema XML: evCancIECTe_v9.99.xsd Final do Processamento Se o evento de Cancelamento do Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat=135. Este evento futuramente será propagado nas notas fiscais eletrônicas informadas no evento Insucesso de Entrega cancelado. Alterações no ACBr. Visto que se trata da criação de um novo evento, será necessário realizar a implementação do mesmo nos fontes, disponibilizando tais alterações dentro do prazo estipulado pela NT. Consequentemente, nova versão do ACBrMonitorPLUS e da Lib deverão ser geradas. Essa e outras Notas Técnicas disponíveis AQUI. Você pode ler esta Nota Técnica na íntegra AQUI.

Boa tarde. Foi divulgado no dia 24/03/2023 a NT2023/001 tratando de alterações de regras de validação para CTe, CTeOS e GTVe. Resumo da Nota Técnica: Esta Nota Técnica promove ajustes nas regras de validação do CTe, CTeOS e GTVe visando adequar o sistema à legislação aprovada no AJUSTE SINIEF. Data para Implantação: Implantação Homologação: 04/2023 Implantação Produção: 06/2023 Sobre as alterações: Eliminação da Denegação Interestadual As hipóteses da Denegação no processo de autorização dos documentos deixam de existir. A validação do CTe poderá resultar em: Rejeição – o CTe será descartado, não sendo armazenada no Banco de Dados podendo ser corrigido e novamente transmitido; Autorização de uso – o CTe será armazenado no Banco de Dados; Regras de Validação de CTe, CTeOS e GTVe No geral, a redação da NT remove das regras G036, G068, G074, G096 e N064 a palavra denegado. Além disso, adiciona a seguinte observação na regra G110: E também remove as regras abaixo: Regras de Validação G133, N089 e Q026: cStat - 301/ cStat - 205. Emitente em situação irregular perante o Fisco (tratar duplicidade na inserção do CT-e, evitando a inserção de mais de um CT-e denegado). Uso Denegado: Irregularidade fiscal do emitente. Regra de Validação G183 e N106: cStat - 205. - Verificar se CT-e está denegado Retornar Protocolo e data de denegação. [nProt:999999999999999][dhDeneg: AAAA-MMDDTHH:MM:SS TZD]. Rejeição: CT-e está denegado na base de dados da SEFAZ. Eliminar o Serviço de Inutilização O Webservice de Inutilização deixa de existir nas datas de implantação desta NT conforme o ambiente. O acesso ao Serviço será bloqueado pela SEFAZ Autorizadora, podendo retornar um erro http 404 (Not found) ou a rejeição 998 – Serviço Desativado. Revogação dos Eventos de Marcação Os seguintes eventos de marcação deixam de ser gerados pelas SEFAZ Autorizadoras: 440130| 57| Autorizado Redespacho 440140| 57| Autorizado Redespacho intermediário 440150| 57| Autorizado Subcontratação 240150| 57 e 67| CTe de Anulação CTe de Anulação e Substituição na Versão 3.00 O CTe com tipo anulação e substituição deixam de existir na versão 3.00. A nova sistemática de substituição passa a ser possível apenas na versão 4.00. As seguintes Regras de Validação devem ser executadas no início das validações de CTe, CTeOS e GTVe: Se Tipo do CT-e= 2 (Anulação) ou 3 (Substituição), rejeitar o CTe cStat - 990: Rej. Rejeição: Vedado a utilização do CTe de anulação ou substituição na versão 3.00 O grupo de dado do CTe de substituição não pode ser informado (grupo: infCteSub) cStat - 991: Rej. Rejeição: Dados do CTe de substituição não são permitidos na versão 3.00 Todas as regras de validação associadas aos CTe de anulação e substituição perdem o sentido porque o ambiente de autorização não passará por elas. Revogação do Evento de Informações da GTV no CTeOS e suas implicações Revoga-se o evento de Informações da GTV (em papel) no CTeOS de Transporte de valores para as versões 3.00 e 4.00. Tipo de evento revogado: 110170. Em relação as Regras de Validação do CTeOS as seguintes alterações serão aplicadas a versão 3.00 (até sua total desativação) e na versão 4.00: Regra de Validação Revogada Se tipo de serviço = Transporte de Valores - Verificar se existe CTe OS autorizado há mais de 45 dias para o mesmo CNPJ do emitente sem que exista pelo menos um evento de Informações da GTV vinculado Observação: Retornar a chave de acesso do CTe OS mais antigo que causou o bloqueio Observação 2: Essa validação não deve ser aplicada no ambiente de homologação. Observação 3: A validação não deve ser aplicada a CTe OS de transporte de valores que relacionam GTVe. Rejeição: Existe CTe OS de Transporte de Valores autorizado há mais de 45 dias sem informar as GTV [chCTe: 99999999999999999999999999999999999999999 999]. Nova Regra de Validação para Transporte de Valores H045a: cStat - 927. Se tipo de serviço for igual a Transporte de Valores - O grupo de informações infGTVe DEVE estar informado. Rejeição: Informações da GTVe devem ser preenchidas para CTe OS de transporte de valores. Retificação de informação do MOC 4.00 O valor de preenchimento da tag CST do grupo ICMSSN deve ser conforme está no schema da versão 4.00 com o valor 90 – Simples Nacional e não 01 – Simples Nacional como saiu no MOC. A tag correta deverá aceitar apenas o valor 90 – Simples Nacional. Modificações no ACBr. De maneira bem resumida, a Nota Técnica discorre sobre algumas regras de validação e o fim do evento de inutilização. Por isso, modificações no ACBr não se fazem necessárias. Dito isso será preciso que validem em suas aplicações para remover a possibilidade de enviar este evento. Esta e outras Notas Técnicas disponíveis AQUI. Você pode ler esta Nota Técnica na íntegra AQUI.

Boa tarde. Em 29/03/2023, foi publicada a versão 10.1.2 do programa validador do SPED ECD - Escrituração Contábil Digital, trazendo as seguintes mudanças: Fonte: http://sped.rfb.gov.br/pagina/show/7190

Boa tarde. Primeiro de tudo, muito obrigado pela contribuição! Toda colaboração é e sempre será mais do que bem vinda! Em sua contribuição, você adiciona uma função que faz o seguinte: Se conferirmos na unit ACBrNFSeXGravarXml_ABRASFv1(classe base para a BHISS.GravarXml), é possível observar que ela insere no XML a Razão Social assim: Result.AppendChild(AddNode(tcStr, '#38', 'RazaoSocial', 1, 115, 0, NFSe.Tomador.RazaoSocial, DSC_XNOME)); Conferindo dentro da estrutura de AddNode temos o seguinte trecho: // Grava a tag no arquivo - Quando existir algum conteúdo if ((ocorrencias = 1) or (not EstaVazio)) then begin Result := CreateElement(Tag); if ParseTextoXML then Result.Content := FiltrarTextoXML(FOpcoes.RetirarEspacos, ConteudoProcessado, FOpcoes.RetirarAcentos, True, FOpcoes.FQuebraLinha) else Result.Content := ConteudoProcessado; if (Atributo <> '') and (Result <> nil) then begin AttSplit := Split('=', Atributo); Result.SetAttribute(Trim(AttSplit[0]), Trim(AttSplit[1])); end; end; Pela forma com é feita a chamada da AddNode, o parâmetro ParseTextoXML é igual a True, então ele vai passar pela function FiltrarTextoXML. Dentro dela, temos o seguinte: function FiltrarTextoXML(const RetirarEspacos: boolean; aTexto: String; RetirarAcentos: boolean; SubstituirQuebrasLinha: Boolean; const QuebraLinha: String): String; begin if RetirarAcentos then aTexto := TiraAcentos(aTexto); aTexto := ParseText(AnsiString(aTexto), False ); if RetirarEspacos then begin while pos(' ', aTexto) > 0 do aTexto := FaststringReplace(aTexto, ' ', ' ', [rfReplaceAll]); end; if SubstituirQuebrasLinha then aTexto := ChangeLineBreak( aTexto, QuebraLinha); Result := Trim(aTexto); end; Conferindo o conteúdo da ParseText, a mesma já faz a substituição. if Decode then begin Astr := DecodeToString( Texto, IsUTF8 ) ; Astr := InternalStringReplace(AStr, '&amp;' , '&'); AStr := InternalStringReplace(AStr, '&lt;' , '<'); AStr := InternalStringReplace(AStr, '&gt;' , '>'); AStr := InternalStringReplace(AStr, '&quot;' , '"'); AStr := InternalStringReplace(AStr, '&#39;' , #39); AStr := InternalStringReplace(AStr, '&#45;' , '-'); AStr := InternalStringReplace(AStr, '&aacute;', 'á'); AStr := InternalStringReplace(AStr, '&Aacute;', 'Á'); AStr := InternalStringReplace(AStr, '&acirc;' , 'â'); AStr := InternalStringReplace(AStr, '&Acirc;' , 'Â'); AStr := InternalStringReplace(AStr, '&atilde;', 'ã'); AStr := InternalStringReplace(AStr, '&Atilde;', 'Ã'); AStr := InternalStringReplace(AStr, '&agrave;', 'à'); AStr := InternalStringReplace(AStr, '&Agrave;', 'À'); AStr := InternalStringReplace(AStr, '&eacute;', 'é'); AStr := InternalStringReplace(AStr, '&Eacute;', 'É'); AStr := InternalStringReplace(AStr, '&ecirc;' , 'ê'); AStr := InternalStringReplace(AStr, '&Ecirc;' , 'Ê'); AStr := InternalStringReplace(AStr, '&iacute;', 'í'); AStr := InternalStringReplace(AStr, '&Iacute;', 'Í'); AStr := InternalStringReplace(AStr, '&oacute;', 'ó'); AStr := InternalStringReplace(AStr, '&Oacute;', 'Ó'); AStr := InternalStringReplace(AStr, '&otilde;', 'õ'); AStr := InternalStringReplace(AStr, '&Otilde;', 'Õ'); AStr := InternalStringReplace(AStr, '&ocirc;' , 'ô'); AStr := InternalStringReplace(AStr, '&Ocirc;' , 'Ô'); AStr := InternalStringReplace(AStr, '&uacute;', 'ú'); AStr := InternalStringReplace(AStr, '&Uacute;', 'Ú'); AStr := InternalStringReplace(AStr, '&uuml;' , 'ü'); AStr := InternalStringReplace(AStr, '&Uuml;' , 'Ü'); AStr := InternalStringReplace(AStr, '&ccedil;', 'ç'); AStr := InternalStringReplace(AStr, '&Ccedil;', 'Ç'); AStr := InternalStringReplace(AStr, '&apos;' , ''''); end else begin AStr := string(Texto); AStr := StringReplace(AStr, '&', '&amp;' , [rfReplaceAll]); //Aqui ele substitui o "e" comercial; AStr := StringReplace(AStr, '<', '&lt;' , [rfReplaceAll]); AStr := StringReplace(AStr, '>', '&gt;' , [rfReplaceAll]); AStr := StringReplace(AStr, '"', '&quot;', [rfReplaceAll]); AStr := StringReplace(AStr, #39, '&#39;' , [rfReplaceAll]); AStr := StringReplace(AStr, '''','&apos;', [rfReplaceAll]); end; Result := AStr; Por favor, isso não está ocorrendo? É possível fazer um teste? Se abrir o XML gerado no navegador e também em um editor de texto como o bloco de notas ou notepad++ ele ainda tem o & ?

Bom dia. Que bom que deu certo! Por favor, para ajudar outros que possam vir a ter o mesmo problema futuramente, pode compartilhar qual foi a solução?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.