Italo Giurizzato Junior

Bom dia Solivan, Muito obrigado pela colaboração, ainda hoje estaremos enviando para o repositório.

Bom dia Professor, Acredito o problema seja que você esta destacando campos que não deveria. Por exemplo no grupo <infResp> a tag <CNPJ> só deve ser preenchida se o valor de <respSeg> for 2. A rejeição referente a imagem postada é 699, ela ocorre conforme a regra G084 que diz: Se modal Rodoviário e Tipo Emitente for igual a Prestador de Serviço de Transporte (tpEmit=1) e informado grupo de seguro da carga: -Rejeitar se alguma informação do grupo seguro não estiver informada. OBS: Verificar preenchimento de CNPJ/CPF, infSeg, nApol e nAver A empresa que esta emitindo o MDF-e é uma transportadora? Se não for, o valor de tpEmit não pode ser 1, tem que ser 2 = Transportador de Carga Própria.

Bom dia, As datas estão informadas de forma errada. O formato correto de uma data no XML é: AAAA-MM-DD No seu XML esta no seguinte formato: DD/MM/AAAA Corrija o formato de todas as datas e tente novamente.

Bom dia Gustavo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Ismael, Veja se você consegue os Schemas (Arquivos XSD) que serão utilizados para validar o XML antes do seu envio.

Rubens, Anexa o XML de exemplo de envio de um lote para podermos comparar com o que o ACBr esta gerando.

Qual é a aplicação que esta gerando esse XML? Se é a sua, por favor tenha em mãos o Manual do eSocial, pois removi a assinatura do XML que você anexou tentei ler com o programa exemplo do eSocial e o erro não é esse e sim: 1871 - Element '{http://www.esocial.gov.br/schema/evt/evtMonit/v02_04_02}respMonit': Missing child element(s). Expected is ( {http://www.esocial.gov.br/schema/evt/evtMonit/v02_04_02}nisResp ). Ou seja esta faltando o elemento nisResp que faz parte do grupo respMonit. Se você olhar o seu XML o grupo respMonit esta vazio e esse grupo é obrigatório e nele consta 3 tags sendo que as 2 primeiras são obrigatórias e a ultima opcional. Enquanto você não gerar o XML conforme o manual (sem o grupo Signature) para ser lido pelo componente não vai funcionar.

Peguei o seu XML, removi a assinatura e tentei ler com o programa exemplo. O erro que apareceu não foi esse referente ao elemento nrCRM e sim pela ausência da tag obrigatória <interprExm> que se encontra dentro do grupo exames e fica entre as tags: obsProc (opcional) e ordExame (obrigatória).

Bom dia ALA, É preciso checar o valor da seguinte linha que se encontra em ACBrNFSeWebService: CondicaoNovoRetorno := (StrToInt64Def(FNotasFiscais.Items[ l ].NFSe.IdentificacaoRps.Numero, 0) = StrToInt64Def(FRetornoNFSe.ListaNFSe.CompNFSe.Items[ i ].NFSe.IdentificacaoRps.Numero, 0)) and (FNotasFiscais.Items[ l ].NFSe.IdentificacaoRps.Serie = FRetornoNFSe.ListaNFSe.CompNFSe.Items[ i ].NFSe.IdentificacaoRps.Serie) and ((FNotasFiscais.Items[ l ].NFSe.IdentificacaoRps.Tipo = FRetornoNFSe.ListaNFSe.CompNFSe.Items[ i ].NFSe.IdentificacaoRps.Tipo) or (FNotasFiscais.Items[ l ].NFSe.InfID.ID = FRetornoNFSe.ListaNFSe.CompNFSe.Items[ i ].NFSe.InfID.ID)); Se o valor de CondicaoNovoRetorno for False será criado um novo item na lista. Condições para o teste: Enviar o RPS, não limpar o componente ao realizar a consulta ao Lote.

Bom dia Rubens, Eu não vejo o que melhoraria na segurança se o nome do atributo é id ou Id. Agora, se o valor do atributo ID em vez de ser apenas 123 e passar a ser RPS123 ou Rps123 ou rps123 e este valor ser utilizado na assinatura ai eu concordo que segurança será mais fraca ou mais forte dependendo do valor atribuído ao atributo ID. Outra coisa, no ACBrNFSe para o provedor Salvador temos: Identificador=id portanto o atributo ID esta todo minúsculo. O valor do ID do RPS é: proSalvador: FNFSe.InfID.ID := 'RPS' + OnlyNumber(FNFSe.IdentificacaoRps.Numero); Note que o valor é alfanumérico, a duvida agora é o literal "RPS" tem que ser todo minúsculo? O valor do ID do Lote é: proSalvador: IdLote := 'Lote' + NumeroLote; Note que o valor é alfanumérico, a duvida agora é o literal "Lote" tem que ser todo minúsculo?

Agora deixa, da próxima vez, assuntos diferentes, tópicos diferentes. Muito obrigado pela compreensão.

Bom dia, Quando é o componente que gera o XML o provedor é definido através da informação do código IBGE da cidade. Mas ao ler um XML de um RPS ou NFSe como posso garantir que o mesmo se refere a uma determinada cidade? A minha cidade é Araraquara, mas estou lendo o XML de NFS-e (para imprimir o DANFSE) emitido por uma empresa de Ibaté. Araraquara é atendida pelo provedor Ginfes (segue a versão 1 do layout da ABRASF), já Ibaté é Fiorilli (segue a versão 2). Dai o motivo de descobrir o provedor pelo XML que esta sendo lido.

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Rodrigo, Muito obrigado pela colaboração, fiz uma pequena alteração, ainda hoje estarei enviando para o repositório. Favor atualizar os fontes e repita os testes.

Bom dia ALA, Por favor vamos seguir as regras do fórum, assuntos diferentes tópicos diferentes, não misture os assuntos.

Bom dia Marcos, Com essa alteração o envio de um lote com 1 ou mais RPS foi processado com sucesso? Qual método foi utilizado para o envio (Enviar ou EnviarSincrono)?

Bom dia Everto, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Esse XML esta errado, pois segundo o manual o grupo <ideServSaude> fica dentro do grupo <aso> logo após o grupo <exames> Favor montar corretamente o XML e faça novos testes.

Bom dia Paulo, Realmente o IE informado no grupo <rem> se refere ao CNPJ também informado no mesmo grupo. Favor entrar em contato com a SEFAZ e questionar sobre esse problema, uma vez que ao realizar uma consulta desse CNPJ através do Webservice Consultar Cadastro disponibilizado pela própria SEFAZ retorna exatamente o IE que esta sendo informado no XML.

Bom dia Everto, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Arce, No componente o nome da tag usada na consulta é numeroReciboFechamento, vamos aguardar a publicação de uma Nota Técnica que define o nome correto a ser utilizado.

Bom dia, Você poderia anexar a unit alterada para que possamos analisar a sua proposta de correção?

Bom dia, Favor atualizar os fontes e faça novos testes.

Boa tarde Gean, A Manifestação do Destinatário é um evento, na verdade 4 eventos. * teManifDestCiencia ==> Este evento diz que o Destinatário tem Ciência da Operação, ou seja, esta informando a SEFAZ que realmente comprou o produto. * teManifDestDesconhecimento ==> Este evento diz que o Destinatário Desconhece a Operação, ou seja, esta informando a SEFAZ que não comprou o produto. * teManifDestConfirmacao ==> Este evento diz que o Destinatário Confirma a Operação, ou seja, esta informando a SEFAZ que recebeu o produto. * teManifDestOperNaoRealizada ==> Este evento diz que o Destinatário Não Confirma a Operação, ou seja, esta informando a SEFAZ que não recebeu o produto (neste caso se faz necessário uma justificativa). Gostaria de saber qual é a sua duvida, uma vez que a passagem das informações para o componente é semelhante a da carta de correção ou do cancelamento, uma vez que estes também são eventos.