Painel de líderes

Interesso, sim, em contribuir com o projeto, realizando os testes e validação do mesmo. como devo proceder?

Boa tarde Por algum motivo, o componente estava vindo com alguma sujeira. Coloquei o ACBRNFe.NotasFiscais.Clear e o problema foi sanado.

Bom dia Ângelo, Muito obrigado pela colaboração, assim que possível vou enviar para o repositório. Observação, lembre-se que quando incluir um novo campo devido a uma alteração no layout do evento, além de incluir a linha que vai gerar esse campo no XML, devemos também incluir a leitura desse campo na função: LerArqIni. Essa função é utilizada pelo ACBrMonitor (aplicativo utilizado por desenvolvedores que não utilizam Delphi e Lazarus) para ler o arquivo INI de um evento.

Terá problemas (rejeição)... Já que o estado ainda não está preparado para receber essa informação.

Bom dia Sergio, o interessante é você consultar um analista contábil pra te ajudar nesse quesito, ele saberá (ou ao menos deveria) responder todos seus questionamentos acerca do assunto com maior exatidão. Há várias regras e situações diferentes para cada empresa, então fica complicado lhe passar como são feitos os cálculos sendo que pode resultar em problemas futuros, ao menos em minha opinião, não é mesmo? Abraço

Boa noite Italo, obrigado pela resposta..na verdade minha dúvida era se a UF estava realmente validando o conteúdo, aparentemente sim..obrigado mais uma vez.

No teu XML falta a versão do evento. with ACBrCTe1.EventoCTe.Evento.New do begin infEvento.cOrgao := 41; infEvento.versaoEvento := '1.00'; Tanto cOrgao quando a configuração ACBrNFe1.Configuracoes.WebServices.UF deve ser a UF do emitente do CTe, no caso, o PR.

O evento de cancelamento vem sem a manifestação do destinatário. Então supondo do exemplo que o destinatário recebe o resumo hoje com a situação da nota autorizada e no outro dia o emitente cancela essa NFe. Será gerado um novo NSU com o evento de cancelamento e o mesmo será disponibilizado para o destinatário mesmo que ele ainda não realizado nenhum evento de manifestação. Como pode ver nesse exemplo: Abaixo vou deixar um trecho de como conseguir capturar o evento de cancelamento no momento que estiver processando os NSU's. for i := 0 to Pred(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count) do begin LDocZip := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[i] if (LDocZip.schema = schprocEventoNFe) then begin if LDocZip.procEvento.RetinfEvento.tpEvento = teCancelamento then begin Justificativa := LDocZip.procEvento.detEvento.xJust; Data := LDocZip.procEvento.RetinfEvento.dhRegEvento; Protocolo := LDocZip.procEvento.RetinfEvento.nProt; end; end; end;

Mas se ele é consumidor final, e você informou a inscrição estadual IEDest, e na tag IndIEDest= 9 ( Não contribuinte). <indIEDest>9</indIEDest> --> Esta definido como não contribuinte <IE>407069960117</IE> --> Porém foi informada a Inscrição Estadual Dercide.

Homologando o Módulo VPE - CE Ola, Nesse tópico vamos detalhar os passos para realizar testes e homologação utilizando o Módulo VPE (Validador de Pagamentos Eletrônicos) com o Integrador Fiscal no estado do CE. Embora a SEFAZ CE permitiu a emissão de Cupom Fiscal Eletrônico utilizando apenas o driver MFe (sem a necessidade do uso do Aplicativo Integrador Fiscal), para a integração dos dados de pagamento com cartão - VPE, ainda é necessário a utilização do Integrador Fiscal do Ceará. Para esse procedimento, segue abaixo como utilizar o Componente ACBrIntegrador para realizar o envio dos dados de pagamento por meio do Integrador Fiscal. Neste caso, estamos utilizando o Demo "SATTest" do Projeto ACBr para os testes, você poderá verificar os fontes desse demo no repositório do ACBr : (..\ACBr\Exemplos\ACBrSAT\ ) ou baixar o demo em: SATTest Instalar Integrador Fiscal O Primeiro passo é Instalar o Aplicativo Integrador Fiscal, segue abaixo o tópico sobre como Instalar e configurar o Integrador Fiscal: Instalar Integrador Fiscal Utilizando o SATTest No exemplo do SATTest abaixo, estamos utilizando a conexão direta com a dll do driver MFe, mas a comunicação entre o ACBrIntegrador - (VPE) e o Integrador Fiscal vai funcionar independente desta configuração, basta apenas que o Integrador Fiscal esteja em execução e devidamente configurado na máquina. Para mais Informações sobre configuração do Driver MFe, veja em: Configurar Driver MFe Para integração ACBrIntegrador e VPE vá para aba: MFe e veja as quatro opções disponíveis para o Módulo VPE - ("Enviar Pagamento", "Enviar Status Pagamento", "Verificar Status Validador", "Resposta Fiscal") Existem duas situações para Integração do Módulo VPE, sendo distintas entre: POS e TEF: Utilizando Integração VPE com Pagamento P.O.S. Obs Importante: A SEFAZ CE não disponibilizou um Serviço P.O.S. compatível com Integrador Fiscal conforme estava previsto inicialmente. Então a opção "Verificar Status Validador" está disponível apenas para ambiente de homologação, para isso é utilizado o Simulador P.O.S. Ceara: http://simuladorposceara.azurewebsites.net/. Portanto o Serviço "Verificar Status Validador" não é utilizado em Produção. Passo 1: EnviarPagamento Informações a ser enviada neste método: PagamentoMFe := TEnviarPagamento.Create; try with PagamentoMFe do begin Clear; ChaveAcessoValidador := '25CFE38D-3B92-46C0-91CA-CFF751A82D3D'; ChaveRequisicao := '26359854-5698-1365-9856-965478231456'; Estabelecimento := '10'; SerialPOS := InputBox('SerialPOS','Informe o Serial do POS','ACBr-'+RandomName(8)); CNPJ := edtEmitCNPJ.Text; IcmsBase := 0.23; ValorTotalVenda := 1530; HabilitarMultiplosPagamentos := True; HabilitarControleAntiFraude := False; CodigoMoeda := 'BRL'; EmitirCupomNFCE := False; OrigemPagamento := 'Mesa 1234'; end; ... finally ... end; Definição sobre Principais Campos: Chave de Acesso Validador - Esta chave é fixa, está Pré-Definida no Manual Do Integrador Fiscal. Chave de Requisição - Esta chave deve ser única para cada requisição POS, deve-se gerar um GUID para cada Envio de Pagamento. Esta especificação está descrita no Manual do Integrador. Estabelecimento - Como não existe este equipamento POS Integrado conforme previsão inicial, está sendo informado um valor fixo. SerialPOS - Como não existe este equipamento POS Integrado conforme previsão inicial, está sendo informado o Numero serial do Equipamento POS utilizado (Independente do equipamento) (Apenas para efeito de testes no SATTest, estamos utilizando um valor randômico para gerar o Número do Serial). Após o Envio do Pagamento será retornado o "ID do Pagamento" obs: O ID do pagamento deve ser gravado pela sua aplicação para Identificação do Pagamento e Requisições Posteriores, pode ser obtido pelo método: (RespostaVerificarStatusValidador.CodigoAutorizacao) Passo 2: VerificarStatusValidador (Utilizado apenas em Ambiente de Homologação) Para Testes em Homologação deve-se utilizar o Site Simulador POS Ceará http://simuladorposceara.azurewebsites.net/ e informar o SerialPOS utilizado no envio, para Simular o Pagamento Efetuado Após a Confirmação de Pagamento utilizando o Emulador, deve realizar a chamada do método: VerificarStatusValidador informando o ID Pagamento: with VerificarStatusValidador do begin Clear; ChaveAcessoValidador := '25CFE38D-3B92-46C0-91CA-CFF751A82D3D'; IDFila := StrToIntDef(InputBox('IDPagmento','Informe o ID do Pagamento',''),0); CNPJ:= edtEmitCNPJ.Text; end; Definição sobre os Campos: Chave de Acesso Validador - Esta chave é fixa, está Pré-Definida no Manual Do Integrador Fiscal. ID FIla - Este campo se trata do "ID Pagamento" retornado no primeiro método CNPJ - CNPJ do Emitente Será obtido como retorno o XML com a simulação da Autorização de Pagamento: Lembrando que em Produção não é possível realizar o Passo 2, pula direto para o passo 3: Passo 3: RespostaFiscal Após o Envio do XML de Venda para o MFe ou Integrador (no caso de NFC-e), realiza-se o passo 3, apenas para Vincular o Pagamento com Cartão a um Documento Fiscal, através do método: RespostaFiscal RespostaFiscal := TRespostaFiscal.Create; try with RespostaFiscal do begin Clear; ChaveAcessoValidador := '25CFE38D-3B92-46C0-91CA-CFF751A82D3D'; IDFila := StrToIntDef(InputBox('IDPagmento','Informe o ID do Pagamento',''),0); ChaveAcesso := '35170408723218000186599000113100000279731880'; Nsu := '1674068'; NumerodeAprovacao := '123456'; Bandeira := 'VISA'; Adquirente := 'STONE'; if Assigned(ACBrSAT1.CFe) and (ACBrSAT1.Extrato= ACBrSATExtratoESCPOS1) then ImpressaoFiscal := '<![CDATA['+ACBrSATExtratoESCPOS1.GerarImpressaoFiscalMFe+']]>'; NumeroDocumento := '1674068'; CNPJ:= edtEmitCNPJ.Text; end; finally RespostaFiscal.Free; end; Definição sobre Principais Campos: Chave de Acesso Validador - Esta chave é fixa, está Pré-Definida no Manual Do Integrador Fiscal. ID FIla - Este campo se trata do "ID Pagamento" retornado no primeiro método ChaveAcesso - Refere-se a Chave do CFe de Venda gerado pelo MFe ou Integrador Fiscal (no caso de NFC-e) NSU - Fornecido pela Adquirente (Autorizadora de Pagamento) - Como não existe este equipamento POS Integrado conforme previsão inicial, está sendo informado um valor fixo. NumeroAprovacao - Código de Autorização de Pagamento Retornado pela Adquirente - Como não existe este equipamento POS Integrado conforme previsão inicial, está sendo informado um valor fixo. ImpressaoFiscal - A Intensão futura será passar o Extrato do CFe para impressão no aparelho POS (A Função GerarImpressaoFiscalMFe já gera o Modelo do Cupom a ser impresso) NumeroDocumento - Número do Cupom Fiscal Autorizado. Será obtido o XML Retorno com o Código de Processamento da Resposta Fiscal. Encerra-se o Processo VPE - utilizando o P.O.S. Utilizando Integração VPE com Pagamento TEF Passo 1: EnviarStatusPagamento Informações a ser enviada neste método: StatusPagamentoMFe := TStatusPagamento.Create; try with StatusPagamentoMFe do begin Clear; ChaveAcessoValidador := '25CFE38D-3B92-46C0-91CA-CFF751A82D3D'; CodigoAutorizacao := '20551'; Bin := '123456'; DonoCartao := 'TESTE'; DataExpiracao := '01/01'; InstituicaoFinanceira:= 'STONE'; Parcelas := 1; CodigoPagamento := '12846'; ValorPagamento := 1530; IDFila := 1674068; Tipo := '1'; UltimosQuatroDigitos := 1234; end; finally StatusPagamentoMFe.Free; end; Definição sobre Principais Campos: Chave de Acesso Validador - Esta chave é fixa, está Pré-Definida no Manual Do Integrador Fiscal. Obs: Para quem utiliza o Componente ACBrTEFD os dados do cartão e de Confirmação de Pagamento, utilizados no pagamento TEF podem ser obtidos acessando a propriedade ACBrTEFDRespNFCeSAT da Classe de retorno TACBrTEFDResp do Componente ACBrTEFD, automatizando assim o preenchimento destes dados. Será obtido o XML Retorno com o Código de Processamento do Status de Pagamento. Passo 2: RespostaFiscal Após o Envio do XML de Venda para o MFe (ou Integrador no caso de NFC-e), realiza o passo 2, apenas para Vincular um Pagamento com Cartão ao Documento Fiscal, através do método: RespostaFiscal RespostaFiscal := TRespostaFiscal.Create; try with RespostaFiscal do begin Clear; ChaveAcessoValidador := '25CFE38D-3B92-46C0-91CA-CFF751A82D3D'; IDFila := StrToIntDef(InputBox('IDPagmento','Informe o ID do Pagamento',''),0); ChaveAcesso := '35170408723218000186599000113100000279731880'; Nsu := '1674068'; NumerodeAprovacao := '123456'; Bandeira := 'VISA'; Adquirente := 'STONE'; if Assigned(ACBrSAT1.CFe) and (ACBrSAT1.Extrato= ACBrSATExtratoESCPOS1) then ImpressaoFiscal := '<![CDATA['+ACBrSATExtratoESCPOS1.GerarImpressaoFiscalMFe+']]>'; NumeroDocumento := '1674068'; CNPJ:= edtEmitCNPJ.Text; end; finally RespostaFiscal.Free; end; Definição sobre Principais Campos: Chave de Acesso Validador - Esta chave é fixa, está Pré-Definida no Manual Do Integrador Fiscal. ID FIla - Este campo se trata do "ID Pagamento" retornado no primeiro método ChaveAcesso - Refere-se a Chave do CFe de Venda gerado pelo MFe ou Integrador Fiscal (no caso de NFC-e) NSU - Fornecido pela Adquirente (Autorizadora de Pagamento) - Como não existe este equipamento POS Integrado conforme previsão inicial, está sendo informado um valor fixo. NumeroAprovacao - Código de Autorização de Pagamento Retornado pela Adquirente - Como não existe este equipamento POS Integrado conforme previsão inicial, está sendo informado um valor fixo. ImpressaoFiscal - A Intensão futura é utilizar no Aparelho POS NumeroDocumento - Número do Cupom Fiscal Autorizado. Será obtido o XML Retorno com o Código de Processamento da Resposta Fiscal. Encerra o Processo VPE - utilizando o TEF Veja Mais detalhes sobre o Fluxo de Venda utilizando POS e TEF em: https://servicos.sefaz.ce.gov.br/internet/download/projetomfe/FluxoVendaPDVUtilizandoPOS.pdf https://servicos.sefaz.ce.gov.br/internet/download/projetomfe/FluxoVendaPDVUtilizandoTEF.pdf Manual Integrador: http://cfe.sefaz.ce.gov.br/mfe/informacoes/downloads#/

Para saber mais como tratar a contingência, na NFCe, vejam essas dicas abaixo... Nessas palestras que fizemos em conjunto com a Elgin, existe uma apresentação, com Download Livre... (baixe o arquivo Apresentação - ACBr - Elgin - ACBrNFe.pdf) Na 2a Edicao do Dia do ACBr, nosso Consultor @José M. S. Junior, ministrou uma excelente palestra sobre o assunto... Veja o vídeo no nosso Canal do YouTube No Curso Completo do ACBrMonitPlus, @José M. S. Junior, também tem aulas específicas sobre a Contingência Off-line https://www.projetoacbr.com.br/forum/video/browse/39-aula-26-contingencia-da-nfe-e-nfce/ Se você é usuário do SAC do ACBr, creio que esse vídeo de um Webinar, ministrado por @André Ferreira de Moraes, responderá todas as suas dúvidas...

Há uns 6 anos atrás achei isso: tão verdade...

Boa tarde, Essa configuração é sugerida para que utiliza certificado A3, se você utiliza A1 aconselho configurar com libOpenSSL, desta forma você fica livre de qualquer configuração e atualização do Windows.

sim deu, muito obrigado

Boa tarde Felipe! Passei o timeout para 8000 e o SSLType para o LT_TLSv1_2 como sugerido. Vou continuar os testes, obrigado.

Meu Deus... que vergonha..... deu certo, muito obrigado Italo.

Boa tarde! Quero agradecer enormemente ao Italo e ao Big Wings pela atenção e ajuda dispensado ao meu problema. Consegui emitir o manifesto. Obrigado a todos.

problema resolvido

realmente era esse problema

Bom dia Chagas, Notei que o XML esta sendo gerado segundo a versão 4.00, mas pelo XML de retorno a versão do aplicativo da SEFAZ responsável pela recepção da nota é da versão 3.10, muito estranho. Verifique a configuração do componente, o atributo VersaoDF tem que ter o valor ve400. Outra coisa, futuramente as suas notas vão ser rejeitadas, motivo: você esta atribuindo o numero da nota ( nNF ) ao código da nota ( cNF ). Leia a Nota Técnica 2019/001.

Bom dia, Pela mensagem de erro diz que o grupo Endereço esta incompleto, segundo a mensagem esta faltando a UF, e o e-mail esta invalido.

Curioso né? Bom Italo, vou seguir por aqui então tentando viabilizar o serviço. Obrigado pelo retorno.

Fernando, Com certeza deve ser uma exceção, inclusive existem nesse Webservice serviços que eu nunca tinha visto.

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

Bom dia. Seus fontes estão atualizados? Não tivemos relatos recentes deste problema. Att.

Acho que desde a versão 1.2.0.59 o problema começou. Se passar no INI as informações funciona, mas antes não era necessário porque pegava do proprio monitor. [infCFe] versao=0.07 [Identificacao] CNPJ=11111111111111 signAC=SGR-SAT SISTEMA DE GESTAO E RETAGUARDA DO SAT numeroCaixa=1

Bom dia. Você deve verificar se estas UFs permitem este tipo de documento, eu tenho conhecimento somente de Manaus e do DF. Att.

Validações a critério da UF significa que o estado pode ou não aderir aquela regra/validação. Nesse caso a forma mais correta é entrando em contato com a SEFAZ do estado e verificando com eles o que vão implementar. Pode ainda verificar se há algum boletim informativo no site da SEFAZ de cada estado com essa informação. O grupo do responsável técnico (uma das novas implementações da nota técnica) foi muito discutido aqui no grupo e com isso foi criado uma "aba" no mapa fiscal do ACBr. De uma olhada lá e você verá quais serão os estados que irão implementar. Sobre as demais validações, recomendo também dar uma pesquisada aqui no fórum. Pois em alguns casos alguém já fez esse contato com a SEFAZ do estado e já obteve a resposta se a validação X será implementada para aquele estado. Uma dica é: deixe seu software inteiramente compatível com a Nota Técnica em questão. E nas validações que são a critério da UF, você cria parâmetros, por exemplo: "Enviar grupo responsável técnico" (Sim ou não) dessa forma se amanhã ou depois algum estado aderir, basta você marcar essa opção no seu sistema.

Olá, Eu acabei de enviar ao SVN (revisão 17083) uma correção para os ECF de modelos que utilizam o protocolo ESCECF, FiscNet e Epson. Você pode atualizar o seu código e testar novamente. Queira, por favor, reportar qualquer problema.

Bom dia Você chegou a testar no demo? Att.

Bom dia, Veja neste tópico que já foi enviada uma contribuição para este caso, porém precisava uma análise mais detalhada, de modo a ser funcional para todos os geradores. Att.

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

A configuração do ACBrMonitorPlus não só se resume na parametrização dos arquivos de entrada e saída. Requer assinatura, código de ativação, etc. Entre em contato com o fornecedor desse software: https://www.bling.com.br/contato

Funcionou agora Muito obrigado pela ajuda.

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

Encontrei o erro no meu código. O campo convênio eu estava preenchendo conforme o manual, porém é só preencher com o número que o componente faz a tratativa. Desconsiderar!

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

Boa tarde Italo, Agora passou. O problema estava mesmo no CNPJ. Muito obrigado pela ajuda.

Sim vou postar obrigado pela atenção e dica! Solução que encontrei foi bem simples, minha variável fDataProtesto eu tinha criado ela como String, bastou eu alterar ela para TDate, que funcionou tudo certo. Obrigado ACBR.

Bom dia, joao.becker. Mas qual a mensagem de erro?

Bom dia Volmir, Foram feitos algumas alterações nos arquivos INI de diversos provedores. Verifique se no seu cliente o arquivo Betha.ini esta atualizado.

Bom dia Rogério, A configuração esta correta, se o tomador é de SP, você tem que informar SP ao campo UF. Mas na sua rotina esta faltando uma linha. infEvento.cOrgao := 'SP'; A UF informada em ACBrCTe1.Configuracoes.WebServices.UF tem que ser a mesma informada em infEvento.cOrgao.

Bom dia, de acordo com as informações que temos, MG por hora não irá validar as informações. https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico

Favor anexar os XML de envio e de retorno do evento. Outra coisa importante, o CNPJ informando no campo CNPJ tem que ser do destinatário da mercadoria e não de quem emitiu a nota.

Resolvido com a dica do amigo @BigWings Obrigado. Charles

Olá Pessoal, Muitos desenvolvedores acabam escolhendo um dos 3 métodos de envio de RPS e nem sempre funciona, porque? É muito simples, primeiro temos que separar os provedores em 3 grupos: os que seguem a versão 1 do layout da ABRASF, os que seguem a versão 2 e os que tem o seu próprio layout. Os provedores que seguem a versão 1 do layout da ABRASF oferecem somente o serviço de envio assíncrono, portanto só podemos usar o método Enviar do componente, esse método permite o envio de um lote contendo de 1 até 50 RPS. Os provedores que seguem a versão 2 do layout da ABRASF a principio oferecem os serviços: envio assíncrono, envio síncrono e gerar NFSe, respectivamente no componente temos os métodos: Enviar, EnviarSincrono e Gerar, onde os dois primeiros permite o envio de um lote contendo de 1 até 50 RPS e o último o envio de apenas 1 RPS. Destaquei "a principio" porque ao implementar dezenas de provedores que seguem a versão 2 no componente, notei que vários não disponibilizaram os 3 serviços e sim apenas um ou dois dos três sugeridos pelo layout. Logo não é possível afirmar que todos os provedores que seguem a versão 2, disponibilizam os 3 serviços de envio. Já os provedores que tem o seu próprio layout, não tem como estabelecer uma regra, pois cada um implementou o serviço que melhor lhe convém. Além dos serviços de envio, temos também os de consulta, cancelamento e substituição de NFSe. Como faço para saber quais são os serviços disponibilizados pelo provedor que vou utilizar, bem como o layout que ele segue? É muito simples, basta abrir o arquivo INI do mesmo. Na seção XML temos o campo Layout que pode conter os seguintes valores: ABRASFv1, ABRASFv2 ou outro valor (normalmente o nome do provedor). No caso de um valor diferente de ABRASFv1 e ABRASFv2 fica claro que não segue nenhuma das versões da ABRASF, logo tem o seu próprio layout. Para saber os serviços oferecidos pelo provedor basta olharmos para as seções: [Recepcionar] => Responsável por montar o envelope de Envio assíncrono, se consta a definição do envelope significa que este serviço esta disponível. [ConsSit] => Responsável por montar o envelope de Consulta a Situação do Lote, se consta a definição do envelope significa que este serviço esta disponível. [ConsLote] => Responsável por montar o envelope de Consulta ao Lote, se consta a definição do envelope significa que este serviço esta disponível. [ConsNFSeRps] => Responsável por montar o envelope de Consulta NFSe por RPS, se consta a definição do envelope significa que este serviço esta disponível. [ConsNFSe] => Responsável por montar o envelope de Consulta NFSe, se consta a definição do envelope significa que este serviço esta disponível. [Cancelar] => Responsável por montar o envelope de Cancelar NFSe, se consta a definição do envelope significa que este serviço esta disponível. [Gerar] => Responsável por montar o envelope de Gerar NFSe, se consta a definição do envelope significa que este serviço esta disponível. [RecSincrono] => Responsável por montar o envelope de Envio síncrono, se consta a definição do envelope significa que este serviço esta disponível. [Substituir] => Responsável por montar o envelope de Substituir NFSe, se consta a definição do envelope significa que este serviço esta disponível. Exemplo de um Envelope não definido, portanto serviço não disponibilizado no webservice do provedor: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1= Exemplo de um Envelope definido, portanto serviço disponibilizado no webservice do provedor: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1=<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> Texto2=<S:Body> Texto3=%DadosMsg% Texto4=</S:Body> Texto5=</S:Envelope> Conselho: Tenha uma tela de configuração que permite ativar ou não a execução de cada um desses métodos, assim a sua aplicação pode enviar o RPS através do método ou outro dependendo da configuração estabelecida por conta do provedor a ser utilizado.

Opa! Então, para cada rubrica com incidência de IRRF 51, 52, 53, 54 ou 55 o grupo <penAlim> deve ser informado, nas demais o grupo deve ser omitido. Geralmente temos somente uma rubrica de pensão para cada demonstrativo do empregado. Se você tiver mais de uma talvez seja interessante junta-las. Assumindo que você é o desenvolvedor do programa e de todo modo precisa ter várias rubricas de pensão, o beneficiário deve ser informado para cada uma rubrica no xml, mas no seu programa você pode realizar esse vinculo somente uma vez e quando for gerar o evento busca esse vinculo e repete para cada uma. Como são dados cadastrais não vejo como poderia interferir em algum totalizador. É interessante que os valores do campo <vlrPensao> corresponda aos valores das rubricas, no meu caso o valor da rubrica e o valor da pensão foi sempre o mesmo. As rubricas de pensão alimentícia devem ser informadas porque interferem na formação da base de calculo do IRRF, então se você esta se referindo a totalizações que o sistema do e-Social faz, acho que o valor das rubricas que são importantes. Acredito que esses dados estão sendo solicitados mais para fazerem algum tipo de cruzamento de informação com a declaração do IR ou algo do tipo, para efeito de cálculo e fechamento da folha, o que vale é o valor da rubrica.

Boa tarde Adilson, A mensagem é clara, o RPS não foi aceito por já existir outro com o mesmo numero, serie e tipo. É preciso descobrir qual foi o ultimo RPS enviado para dar continuidade na numeração.

Boa tarde. Obrigada pelo feedback, está para ser analisada pelo @José M. S. Junior Att.

Responsável Técnico - Como fica o XML na prática? Com tantas alterações, ficou um pouco confuso entender quando e quais tags do grupo Responsável Técnico deverão ser enviadas. Segue então um resumo. Até 02/06/2019 Os XMLs deverão ser enviados sem este grupo, como tem sido feito até então. A partir de 03/06/2019 Para as UFs do AM, MS, PE, PR, SC e TO deverá ser incluído o grupo Responsável Técnico, porém sem as tags relativas ao idCSRT. Veja imagem a seguir. Após definição de data para exigência do idCSRT Quando as SEFAZ publicarem as datas para exigência destas tags, as mesmas passarão a ser exigidas no XML, caso contrário os mesmos passaram a ser rejeitados. A seguir, exemplo de XML com o grupo Responsável Técnico completo. Importante Até o presente momento nenhuma SEFAZ disponibilizou os mecanismos para geração do idCSRT, logo mesmo em homologação não é possível enviar estas tags. A partir de 07/05/2019 as UFs que optaram pela exigência do Grupo do Responsável Técnico ( AM, MS, PE, PR, SC e TO ), já aceitaram as tags de identificação também em ambiente de produção, porém rejeitarão os XMLs sem estas tags somente em 03/06/2019.