Diego Foliene

SSLType fica na aba Webservice do programa exemplo.

Coloque as Dlls da deste link: https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x86 E as Dlls deste link: https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/XMLSec Na pasta em que está o executável e depois faça um novo teste por favor.

Bom dia! Infelizmente, uma das características comuns para a nota de serviço é a de que "não tem padrão". A ABRASF sugeriu um padrão e layout a ser seguido pelos provedores, mas tem muitos que usam layout próprio e até mesmo aqueles que seguem o padrão ABRASF tem suas customizações. Então, mesmo que a ABRASF tenha uma lista de métodos que devem ser implementados, nada garante que os provedores que seguem seu layout implementam todos os métodos. Foi isso o que aconteceu no seu caso, você tentou usar o método GerarNFSe que envia um único RPS, mas o provedor não tem esse método implementado. Por isso o componente levantou essa exceção para você. Use o botão Emitir(Novo) do programa exemplo, ele vai escolher automaticamente o método que deve ser usado para o provedor.

Foi criada a #TK-3763 para análise do caso e parecer dos consultores responsáveis.

Certifique-se que o windows está com as atualizações em dia. Se o certificado for A1, você pode usar OpenSSL.

Bom dia! Que eu me recordo, você é o primeiro relato nesse sentido. Por favor, você está usando componente, monitor ou Lib? Como é o log gerado? No arquivo de retorno não vem a informação? É possível marcar a opção para salvar os envelopes de envio e retorno para verificar se de fato não está devolvendo o protocolo?

A contribuição foi enviada ao SVN na Rev-28892. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

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

Recomendo que abra um chamado junto ao e-Social para verificar porque você está recebendo este retorno.

Por favor, para testar a alteração na ACBrNFSeLerXml_ABRASFv2.pas é possível compartilhar um arquivo XML que tenha esses caracteres? Se possível, encaminhe também o arquivo de envelope. Para que ele seja gerado, marque a opção "Salvar Envelope Soap" da aba WebService no programa exemplo. Os arquivos tem um -soap no nome. Se tiver dados sensíveis, por favor, siga as orientações deste tópico

Boa tarde. Também obtive este retorno ao testar com o programa exemplo(note que ele está pegando a nova URL). Por favor, é possível confirmar com o provedor se há instabilidade? Por gentileza, é possível testar por outros programas de requisição, como o SoapUI, por exemplo?

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Bom dia. Pela URL de homologação disponibiliza, parece que o provedor utilizado é o WebISS na versão 2.02. Este provedor já foi implementado no componente, veja um exemplo de configuração de outra cidade(note que a URL de homologação é a mesma que passou): Precisamos da URL de produção.

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

Alteração enviada ao SVN na Rev-28859. Por favor, queria atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia. A alteração foi enviada ao SVN na Rev-28858. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia. Por favor, como fica o log no componente do ACBrNFSeX?

Bom dia. Sugiro entrar em contato com o provedor e questionar por que está recebendo este retorno. O arquivo montado pelo componente coincide com o schema que temos disponível para o provedor.

Bom dia. Muito obrigado por reportar, foi criada a #TK-3757 para análise do caso e parecer dos consultores.

Isso explica os problemas que estava tendo, a cidade trocou de provedor. Como não temos como testar a emissão para todas as cidades por falta de dados válidos, nesses casos, nós realmente dependemos de contribuição por parte dos usuários para manter o componente atualizado. Muito obrigado pela contribuição, foi criada a #TK-3756 para análise e inclusão no SVN.

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

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

Boa tarde. Contribuição enviada ao SVN na Rev-28885. Por favor, atualize seus fontes, reinstale o ACBr para realizar novos testes e reporte qualquer problema.

Boa tarde. Recebemos os arquivos de envelope do EnvioLoteRPSSincrono e EnvioLoteRPSSincronoResponse. Mas você comentou que o problema ocorre no momento da consulta, não foi gerado arquivos de envelope(-soap) para esse processo? Se foram, é possível encaminhar eles por e-mail?

Conforme programação prévia, no dia 19/03/2023, ocorrerá o fim do período de convivência das versões S-1.0 e S-1.1 do leiaute do eSocial. A partir do dia 20/03, todos os empregadores deverão adotar a versão mais recente do leiaute, que já está disponível desde 16/01/2023. A versão anterior, S-1.0, será desativada e não poderá mais ser utilizada para o envio das informações. Os empregadores que ainda não atualizaram seu sistema para a nova versão do leiaute do eSocial devem fazê-lo o mais breve possível, para evitar problemas com o envio das informações. Fonte: Fim da convivência das versões do leiaute do eSocial E como fica o ACBr? O componente ACBreSocial e consequentemente o ACBrMonitor e a Lib já estão com as alterações para funcionar com essa nova versão de acordo com os manuais e informações disponibilizadas. Para utilizar é preciso configurar a propriedade VersaoDF como segue: ACBreSocial.Configuracoes.Geral.VersaoDF := veS01_01_00; No ACBrMonitor: Usando ACBrLibeSocial: Utilize o método eSocial_SetVersaoDF passando no parâmetro sVersao a string "S01_01_00"

Boa tarde. No dia 23/03/2023, foi divulgada a Nota Técnica 2023/001 para MDFe. Resumo da NT. Esta Nota Técnica modifica a regra de validação do evento de encerramento do MDFe para permitir que filiais possam encerrar os MDFe mesmo que em situação cadastral diferente de ativo no CCC. O serviço de eventos já garante que o autor e o CNPJ do certificado de transmissão sejam do mesmo CNPJ base, portanto, impedir que um MDFe seja encerrado por filiais que deixaram de operar gera apenas dificuldade operacional e necessidade de atendimento especializado do fisco para resolver o problema de forma manual. A NT também permite que os emitentes possam consultar MDFe não encerrados sem considerar a situação cadastral da filial. Datas de Implantação. Implantação em Homologação: 03/2023 Implantação em Produção: 04/2023 Sobre as Alterações. Desativação da rejeição da Situação do Emitente no encerramento. K05: Emitente deve estar habilitado na base de dados para emissão do MDFe Exceção: Esta regra não será aplicada quando a forma de emissão do MDFe (tpEmis) for Regime Especial da Nota Fiscal Fácil (3) Observação: Se evento gerado por PAA (grupo: infPAA) verificar se o CNPJ do emitente está em situação ativa no cadastro do CNPJ MEI da RFB. 203: Rej. Rejeição: Emissor não habilitado para emissão do MDFe. Desativação da rejeição da Situação do Emitente no serviço de consulta MDFe não encerrados H06: Emitente não credenciado a emissão de MDFe Exceção: Esta regra não se aplica a CNPJ Emitente que possui vínculo ativo no cadastro de PAA da SVRS. 203: Rej. Rejeição: Emissor não habilitado para emissão do MDFe. Correção da Observação do MOC Anexo I em relação ao tamanho do campo placa no modal rodoviário para o tamanho de 7 caracteres. O MOC Anexo I pode ser encontrado aqui. Já a NT2023/001 pode ser encontrada aqui.