Italo Giurizzato Junior

Boa tarde Dênio, Primeiramente quando postar alguma rotina favor postar como anexo para que o post não fique longo demais como ficou o seu. Segundo porque você não utiliza a formatação de um arquivo INI, algo do tipo: [Lote] Numero=22 Cnpj=17512294000133 InscricaoMunicipal=123456789 QuantidadeRps=2 [RPS01] RpsId=rps:41 Numero=4 Serie=1 (...) [RPS02] RpsId=rps:51 Numero=5 Serie=1 (...) E utilize as functions nativas do Delphi para ler os campos do arquivo, acredito que desta forma vai ficar mais simples a sua rotina.

Boa tarde a todos, Asterix, os Schemas tem como finalidade validar o XML gerado pela sua aplicação antes de ser enviado para SEFAZ. Pelo que estou entendendo o envio esta ocorrendo logo não se trata de um erro na montagem do XML. Se a Graça gerar o XML da NF-e na versão 3.10 e utilizar um conjunto de Schemas desatualizado ou da versão 2.00 ou 3.00 por exemplo, com certeza ela teria uma exceção com o erro de validação. Muito estranho você estar tendo um retorno contendo o Status 999 e ela o retorno vem em branco, mesmo fazendo a alteração que sugeri. Bom, se o Obelix não vai poder ajudar é melhor começar a rezar para o Santo Byte.

Boa tarde Lopes, Não tive nenhum problema apontado por você nos meus testes. Qual é a SEFAZ autorizadora?

Boa tarde Ricardo, Enviei para o SVN a alteração proposta pelo André.

Boa tarde Maikon, Já faz um bom tempo que fizemos uma alteração no componente migrando a cidade de Mirassol/SP do provedor GovBR para Pronim. Certifique-se se todos os fontes estão atualizados e se utilize dos Schemas que encontra-se na pasta Pronim para realizar a validação do lote de RPS.

Bom dia Luiz, Dependendo se o Canhoto é impresso em cima ou em baixo, se o CT-e é carga fracionado ou lotação, dependendo da combinação ocorre esse erro na quantidade de páginas. Ainda não consegui identificar onde que esta provocando isso, mas estamos consciente dele e estamos trabalhando para tentar corrigir.

Bom dia Rodrigo, No segundo caso a nota não foi validada pelo componente ou foi rejeitada pela SEFAZ?

Bom dia Asterix, Na verdade o consultar status do serviço não serve para nada, somente para saber se essa funcionalidade esta funcionando. Digo isso, pois ela não retorna o status dos demais serviços. Para você ter uma ideia a SEFAZ já cogita em remover essa funcionalidade. Se ao enviar você obter como retorno o Status = 999 isso significa que o Web Service esta com problemas e não tem nada haver com o seu XML.

Bom dia Graça e Juliomar, Mil desculpas, disponibilizei antes de testar aqui. Muito obrigado Juliomar pela correção.

Bom dia Graça, No modo Assíncrono temos inicialmente o retorno do numero do recibo para depois termos o retorno do protocolo de autorização caso o processamento tenha ocorrido com sucesso. Necessito saber se nesse modo de envio você esta obtendo o recibo? Se sim, o problema esta no arquivo -pro-rec.xml que esta vazio, correto? Neste caso sugiro que você abra o fonte: ACBrNFeWebServices.pas e altere a linha 2332: if FConfiguracoes.Geral.Salvar then begin FPathArqResp := Recibo+'-pro-rec.xml'; FConfiguracoes.Geral.Save(FPathArqResp, FRetWS); <---- linha 2332 end; if FConfiguracoes.Geral.Salvar then begin FPathArqResp := Recibo+'-pro-rec.xml'; FConfiguracoes.Geral.Save(FPathArqResp, FRetornoWS); end; Essa alteração de FRetWS para FRetornoWS vai fazer com que o componente salve em disco o XML na integra retornado pelo WebService. Com isso temos como verificar o que esta ocorrendo. Por favor faça isso e post em anexo o -prorec.xml

Bom dia Gill, Se possível post como anexo tanto o XML do RPS quanto o da NFS-e para que eu possa verificar.

Antonio, Se possível post como anexo o XML da NFS-e de Bauru. Eu lhe digo se segue o padrão ABRASF ou não.

Boa tarde Daniel, A rejeição que você se refere é a do título do tópico, correto? Já verificou se o problema não é o credenciamento no ambiente de homologação? Verifique se a empresa referente ao certificado que você esta utilizando esta credenciada nos dois ambientes: homologação e produção.

Boa tarde Antonio, Você chegou a abrir o XML da NFS-e de Bauru utilizando o navegador (Internet Explorer por exemplo) e outro XML de outra cidade por exemplo Araraquara, Ribeirão Preto, São José do Rio Preto? Se não me falha a memória Bauru não segue o padrão ABRASF. O componente atende o padrão ABRASF e DSF.

Boa tarde Dênio, A validação sempre é feita em cima do lote, quanto a assinatura o meu conselho caso você vai desenvolver um monitor é: Em vez da sua aplicação salvar na pasta o XML do RPS, salvar um TXT com os dados do RPS. O monitor lê o TXT alimenta o componente com os dados lidos e se encarrega de fazer o resto. Porque fazer desta forma, pois alguns provedores requerem que o XML do RPS seja assinado e outros não, uns requer que o lote seja assinado e outros não, outros possui algumas particularidades a mais no XML ou até mesmo a inversão de uma TAG em relação a outra. Quanto ao problema com o DANFSE, com certeza você deve ter alguma DCU antiga em alguma pasta que o Delphi esta tendo acesso.

Fernando, Já respondido no outro tópico.

Bom dia Rigotti, Muito obrigado, alteração realizada e disponibilizada.

Bom dia Fernando, Favor atualizar os fontes e testar novamente.

Bom dia Antonio, Você esta carregando o XML do RPS ou da NFS-e? Todos os fontes estão atualizados?

Bom dia Emerson, infEvento.tpEvento := teCCe;

Bom dia Cesar, Os seus testes com a versão 3.10 se refere a UF = 29, ou seja, Bahia, correto? Realizei algumas alterações no componente visando a versão 3.10 da NF-e para a Bahia. Favor atualizar os fontes e realizar os testes.

Boa noite Gill, Você não esta executando o Enviar com o segundo parâmetro valendo true e depois manda executar o Imprimir? O Enviar possui 2 parâmetros sendo que o segundo por padrão vale True isso faz com que assim que ocorre o retorno da NFS-e é impresso o DANFSE. Quanto ao valor da Alíquota: No RPS como deve ser informada: 2,35 ou 0,0235? Na NFS-e retornada pelo provedor como ela aparece: 2,35 ou 0,0235?

Boa noite Marco, Se aparece a mensagem de erro acusando que um identificador não esta definido, isso significa que o a unit onde encontra-se a definição a mesma não foi compilada. Procure sempre compilar com a opção Build. Caso você já tenha feito esse procedimento, com certeza existe uma DCU antiga perdida no HD e o Delphi a esta utilizando em vez da nova.

Boa noite Dênio, Vasculhe o HD da maquina em busca do arquivo qrpt70.bpl se não me falha a memória é esta extensão. Ao encontrar renomeie esse arquivo para qrpt70_xxx, isso deve resolver o problema.

Boa noite Marco, O componente possui na unit pnfsConversao.pas uma function onde informamos o código do serviço e este retorna a sua descrição. O que eu fiz foi possibilitar uma segunda alternativa onde você determina se deseja a descrição que encontra-se na unit ou no arquivo chamado TabServicos.txt O componente agora possui uma propriedade chamada TabServicosExt cujo valor padrão False. Detalhe importante o arquivo TabServicos.txt tem que ser salvo na mesma pasta do executável.