Italo Giurizzato Junior

Izaque, O arquivo *-ped-rec-soap.xml é o que é enviado para a SEFAZ e portanto o outro é o retorno. Abre um chamado na SEFAZ-BA e anexa esses dois arquivos, pede para eles mostrarem no arquivo *-ped-rec-soap.xml onde esta o namespace que não se refere a NF-e ou que esteja fora do padrão.

Bom dia, Sendo assim vou fechar esse.

Bom dia, Sei que esta caminhando, mas a passos largos de tartaruga.

Bom dia Juarez, A unit que gera o XML de consulta ao webservice DistribuicaoDFe foi escrita conforme consta na Nota Técnica publicada pelo Encat e disponibilizada no Portal Nacional da NF-e, bem como a do CT-e e MDF-e. A rotina que estabelece a conexão com a SEFAZ é exatamente a mesma usada para todos os outros métodos (envio de lote, consulta, envio de eventos, ...). Me parece que a SEFAZ-RS possui um webservice particular para o DistribuicaoDFe, mas acredito que este seja apenas para os contribuintes do RS. Pode se que esses programas que você mencionou se utilizam desse webservice, tai uma coisa para se investigar. Peço que compare o XML gerado com o layout publicado na Nota Técnica, quem sabe cometemos alguma gafe. Outra coisa importante, o componente se utiliza do serviço DistribuicaoDFe disponibilizado pela SEFAZ-Virtual do Ambiente Nacional e os eventos de Manifestação do Destinatário também são enviados para a SV-AN.

Bom dia a todos, Pelos XML anexados pelo Izaque, a rejeição apontada pela SEFAZ-BA não condiz com a realidade, pois em todos os XMLs gerados pelo componente e enviados para a SEFAZ tem o mesmo NameSpace, vocês podem inclusive comparar com os XMLs retornados pela mesma. Notem que o Lote é enviado e o numero do recibo é retornado, mas ao realizar a consulta (pelo numero do recibo) é retornado a rejeição. Posso garantir que o componente esta gerando os XMLs corretamente inclusive com o NameSpace correto. O problema esta no serviço de consulta pelo recibo da SEFAZ-BA que esta com problemas. Favor abrir chamado questionando o problema, não esqueçam de anexar o XML de consulta pelo recibo (arquivo: *-ped-rec.xml), bem como o seu retorno (arquivo: *-proc-rec.xml). Pedem para eles provarem que no arquivo enviado consta o NameSpace errado. Izaque: Por favor configure o componente para salvar os arquivos soap, faça um novo teste e anexe os XMLs. Configuracoes.WebServices.Salvar := True; Teremos os arquivos: *-ped-rec-soap.xml, *-proc-rec-soap.xml, ...) anexe esses para que eu possa analisar.

Boa tarde Joceandro, Até que enfim eles viram a mercadoria que tinham feito. Esses Schemas pelo que notei são exatamente os que eu corrigi e que estão no repositório. Não há nenhuma novidade.

Boa tarde Mauricio, Muito obrigado pela colaboração, mas os seus fontes estão desatualizados. Favor atualizar todos os fontes de todas as pastas, reinstale usando o ACBrInstall_Trunk2 marcando a opção para apagar os arquivos antigos. E veja como eu fiz na unit que gera o XML para o Equiplano, não há necessidade de se criar mais uma propriedade.

Boa tarde Thiago, Segue um exemplo: if ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Count > 0 then begin // as linhas abaixo é interessante colocar em um loop, pois pode ser retornado mais de uma rejeição sStat := ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Codigo; sMotivo := ACBrNFSe.WebServices.EnviarSincrono.RetornoNFSe.ListaNfse.MsgRetorno.Items[0].Mensagem; end else begin sStat := ''; sMotivo := ''; end;

Boa tarde Allan, Muito obrigado pela colaboração, já esta no repositório.

Bom dia Izaque, Uma dica, não precisa executar o GerarNFe, pois o Método Assinar se encarrega de gerar o XML. Caso você venha executar o ACBrNFe.Enviar(nLote, False) nem precisa executar o Assinar e Validar, pois o Enviar se encarrega disso.

Bom dia William, Você esta usando o programa exemplo para os seus testes? Veja que com ele, você marca o evento que deseja gerar ou gerar e enviar. Estude o programa exemplo.

Bom dia Rafael, O numero do protocolo normalmente é retornado quando usamos o método Enviar pois usamos o numero do protocolo para Consultar a Situação do Lote (Versão 1 do layout da ABRASF) e para Consultar o Lote. Já os métodos EnviarSincrono e Gerar vai depender do provedor retornar ou não essa informação.

Bom dia Leo, O grande problema é que os provedores disponibilizam um Schema para que possamos validar o Lote de RPS antes do seu envio, mas o schema usado pelo validador do webservice é outro. Segundo o Schema disponibilizado pelo provedor entre o grupo <Tomador> e o elemento <OptanteSimplesNacional> temos: <xsd:element name="Tomador" type="tcDadosTomador" minOccurs="0" maxOccurs="1" /> <xsd:element name="Intermediario" type="tcDadosIntermediario" minOccurs="0" maxOccurs="1" /> <xsd:element name="ConstrucaoCivil" type="tcDadosConstrucaoCivil" minOccurs="0" maxOccurs="1" /> <xsd:element name="RegimeEspecialTributacao" type="tsRegimeEspecialTributacao" minOccurs="0" maxOccurs="1" /> <xsd:element name="OptanteSimplesNacional" type="tsSimNao" minOccurs="1" maxOccurs="1" /> Note que os grupos: <Intermidiario>, <ConstrucaoCivil> e o elemento <RegimeEspecialTributacao> que aparecem na mensagem de rejeição, segundo o Schema são opcionais. Mas como dito antes, o Schema usado no webservice exige que o elemento <RegimeEspecialTributacao> seja obrigatório. Sendo assim informe o Regime Especial de Tributação que as chances do RPS ser aceito é grande.

Bom dia Thiago, Todos os provedores (empresas contratadas pelas prefeituras) que seguem a versão 2 do layout da ABRASF a principio disponibiliza o serviço de envio Síncrono. Neste caso não temos o serviço para consultar a situação do lote. O que temos é o Consultar Lote que se o lote enviado foi processado com sucesso, teremos como retorno o XML da NFS-e, caso contrario teremos a lista de rejeições. Estude o programa exemplo do componente ACBrNFSe.

Bom dia Danilo, Estamos analisando esse efeito colateral.

Bom dia João, Estamos analisando esse efeito colateral.

Danilo, Mas a unit que passei não tem nada haver com essa.

Boa tarde Danilo, Favor testar com as units abaixo: ACBrDFeXsLibXml2.pas ACBrNFSeWebServices.pas

Boa tarde João, Peço que faça um teste com as Units abaixo: ACBrDFeXsLibXml2.pas ACBrNFSeWebServices.pas

Boa tarde William, Acabei de fazer um teste usando o programa exemplo, o XML do evento 2200 foi gerado, assinado e validado com sucesso. Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a Suite ACBr usando o ACBrInstall_Trunk2 com a opção: apagar arquivos antigos marcada? Configurou o programa exemplo para usar os schemas da pasta: ...\trunk2\Exemplos\ACBrDFe\Schemas\eSocial ?

Boa tarde Volnei, Sim, mas peço que leia as Notas Técnicas pois consta informações importantes para o Desenvolvedor e contem as datas de implementação no ambiente de homologação e produção das SEFAZ.

Bom dia a todos, Os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec> = Informações do Responsável Técnico. Para quem emite NF-e favor ler a Nota Técnica 2018/005, já os emitentes de CT-e - Nota Técnica 2018/002 versão 1.01, e MDF-e - Nota Técnica 2018/002 versão 1.02 Essas NT estão disponíveis nos Portais de cada Documento Fiscal Eletrônico. Para quem esta com os fontes atualizados e reinstalados, ao selecionar o componente ACBrNFe ou ACBrCTe ou ACBrMDFe vai notar no Object Inspector em Configurações o grupo RespTec e dentro deste as propriedades idCSRT e CSRT. O grupo <infRespTec> contem as seguintes informações: CNPJ, Nome, e-mail, telefone, idCSRT e HashCSRT do Responsável Técnico. Sendo que as duas ultimas são geradas automaticamente se as propriedades idCSRT e CSRT forem informadas. Logo o que muda na aplicação: Configuração: Configuracoes.RespTec.idCSRT := <identicador do CSRT> Configuracoes.RespTec.CSRT := <Código de Segurança do Responsável Técnico> Tanto o ID quanto o código serão fornecidos futuramente pela SEFAZ, sendo assim devemos atribuir zero ao idCSRT e uma string vazia para CSRT, nesse primeiro momento. Rotina que alimenta o componente: // Dados do Responsável Técnico infRespTec.CNPJ := xCNPJ_RespTec; infRespTec.xContato := xContato_RespTec; // Nome do responsável técnico infRespTec.email := xEmail_RespTec; infRespTec.fone := xFone_RespTec; Como dito acima o idCSRT e HashCSRT são gerados automaticamente caso o idCSRT seja diferente de zero e CSRT diferente de uma string vazia. Observação: Tanto a configuração quanto a alimentação do componente é exatamente a mesma conforme o exemplo acima para a NF-e, CT-e e MDF-e. A geração desse grupo esta condicionada a cada UF, sendo assim uma UF poderá exigir e outra não, logo devemos ficar atento a legislação de cada UF.

Bom dia Morgana, Se você tenta encerrar o MDF-e 272 ocorre a rejeição refere a data é porque ele existe, caso contrario deveria mostrar a rejeição informando que o MDF-e não consta na base de dados da SEFAZ. Entre no Portal do MDF-e e tente baixar o MDF-e em questão.

João, Você poderia fazer esse teste de enviar o cancelamento?

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