Sófolha

De acordo com a Nota Técnica 2023.001 (Tributação Monofásica sobre Combustíveis) a regra de validação LA03d foi excluída (Obrigatória a informação do campo vPart (id: LA03d) para produto "210203001 – GLP" (tag:cProdANP) (NT 2016.002)), mas no ACBr continua sendo feita a validação. Segue em anexo o arquivo (ACBrNFeNotasFiscais.pas) com a correção. ACBrNFeNotasFiscais.pas

Boa tarde! @Juliomar Marchetti, o código foi corrigido parcialmente. Por favor, observe a estrutura do tipo "TAltContratual" na imagem abaixo, focando nas propriedades "Vinculo" e "infoRegimeTrab". Agora, compare com a imagem subsequente, onde a classe "Vinculo" também contém a propriedade "infoRegimeTrab". Ambas estão referenciando a mesma classe "TInfoRegimeTrab". Na última versão do método "gerarAltContratual" (veja a imagem abaixo), nas linhas 310, 312, 313 e 314, o sistema acessa as propriedades do atributo "objAltContratual.Vinculo.infoRegimeTrab", enquanto na linha 318, utiliza as propriedades de "objAltContratual.infoRegimeTrab". Além disso, na função "function TEvtAltContratual.LerArqIni(const AIniString: String): Boolean;", todos os valores são atribuídos à propriedade "InfoRegimeTrab" do objeto. As alterações sugeridas por @Andergoncalves padronizaram o acesso à propriedade "objAltContratual.Vinculo", incluindo a modificação na função "TEvtAltContratual.LerArqIni". Resumindo, parte do código utiliza "objAltContratual.Vinculo.infoRegimeTrab." e outra parte utiliza "objAltContratual.infoRegimeTrab.". Acredito que seguir a sugestão do @Andergoncalves, conforme também é feito no S-2200 com a estrutura "vinculo.InfoRegimeTrab", seria mais adequado. Atenciosamente,

Bom dia. Houve problema na publicação do post estamos enviando o anexo com a sugestão de alteração. Obrigado pcesS1280.pas

Bom dia. Estamos enviando uma sugestão de melhoria na geração do evento S-1280 onde percebemos que sofreu alteração no tópico: Segundo o leiaute do eSocial a regra é que esta tag tem obrigatoriedade quando a Classificação Tributária for igual a 3, independentemente se houver valor a ser informado. No caso de nosso cliente ele tem uma empresa com a Classificação Tributária 3, enquadrada na lei 12.546 (Desoneração da Folha de Pagamento) e sem faturamento. Ocasionado um erro ao processar o envido do Evento no Mês subsequente conforme imagem abaixo: Portanto, tive que voltar o código para como era anteriormente: Além deste caso nos deparamos com algumas refatorações que impactaram em nossa aplicação. Estas refatorações e "limpezas" de código são muito bem-vindas, compreendemos a importância deste trabalho. Apenas gostaríamos de sugerir, que caso seja for possível, haja um canal onde pudéssemos receber alertas de alterações que impactam na compatibilidade da versão atual em relação às versões anteriores, para que assim possamos analisá-las e nos adaptarmos de uma forma melhor. Atualmente o ACBR recebe muitas alterações por dia, o que é muito interessante e agradecemos a ajuda de todos. Porém, devido à grande demanda de requisitos nos sistemas de folha de pagamento decorrentes das alterações e evoluções do eSocial, para abarcar o Imposto de Renda e o FGTS, torna-se dificultoso acompanhar estes tipos de alterações apenas pelos logs do Subversion. Segue alguns outros exemplos com os quais nos deparamos: 01/03/2024 Revion 32724 -- ACBrUtil.XMLHTML -- [*] Alteração no ParseText pois o mesmo ao receber um XML no formato UTF-8 estava devolvendo-o no formato ANSI de forma indevida. por: DSA Outra alteração que ocasionou erro foi a função GerarChaveEsocial que foi retirada a referência da unit pcnAuxiliar que usava a função IntToStrZero pegando os 5 números a partir da direita. Isto vai ocasionar um problema para quem tenha um gerador com mais de 5 casas. Hoje com esta alteração esta pegando a partir da esquerda ocorrendo o erro abaixo: Unit : pcesGerador Função: TeSocialEvento.GerarChaveEsocial Antes: Fizemos uma sugestão de alteração neste tópico devido a este problema: Depois da refatoração: No caso o colaborador do ACBR fez o alerta para alterarmos a nossa aplicação, caso houvesse alguma mudança futura, e reconhecemos que não seguimos a orientação quando nos foi sugerida. Porém, se houvesse um canal específico onde pudéssemos nos informar sobre alterações deste tipo, teria nos ajudado bastante. Agradecemos por todo o trabalho que está sendo realizado pela equipe do ACBR. pcesS1280.pas

Bom dia. Estamos enviando uma sugestão de melhoria na geração do evento S-1280 onde percebemos que sofreu alteração no tópico: Segundo o leiaute do eSocial a regra é que esta tag tem obrigatoriedade quando a Classificação Tributária for igual a 3, independentemente se houver valor a ser informado. No caso de nosso cliente ele tem uma empresa com a Classificação Tributária 3, enquadrada na lei 12.546 (Desoneração da Folha de Pagamento) e sem faturamento. Ocasionado um erro ao processar o envido do Evento no Mês subsequente conforme imagem abaixo: Portanto, tive que voltar o código para como era anteriormente: Além deste caso nos deparamos com algumas refatorações que impactaram em nossa aplicação. Estas refatorações e "limpezas" de código são muito bem-vindas, compreendemos a importância deste trabalho. Apenas gostaríamos de sugerir, que caso seja for possível, haja um canal onde pudéssemos receber alertas de alterações que impactam na compatibilidade da versão atual em relação às versões anteriores, para que assim possamos analisá-las e nos adaptarmos de uma forma melhor. Atualmente o ACBR recebe muitas alterações por dia, o que é muito interessante e agradecemos a ajuda de todos. Porém, devido à grande demanda de requisitos nos sistemas de folha de pagamento decorrentes das alterações e evoluções do eSocial, para abarcar o Imposto de Renda e o FGTS, torna-se dificultoso acompanhar estes tipos de alterações apenas pelos logs do Subversion. Segue alguns outros exemplos com os quais nos deparamos: 01/03/2024 Revion 32724 -- ACBrUtil.XMLHTML -- [*] Alteração no ParseText pois o mesmo ao receber um XML no formato UTF-8 estava devolvendo-o no formato ANSI de forma indevida. por: DSA Outra alteração que ocasionou erro foi a função GerarChaveEsocial que foi retirada a referência da unit pcnAuxiliar que usava a função IntToStrZero pegando os 5 números a partir da direita. Isto vai ocasionar um problema para quem tenha um gerador com mais de 5 casas. Hoje com esta alteração esta pegando a partir da esquerda ocorrendo o erro abaixo: Unit : pcesGerador Função: TeSocialEvento.GerarChaveEsocial Antes: Fizemos uma sugestão de alteração neste tópico devido a este problema: Depois da refatoração: No caso o colaborador do ACBR fez o alerta para alterarmos a nossa aplicação, caso houvesse alguma mudança futura, e reconhecemos que não seguimos a orientação quando nos foi sugerida. Porém, se houvesse um canal específico onde pudéssemos nos informar sobre alterações deste tipo, teria nos ajudado bastante. Agradecemos por todo o trabalho que está sendo realizado pela equipe do ACBR.

Bom dia, Realizamos um levantamento entre nossos clientes que relataram esses erros e identificamos que eles estão usando diversas Autoridades Certificadoras diferentes. Alguns exemplos incluem Link RDB V2, Certisign RFB G5, Certifica Minas v5 e Soluti Multipla v5, Safeweb RFB v5. Além disso, é importante destacar que esses certificados são os mesmos usados para transmitir eventos no eSocial. Essas informações nos levam a descartar a hipótese de que o problema esteja relacionado aos certificados ou à sua instalação. Para reforçar nossa posição, foi publicada ontem uma mensagem no portal Sped. Ela informa que a revisão do conjunto de protocolos TLS na EFD-Reinf, que originalmente estava programada para 21/10/2023 e implicava na desativação do uso de TLS 1.0 e TLS 1.1, foi adiada para janeiro de 2024. A data exata ainda será divulgada. Provavelmente, ainda estão ajustando os servidores para recepcionar as informações com esse nível de criptografia. Adiamento da revisão do conjunto aceito de TLS na EFD-Reinf (rfb.gov.br) At.te,

Ok, obrigado!

É outro tipo de boleto É utilizado para o recebimento de valores relativos à prestação de serviços (água, luz, etc), impostos, taxas e contribuições, a api para a geração dessa modalidade é diferente do boleto de cobrança https://api.hm.bb.com.br/pix-bb/v1/swagger?gw-app-key=b82315c0c31e0135776b005056891bef

Vocês pretendem desenvolver/atualizar o componente para a geração do PIX dinâmico para boleto de arrecadação do Banco do Brasil? Documentação: https://apoio.developers.bb.com.br/referency/post/6023ef68d1c0df0012c3ed1a Se já estiver disponível essa modalidade por favor peço orientação para o desenvolvimento, pois não consegui encontrar nenhuma menção a esse tipo de cobrança End Point: /arrecadacao-qrcodes