Gabriel Fernando Lopes

Boa tarde Leandro, Eu já conhecia estes posts, sei que não devemos usar o DistribuiçãoDFe para buscar XML completo. O problema é que em nenhuma circunstância eu conseguia uma resposta que não fosse a "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". E eu precisava saber se teria outra maneira para eu comprovar que o meu último NSU estava correto ou não. Depois de quebrar a cabeça novamente (sempre esperando 1 hora para cada teste), finalmente o servidor liberou a busca de um novo lote de NSU. Eu fiz os seguintes passos: 1 - Via depuração eu forcei o sistema a usar como ultNSU o zero; (ultNSU = '0';) 2 - Esperei o sistema executar "EnviarDados;" e testei as respostas; 3 - Esperei novamente 1 hora, e mandei buscar novamente usando o mesmo ultNSU que eu tinha e deu certo; Pelo que eu vi, realmente não existe outro caminho para saber qual o ultNSU, a não ser guardar ele ou iniciar novamente como zero. De qualquer forma, obrigado pelo retorno.

Desde fevereiro de 2022 não conseguimos baixar NSU pela função DistribuicaoDFePorUltNSU (utilizamos a função desde março de 2019 sem problemas). Sempre aparece a rejeição "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". A principio achamos que era problema no sefaz e ficamos um tempo sem baixar NSU. No entanto, mesmo ficando uma semana sem tentar baixar, a mensagem de rejeição sempre é a mesma. Então suspeitamos que poderíamos ter perdido um bloco de NSU e portanto estaríamos usando o ultNSU errado. Tentamos essa semana enviar o ultNSU como 0 (zero) para receber o bloco mais antigo existente no ambiente nacional e também para sabermos qual o ultNSU e o maxNSU. No entanto a resposta foi a mesma, "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". Existe alguma outra maneira de contornar esse problema?

Juliomar, pela documentação da DSF quando fazemos consulta por lote só temos de retorno um XML com estes dados (por RPS processado): InscricaoPrestador NumeroNFe CodigoVerificacao SerieRPS NumeroRPS DataEmissaoRPS RazaoSocialPrestador TipoRecolhimento ValorDeduzir ValorTotal Aliquota A minha dúvida é se o componente da ACBr guarda estes valores em propriedades ou eu realmente tenho que ler o XML através da função SeparaDados.

Boa tarde pessoal, Estou fazendo a consulta de RPS por lote, usando o seguinte comando notaNFSe.NFSe.ConsultarLoteRps(Lote, Protocolo), no entanto eu não tenho o XML da nota original para ler no componente assim como esta no exemplo da ACBr. A consulta acontece com sucesso e eu consigo retirar os dados que necessito no XML de retorno que eu leio em notaNFSe.NFSe.NotasFiscais.Items[0].XMLNFSe. Os dados são: InscricaoPrestador NumeroNFe CodigoVerificacao SerieRPS NumeroRPS DataEmissaoRPS RazaoSocialPrestador TipoRecolhimento ValorDeduzir ValorTotal Aliquota No momento estou usando a função SeparaDados para retirar as informações do XML. Gostaria de saber se estes dados estão somente nesse XML ou se tem alguma propriedade com estes nomes em algum lugar. Alguém pode me tirar essa dúvida? Obs.: Tentei usar notaNFSe.NFSe.NotasFiscais.Items[0].NFSe.Prestador.InscricaoMunicipal mas sempre esta vazio, se não me engano ele só carrega quando se faz o load do XML original.

Bom dia Italo, É verdade, realmente eu estava com o meu arquivo Cidades.ini desatualizado. Mas só a título de conhecimento, eu recebi novas informações no grupo de discussão de NFSe da DSF. Me parece que estava funcionando as duas URL, tanto com HTTP como HTTPS, mas após uma modificação na API o ambiente HTTP ficou com problemas e não conseguiram arrumar até o momento. Não sei se deixaram somente o HTTPS daqui para frente ou se vão restabelecer o ambiente HTTP novamente. Após o UPDATE do ACBrInstall_Trunk2 fiz os testes novamente tanto no exemplo como na aplicação do nosso ERP e esta tudo funcionando.

Segue anexo o arquivo. Alterei somente as linhas 1470 e 1471. Não sei se as demais cidades da DSF também sofreram alterações. Cidades.ini

Consegui fazer funcionar Juliomar, a DSF e a prefeitura de Uberlândia não tem um canal muito bom para comunicação de alterações. Através de um grupo de discussão descobri que os webservices mudaram na semana passada: Antes: http://udigital.uberlandia.mg.gov.br Agora: https://udigital.uberlandia.mg.gov.br Basta editar o arquivo cidades.ini e alterar. De qualquer maneira obrigado pela ajuda.

Tentei e não funcionou. Eu estou usando o libCapicomDelphiSoap por que é o SSLIB configurado para NFe e esta funcionando normalmente. O normal seria voltar qual valor para FpHTTPResultCode ? Tem mais algum teste que eu possa realizar aqui?

Quando o botão "Enviar Lote RPS (Enviar)" é acionado o sistema chama a modal para inserir a senha do certificado normalmente. Verificando o arquivo "1-env-lot.xml" (ver anexo) me parece assinado corretamente também. 1-env-lot.xml

Juliomar, o certificado esta configurado assim:

Estou implementando o ACBrNFSe para o provedor DSF (em Uberlândia) para substituir o acesso via DLL em um sistema ERP. Inicialmente estou configurando e testando tudo via ACBrNFSe_Exemplo. Todos os parâmetros do exemplo foram configurados, arquivos ISSDSF.ini, Cidades.ini, ReqEnvioLoteRPS.xsd, Tipos.xsd e xmldsig-core-schema_v1.01.xsd foram colocados na raiz do projeto ACBrNFSe_Exemplo. A procedure TfrmACBrNFSe.AlimentarNFSe foi alterada com os parâmetros de um RPS de testes. Ao utilizar o botão "Enviar Lote RPS (Enviar)" é retornado uma mensagem de erro vazia, como mostrado na figura: Depurando o código temos os seguintes retornos para estas variáveis: FpHTTPResultCode volta 200 InternalErrorCode volta 0 Na raiz do diretório do projeto ACBrNFSe_Exemplo, o arquivo 1-env-lot.xml (foi colocado como lote 1 para testes) tem o RPS 7 com todos os dados corretos e assinado, e o arquivo 1-rec.xml tem o seguinte conteúdo: Arquivo_como_anexado_fica_melhor.xml Alguém poderia me dizer o que pode estar acontecendo? Por que esta retornando vazio? O FpHTTPResultCode 200 necessariamente seria um erro?

Configurei o ACBrNFSe_Exemplo para emitir NFSe no provedor DSF (em particular a prefeitura de Uberlândia), no início os testes foram OK, mas quando consegui começar a emitir lotes de teste começou a aparecer um problema na validação de um XSD. A mensagem de erro que aparece é essa: Comecei a depurar e cheguei na unit ACBrDFeXsMsXml, mais precisamente na função TDFeSSLXmlSignMsXml.Validar: function TDFeSSLXmlSignMsXml.Validar(const ConteudoXML, ArqSchema: String; out MsgErro: String): Boolean; var DOMDocument: IXMLDOMDocument2; ParseError: IXMLDOMParseError; Schema: XMLSchemaCache50; AXml: String; ResultInitialize: HRESULT; Inicializado: Boolean; begin Result := False; ResultInitialize := CoInitialize(nil); if (ResultInitialize = E_FAIL) then raise EACBrDFeException.Create('Erro ao inicializar biblioteca COM'); Inicializado := (ResultInitialize in [ S_OK, S_FALSE ]); try DOMDocument := CoDOMDocument50.Create; Schema := CoXMLSchemaCache50.Create; try DOMDocument.async := False; DOMDocument.resolveExternals := False; DOMDocument.validateOnParse := True; // Carregando ConteudoXML em XMLDOC. Nota: IXMLDOMDocument2 deve usar a String Nativa da IDE // {$IfDef FPC2} AXml := ACBrUTF8ToAnsi(ConteudoXML); {$Else} AXml := UTF8ToNativeString(ConteudoXML); {$EndIf} if (not DOMDocument.loadXML(WideString(AXml))) then begin ParseError := DOMDocument.parseError; MsgErro := ACBrStr('Não foi possível carregar o arquivo.')+sLineBreak+ 'Err: '+IntToStr(ParseError.errorCode) + ', ' + 'Lin: '+IntToStr(ParseError.line) + ', ' + 'Pos: '+IntToStr(ParseError.linepos) + ' - ' + String(ParseError.reason); exit; end; Schema.add(WideString(FpDFeSSL.NameSpaceURI), ArqSchema); <<<--- CHAMADA QUE GERA A EXCEÇÃO DOMDocument.schemas := Schema; ParseError := DOMDocument.validate; Result := (ParseError.errorCode = 0); MsgErro := String(ParseError.reason); finally ParseError := nil; DOMDocument := nil; Schema := nil; end; finally if Inicializado then CoUninitialize; end; end; No momento em que o depurador passa a linha "Schema.add(WideString(FpDFeSSL.NameSpaceURI), ArqSchema);" o delphi lança uma "excepiton". O valor das variáveis são os seguintes: FpDFeSSL.NameSpaceURI := 'http://localhost:8080/WsNFe2/lote' ArqSchema := 'D:\Install\Componentes\ACBr\Exemplos\ACBrDFe\ACBrNFSe\Delphi\ReqEnvioLoteRPS.xsd' O conteúdo de ReqEnvioLoteRPS.xsd é: <xs:schema xmlns:tipos="http://localhost:8080/WsNFe2/tp" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ns1="http://localhost:8080/WsNFe2/lote" targetNamespace="http://localhost:8080/WsNFe2/lote"> <xs:import namespace="http://localhost:8080/WsNFe2/tp" schemaLocation="Tipos.xsd" /> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema_v1.01.xsd" /> <xs:element name="ReqEnvioLoteRPS"> <xs:annotation> <xs:documentation>Schema utilizado para envio de lote de RPS.</xs:documentation> <xs:documentation>Este Schema XML é utilizado pelos prestadores de serviços para substituição em lote de RPS por NFS-e. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Cabecalho"> <xs:annotation> <xs:documentation>Cabeçalho do Lote.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="CodCidade" type="tipos:tpCodCidade" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation>Informe o Codigo da Cidade no Padrão SIAFI. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CPFCNPJRemetente" type="tipos:tpCPFCNPJ" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> CNPJ do contribuinte ou CPF do Responsável Legal autorizado a entregar o lote. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="RazaoSocialRemetente" type="tipos:tpRazaoSocial" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe o Nome do Contribuinte ou do Responsável Legal </xs:documentation> </xs:annotation> </xs:element> <xs:element name="transacao" type="xs:boolean" default="true" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe se os RPS a serem substituídos por NF-e farão parte de uma mesma transação. True - Os RPS só serão substituídos por NF-e se não ocorrer nenhum evento de erro durante o processamento de todo o lote; False - Os RPS válidos serão substituídos por NF-e, mesmo que ocorram eventos de erro durante processamento de outros RPS deste lote. Por definição estão sendo aceitos apenas lotes com RPS válidos, o lote é recusado caso haja algum RPS inválido. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="dtInicio" type="xs:date" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe a data de início do período transmitido (AAAA-MM-DD). </xs:documentation> </xs:annotation> </xs:element> <xs:element name="dtFim" type="xs:date" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe a data final do período transmitido (AAAA-MM-DD). </xs:documentation> </xs:annotation> </xs:element> <xs:element name="QtdRPS" type="tipos:tpQtdRpsLote" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe o total de RPS contidos na mensagem XML. OBS: O xml não pode ultrapassar o tamanho maximo de 500kb. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="ValorTotalServicos" type="tipos:tpValor" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe o valor total dos serviços prestados dos RPS contidos na mensagem XML. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="ValorTotalDeducoes" type="tipos:tpValor" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe o valor total das deduções dos RPS contidos na mensagem XML. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Versao" type="tipos:tpVersao" fixed="1" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation> Informe a Versão do Schema XML utilizado. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="MetodoEnvio" type="tipos:tpMetodoEnvio" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation>Informe o Método de Envio</xs:documentation> </xs:annotation> </xs:element> <xs:element name="VersaoComponente" type="tipos:tpVersaoComponente" minOccurs="0" maxOccurs="1"> <xs:annotation> <xs:documentation>Versão da DLL de envio de lote. Não é necessário informar esse campo caso não utilize a DLL. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Lote" type="tipos:tpLote" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation>Informe os RPS a serem substituidos por NF-e.</xs:documentation> </xs:annotation> </xs:element> <xs:element ref="ds:Signature" minOccurs="0" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> A exceção é gerada devido ao sistema encontrar um tipo não declarado, mas pelo que eu vejo no XSD me parece correto. O que pode estar acontecendo? Descobrimos o problema, no diretório raiz do exemplo faltou dois XSD que estavam em um subdiretório, e isso gerou o erro. Corrigimos colocando todos no mesmo diretório raiz do exemplo. Vlw galera!

Funcionou BingWings, realmente tem alguma coisa diferente nos schemas disponibilizados pela ACBr. Eu sempre pensei que os schemas vindos da ACBr ou do site do Sefaz fossem os mesmos. Como eu nem sempre atualizo o ACBr, somente faço isso quando necessário, sempre atualizei schemas via site do Sefaz. Valeu a ajuda, foi TOP!

Existe algum mais recente ou somente documentações anexas? Fiz o teste com o método Validar, e ele não retorna nenhum erro. Quem realmente esta retornando o erro é o SEFAZ. Eu sobre escrevi os schemas (PL_009_V4_00_NT_2019_001_v1.20a) mais atualizados no site do http://www.nfe.fazenda.gov.br/ e continua dando o mesmo erro. Tentei enviar como fgtNunca e também foi rejeitado: 938-Rejeicao: Nao informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet - [nItem:1] O interessante é que agora ele diz que falta o vICMSSubstituto também, só pode ser uma piada. Muito estranho.

Refiz os testes e continua dando o mesmo erro: Element '{http://www.portalfiscal.inf.br/nfe}vICMSSubstituto' is unexpected according to content model of parent element '{http://www.portalfiscal.inf.br/nfe}ICMS60'. Expecting: {http://www.portalfiscal.inf.br/nfe}vICMSSTRet. Procurei no manual e vendo essa grupo ICMS60, notei que realmente ele não tem a tag vICMSSubstituto. Estou usando a configuração do ForcarGerarTagRejeicao938 como fgtSempre. Tentei como fgtNunca, mas ai ele retira as tags vBCSTRet e vICMSSTRet. <ICMS> <ICMS60> <orig>0</orig> <CST>60</CST> </ICMS60> </ICMS> Não sei realmente o por que esta colocando a tag vICMSSubstituto, e também não sei como forçar para que não gere e testar. Vc saberia como eu posso evitar a inserção desta tag para que eu faça um teste?