Diego Foliene

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

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-3781. Por favor, é possível disponibilizar o manual do banco para que possamos usar na análise?

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

Primeiro de tudo, muito obrigado pela contribuição. Toda contribuição é e sempre será mais do que bem vinda. Sua contribuição foi: Como você percebeu, a "xsMsXml" é a responsável pelo problema. A correção de identificar o NameSpaceURI deve ser implementada nela. Por isso não podemos aceitar essa contribuição no momento. Mas com certeza esse tópico e sua contribuição vão ajudar outros que possam vir a passar pelo mesmo problema, por isso vamos manter aqui.

Bom dia! Por favor, pode fornecer mais detalhes do problema que o fez sugerir essa contribuição? Fiz um teste sem aplicar sua contribuição usando a cidade de Dourados/MS no programa exemplo e não tive erro de schema na validação do arquivo da requisição. Em que momento ocorre o erro? Vale citar que eu não tenho dados de um prestador de serviço válidos, então se for um retorno do webservice, eu não recebo, por isso, preciso de mais informações.

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

Boa tarde. Como é possível observar no print abaixo, múltiplas Sefaz estão com contingência agendada para o dia 02/04/2023, com previsão de início as 06:30 e término as 12:00 horas. Fonte: Portal da Nota Fiscal Eletrônica Siga as orientações deste tópico para fazer a transmissão em contingência com os componentes do ACBr:

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

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

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?

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

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.

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.