Diego Foliene

Bom dia. De acordo com o fonte da ACBrSATExtratoFortesFr.pas, é preciso definir a propriedade ImprimeEmUmaLinha como True para que mostre a infAdProd por item.

Bom dia. Não temos um componente que atenda ao padrão de 2 a 5 intercalado que é o utilizado pelas concessionárias de água e energia. Toda e qualquer contribuição na criação de tal componente é e sempre será mais do que bem vinda.

Bom dia @Robson_Renan. O arquivo 1-rec-soap.xml é o envelope de resposta, ou seja, ele é a resposta que foi devolvida para você pelo webservice inalterada pelo ACBr. Se abrirmos esse arquivo, é possível observar no conteúdo dele veio algo fora do padrão e não previsto pelo ACBr, por isso, o componente não conseguiu ler corretamente e apresentou este erro. Seu problema é com a outra cidade e outro provedor. Por favor, para não misturarmos as situações, peço que crie um novo tópico. Anexe nele esses arquivos e como você comentou que no antigo funciona normal, peço que anexe nele os envelopes gerados pelo componente antigo também.

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

Boa tarde. Por volta das 12:30 do dia 05/04/2023 membros da nossa comunidade do Discord começaram a relatar no canal #sefaz erro ao Inutlizar NFe na Sefaz MT. A ocorrência comum para todos era receber a rejeição 999 - Erro não catalogado. Em geral, esse tipo de rejeição é um falha não prevista nas validações da Sefaz, e quando é recebida, o curso de ação a ser tomado é entrar em contato com a Sefaz. O membro de nossa comunidade @erlamcastanho compartilhou essa resposta que conseguiu ao abrir um chamado junto a Sefaz evidenciando que eles de fato estão com problema:

Mais uma vez, muito obrigado pela sua contribuição. Toda e qualquer colaboração sempre será mais do que bem vinda. Sobre a questão da propriedade CodigoVan, conferi em alguns no manual de alguns outros bancos além desse próprio da Caixa Econômica. No geral, ou envia como zeros, ou não tem a informação, então a princípio a propriedade acabaria não sendo usada e por isso optei por não aderir. No entanto, a alteração em como era gerado as últimas 29 posições no meu entendimento está correta e por isso foi enviada ao SVN na Rev-29014 . Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde. Sobre a sua alteração na PagFor.Caixa.GravarTxtRemessa, você adicionou a propriedade CodigoVAN, mas no manual que disponibilizou, diz para preencher essa propriedade com zeros. Por favor, qual foi o motivo para ter adicionado essa propriedade?

Boa tarde. Por fugir do escopo do ACBrPRO, movi sua dúvida para um local adequado. Nesta área da comunidade, mais usuários vão poder interagir no tópico e sugerir uma solução. Para ajudar, por favor, forneça mais detalhes do seu problema e contexto. Em uma primeira leitura e sem mais informações, usar Gesture com Desktop não me parece fazer muito sentido.

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

Bom dia. No dia 03/04/2023 foi divulgada a versão 1.11 desta Nota Técnica, cujo resumo de alterações informa: Ou seja, a nova versão altera a data de produção para a implementação das novas regras de validação. Ambiente de Homologação: - Ambiente de Produção: 01/05/2023

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?

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.

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.

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

A rotina lê a ocorrência que vem no respectivo segmento no arquivo.

Boa tarde. Fiz um teste com o programa exemplo e tag não foi gerada no XML. Se conferirmos a procedure GerarXML na unit pcesS1210 a mesma está assim: function TEvtPgtos.GerarXML: Boolean; begin try inherited GerarXML; Self.VersaoDF := TACBreSocial(FACBreSocial).Configuracoes.Geral.VersaoDF; Self.Id := GerarChaveEsocial(now, self.ideEmpregador.NrInsc, self.Sequencial); GerarCabecalho('evtPgtos'); Gerador.wGrupo('evtPgtos Id="' + Self.Id + '"'); if VersaoDF <= ve02_05_00 then GerarIdeEvento3(Self.ideEvento, True, True, False) else GerarIdeEvento3(Self.ideEvento, True, False, True); //Se você configurou corretamente o ACBreSocial, é nesse momento que ele gera o grupo ideEvento GerarIdeEmpregador(Self.ideEmpregador); GerarIdeBenef(Self.ideBenef); Gerador.wGrupo('/evtPgtos'); GerarRodape; FXML := Gerador.ArquivoFormatoXML; // XML := Assinar(Gerador.ArquivoFormatoXML, 'evtPgtos'); // Validar(schevtPgtos); except on e:exception do raise Exception.Create('ID: ' + Self.Id + sLineBreak + ' ' + e.Message); end; Result := (Gerador.ArquivoFormatoXML <> '') end; Repare que ele faz a chamada a procedure GerarIdeEnvento3 da seguinte maneira. GerarIdeEvento3(Self.ideEvento, True, False, True); Agora vamos conferir como é a procedure GerarIdeEvento3: procedure TeSocialEvento.GerarIdeEvento3(pEvt: TIdeEvento3; GeraIndRetif: Boolean=True; GeraIndApuracao: Boolean=True; GeraIndGuia: Boolean=True); begin Gerador.wGrupo('ideEvento'); GerarIdeEvento2(pEvt, false, GeraIndRetif, false); if (GeraIndApuracao) then Gerador.wCampo(tcStr, '', 'indApuracao', 1, 1, 1, eSIndApuracaoToStr(pEvt.IndApuracao)); Gerador.wCampo(tcStr, '', 'perApur', 7, 7, 1, pEvt.perApur); if (GeraIndGuia) and (VersaoDF >= veS01_00_00) and (pEvt.indGuia <> '') then Gerador.wCampo(tcStr, '', 'indGuia', 1, 1, 0, pEvt.indGuia); GerarIdeEvento(pEvt, false); Gerador.wGrupo('/ideEvento'); end; Repare que o parâmetro GerarIndApuracao é passado como False na chamada e por isso não é gerado. Se seus fontes estiverem diferente disso eles estão desatualizados. Importante lembrar que não basta apenas fazer o update no SVN para atualizar, é preciso reinstalar o ACBr rodando o instalador, de preferência marcando a opção "Apagar Arquivos Antigos".

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