Italo Giurizzato Junior

Bom dia Paulo, Os arquivos XSD (Schemas) não tem nada haver com a gravação do XML em disco e sim com a validação do mesmo antes do envio para SEFAZ. Os Schemas da NFC-e são exatamente os mesmos da NF-e e você encontra todos eles na pasta: ...\Exemplos\ACBrDFe\Schemas\NFe Se o XML não foi gravado no disco isso significa que o componente não esta configurado para gravar. Configuracoes.Arquivos.Salvar := True; Espero ter ajudado.

Tiago, Favor atualizar os fontes e realizar um novo teste usando o método Gerar.

Bom dia Sidnei, Alguns provedores possui um layout para o RPS no formato TXT e outro para o RPS no formato XML. Pode ser que o layout que consta na documentação disponibilizada em FGMaiss1.rar seja no formato TXT. Vamos aguardar. Pois seria uma tremenda sacanagem (para não escrever outra coisa) eles pegarem um manual feito pela ABRASF e colocar o logo deles e disponibilizar no próprio site induzindo a todos que eles seguem o layout da ABRASF.

Bom dia Dercide, Você passou um numero inteiro não negativo como numero de lote?

Bom dia Tiago, O provedor WebISS possui 2 Web Services para recepcionar os RPS: EnviarLoteRps e GerarNFSe. Até então nos seus testes você estava usando o método Enviar que se utiliza do Web Service EnviarLoteRps. Utilize o método Gerar, este utiliza o Web Services GerarNFSe. Quais são as diferenças? O EnviarLoteRps aceita um lote contendo de 1 até 50 RPS, já o GerarNFSe aceita o envio de apenas 1 RPS. Ao enviar o RPS para o Web Service EnviarLoteRPS temos como resposta o numero de protocolo de recebimento, depois temos que consultar a situação do Lote e caso ele tenha sido processado realizamos uma nova consulta, caso tenha sido processado com sucesso a resposta dessa ultima consulta é o XML da NFS-e. Por outro lado ao enviar o RPS para o Web Service GerarNFSe temos como resposta o XML da NFS-e isso se o processamento imediado do RPS foi realizado com sucesso.

Bom dia Nelson, Mas o arquivo FGMaiss1.rar que você anexou no dia 26 de janeiro sugere um layout totalmente diferente. Pede para esse pessoal, os schemas de validação, o namespace, as URLs de homologação e de produção e XML exemplo de RPS a ser enviado para o web service a fim deste processar e retornar o XML da NFS-e. Sem isso não da para confiar em um manual da ABRASF onde eles incluíram o logo deles.

Boa noite a todos, Favor atualizar os fontes e realizar novos testes.

Boa noite Tiago, Você tem certeza que todos os arquivos de todas as pastas estão atualizados? Esse erro de URL não definida esta estranha. Você abriu o arquivo 27-sit.xml ? Se sim notou que a situação do lote é 2 ? Ao consultar a situação do Lote podemos ter 4 respostas diferentes: Situação: 1 = Não Recebido 2 = Não Processado 3 = Processado com Erro 4 = Processado com Sucesso No seu caso o lote ainda não foi processado. Alguns provedores passam o dia recebendo os lotes, para processa-los durante a madrugada e portanto disponibilizar as notas no dia seguinte. Será que o WebISS não funciona desta forma?

Boa tarde Claudemir, O seu contador esta interpretando a coisa de forma errada. Lembre-se uma coisa é o campo e outra é o seu conteúdo. Nesse primeiro momento a SEFAZ esta validando a presença do campo e a partir de 04/2016 será validado também o seu conteúdo.

Boa tarde Rodnei, Você não tem o arquivo de retorno?

Bom tarde Jorge, Sim, existe uma propriedade de configuração: ConsultaLoteAposEnvio que deve receber o valor True para que a consulta seja feita de forma automática.

Marco, O pessoal esta preparando uma nova versão do ACBrInstall_Trunk2 que vai permitir a compilação e instalação do ACBrGNRE. A impressão das Guiais ainda não pois esta em fase de migração para o Trunk2.

Boa tarde Marco, Os fontes do componente ACBrGNRE - Trunk2 já podem ser compilados e instalado no Delphi. O que precisa fazer agora é iniciar os testes e fazer as devidas correções.

Tiago, Você realizou as consultas que lhe pedi? Você esta consultando a NFS-e por RPS, ou seja, usando o método ConsultarNFSeporRps. Eu quero que você consulte a situação do lote, ou seja, usar o método ConsultarSituacao(Protocolo); E depois consultar o lote de RPS através do método: ConsultarLoteRps(Lote, Protocolo); Para saber se o lote foi processado ou não temos que consultar a situação do mesmo. Se foi processado com erro (que é o que acredito), para saber o motivo do erro temos que consultar o lote de RPS. Sem realizar essas duas consultas você não vai sair do lugar.

Boa tarde Marcos, Muito obrigado pela colaboração, fiz umas modificações na sua correção. Já esta disponível, pode atualizar os fontes e testar novamente.

Boa tarde Tiago, E a consulta a situação do lote? Se não existe uma nota para o RPS informado pode ser que a situação do lote seja 3, ou seja, processado com erro? E a consulta ao lote de RPS? No retorno dessa consulta deve constar o motivo da rejeição do RPS.

Bom dia Raylan, Essas duas propriedades foram criadas por causa de alguns provedores que não são capazes de seguir a risca um layout e acabam acrescentando essas coisas absurdas no XML. A principio deixe em branco se o provedor recusar por falta dessas informações ai sim você as informa.

Tiago, E os XML referente a consulta, não estão sendo salvos em disco? Se sim, anexa para que eu possa verificar.

Bom dia a todos, O Provedor Pronim resolveu mudar de versão? Se sim, essa mudança é para todas as cidades? Neste caso precisamos dos novos Schemas.

Pessoal, Não existe o SVC para o MDF-e. No meu entendimento, o MDF-e por não ser um documento que contem valor, trata-se apenas de um agrupador de documentos, a sua impressão em contingência pode ser feita em papel comum, não havendo a necessidade de papel moeda.

Bom dia Wislei, Vamos analisar o problema.

Bom dia a todos, Lembrem-se que todos os Estados brasileiros se utilizam da SEFAZ-RS para enviar o MDF-e e seus respectivos eventos: Encerramento, Cancelamento, etc. Logo não é a SEFAZ-MG ou outra com problema e sim a SEFAZ-RS.

Dercide, O método Enviar se utiliza do web service EnviarLoteRps cujo modo de acesso é assíncrono, ou seja, o retorno desejado que é o XML da NFS-e demora, pois é preciso após o envio, consultar a situação do lote para saber se o mesmo já foi processado ou não se sim ai sim consultar o Lote, é nesta consulta que obtemos o XML da NFS-e caso o lote tenha sido processado com sucesso. O Lote do método Enviar pode conter de 1 até 50 RPS. Por outro lado o método Gerar se utiliza do web service GerarNFSe cujo modo de acesso é síncrono, ou seja, já temos o que desejamos logo no retorno dele que neste caso é o XML da NFS-e, logo não se faz necessário executar nenhum método de consulta. O método Gerar só pode conter apenas 1 RPS, com exceção dos provedores BHISS e WebISS (até o momento) que aceitam até 3 RPS.

Bom dia Dercide, Quem lhe passou essa informação, esta completamente por fora. O provedor BHISS não possui o serviço EnviarSincrono e sim o GerarNFSe que diferente dos demais permite enviar até 3 RPS sendo que o normal é apenas 1. Você pode comprovar isso, procurando pela palavra sincrono no Schema do respectivo provedor ou digitando a URL de homologação ou de produção no navegar e por fim procurar pelo serviço EnviarLoteRpsSincrono, não vai achar. No componente para o provedor BHISS você pode usar os métodos Enviar ou Gerar, sendo que este último como dito vai permitir um lote com até 3 RPS.

Bom dia Tiago, Se esta configurado para consultar após o envio e esta aparecendo um erro em branco é preciso "debugar", pois deveria pelo menos salvar o XML da consulta e isso não esta ocorrendo. O retorno após o envio esta correto, ou seja é retornado o numero do protocolo que atesta que o lote foi recebido com sucesso. Se o componente estiver configurado para realizar a consulta, ele deve se utilizar do numero do protocolo para consultar a situação do lote.