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#/

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.

Além da configuração indicada pelo Italo, veja também o seu arquivo ACBrNFeServicos.ini, se contém as URL para a versão 4.00 da NFCe.

Resolvido conforme exemplo abaixo, passando o campo DT_FIN_OP apenas quando houver conteúdo: If (DataFinalizacao <> '') then DT_FIN_OP := StrToDate(DataFinalizacao ) ; Obrigado!

Pessoal, sendo tratado aqui: Podem encerrar este tópico por favor.

problema resolvido

realmente era esse problema

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.

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

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.

Bom dia Julio, Muito obrigado pela colaboração, assim que possível vou enviar para o repositório.

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.

Bom dia. O correto é informar 17 na propriedade carteira e 019 em Modalidade. Att.

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

O código atual faz o esperado, caso seja configurado a versão do componente como veqr000 e usada versão 4.00 do XML, ele será ajustado para veqr100. Para usar o QrCode 2.00, basta configurar a propriedade ACBrNFe1.Configuracoes.Geral.VersaoQrCode = veqr200. Com a sua alteração fica impossibilitado o uso do QrCode 1.00 (que não é mais usado, mas mantido por compatibilidade, para recriar um XML antigo, por exemplo).

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

Boa noite Carlos, Primeiramente MDF-e não é uma nota. Segundo, pela chave o numero dele é zero e não 278.

Boa tarde Moroni, Estou anexando uma nova versão do Manual do DAMDFE que inclusive vai ter QR-Code. Manual MDFe Anexo II DAMDFE v3.00a.pdf Note que no DAMDFE para transporte rodoviário (normal) não é impresso a lista de CT-e/NF-e e muito menos os dados referente ao Seguro. Só no DAMDFE em contingência que é impresso a lista de CT-e/NF-e. Não sei porque existem pessoas que ainda ficam focadas no papel, sendo que o XML tem todas as informações necessárias.

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.

Está confundindo causa/efeito. O XML com a tag nfeProc é montado pelo ACBrNFe após o recebimento do protocolo de autorização, ele não é o XML enviado para o webservice. Configure o componente para gravar os arquivos de envio e retorno e anexe aqui os arquivos *-env-lot.xml e *-env-lot-soap.xml onde houve a rejeição.

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 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.

Resolvido com a dica do amigo @BigWings Obrigado. Charles

É um problema conhecido. Quando você não define o espaçamento entre linhas o PosPrinter usa o espaçamento padrão da impressora, mas o componente não conhece esse valor. Então na impressão do QRCode lateral e informação do consumidor, é usado a altura do QRCode como altura máxima dessa região. Como o QRCode agora está reduzido acaba cortando as informações do consumidor + NFCe. Para resolver você só precisa informar um espaçamento entre linhas: ACBrNFeDANFeEscPos1.PosPrinter.EspacoEntreLinhas := <xxx>; Alterar a disposição das informações do consumidor e identificação da NFCe vai contra o manual de especificações do DANFe NFCe e QrCode.

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.

Boa tarde. Seria importante citar também qual foi a resolução do seu problema, de forma a auxiliar os demais usuários no futuro. Att.