Italo Giurizzato Junior

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

Bom dia Willian, Se não me falha a memória a cidade de Camboriú contratou um provedor que não segue o layout da ABRASF, logo a sua implementação se torna demorada.

Bom dia Marcos, O que tudo indica esse provedor segue a versão 2 do layout da ABRASF. Logo será tranquilo a inclusão desse provedor no componente. Esta faltando os schemas para validar o XML antes do seu envio e as URLs dos ambientes de homologação e produção.

Bom dia Leonardo, Você esta com todos os fontes de todas as pastas atualizados? Se não me falha a memória na versão 2.00 do GNRE é possível informar a chave da NF-e.

Boa tarde Thiago, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde a todos, Futuramente ao emitir o MDF-e a SEFAZ vai se encarregar de gerar o CIOT, mas até agora não disse como e quando isso vai ocorrer. Logo devemos usar o componente ACBrCIOT para obter o numero do CIOT que deve ser informado ao emitir o MDF-e através do componente ACBrMDFe.

Boa tarde Marcio, Muito obrigado pela contribuição, já inclui na minha lista de tarefas, assim que possível vou analisar e estando tudo OK, vou enviar para o repositório.

Boa tarde, Já pensou na possibilidade de gerar PDF de lotes de 500 CT-e por vez em vez de 5000 de uma única vez?

Boa tarde Daniel, Neste caso altere o valor de Validar para zero no arquivo INI do provedor, assim não vai ocorrer erro de validação e consequentemente os arquivos serão salvos. Com os arquivos (XML) vai ser possível identificar o problema.

Boa tarde Adalberto, Eu não conheço Java e no meu entendimento não devemos misturar as coisas. Caso você conheça e tiver um tempo para estudar o que o Daniel fez e fazer em Delphi lhe agradeço.

Boa tarde Izaque, Você quer utilizar o ACBrCIOT sem a necessidade do certificado digital, correto? Pois bem, veja a pergunta/resposta numero 12 do artigo:

Bom dia Izaque, Você esta com todos os fontes de todas as pastas atualizados?

Boa tarde, Não faz nenhum sentido informar o mesmo cUnid "N" vezes.

Bom dia Mario, Na sua postagem de Quarta-Feira você anexou o XML exemplo do provedor e o que é gerado pelo componente e diz que são diferentes. É claro que são diferentes, você comparou o XML do RPS gerado pelo componente com o XML de Envio de Lote de RPS fornecido pelo provedor a titulo de exemplo. Como o provedor forneceu o XML de Envio de Lote, é preciso comparar com o XML de Envio de Lote gerado pelo componente. Na imagem que você postou na Sexta-Feira não vejo nada de errado, pelo contrario note que a presença de um form que mostra o Numero do Lote, Data/Hora de recebimento do mesmo pelo provedor, bem como o numero do protocolo que atesta que o Lote foi recebido por ele. Você utilizou o método Enviar, a principio esse método apenas envia o Lote de RPS e não faz mais nada. Se você deseja que o componente execute todo o fluxo deve atribuir o valor True a propriedade de configuração: ConsultaLoteAposEnvio. Ou após executar o método Enviar, execute o método ConsultarSituacao e se a situação for 3 ou 4 executar o método ConsultarLote para obter a lista de rejeições caso a situação seja 3 ou obter o XML da NFS-e caso a situação seja 4.

Bom dia Anderson, A dica é o seguinte: Abra o arquivo INI do respectivo provedor que se encontra na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI No caso do ISSDSF.ini temos o seguinte, as seções: [ConsSit], [Gerar], [RecSincrono] e [Substituir] não tem o Envelope definido. [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1= Por outro lado as seções: [Recepcionar], [ConsLote], [ConsNFSeRps], [ConsNFSe] e [Cancelar] o Envelope esta definido. [ConsLote] IncluiEncodingCab=0 IncluiEncodingDados=0 TagGrupo=ReqConsultaLote TagElemento= DocElemento= InfElemento=Lote Texto1=<soapenv:Envelope xmlns:dsf="http://dsfnet.com.br" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> Texto2=<soapenv:Body> Texto3=<dsf:consultarLote soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> Texto4=<mensagemXml>%DadosMsg%</mensagemXml> Texto5=</dsf:consultarLote> Texto6=</soapenv:Body> Texto7=</soapenv:Envelope> Resumindo, para o provedor ISSDSF devemos: Usar o método Enviar (se utiliza do envelope definido na seção [Recepcionar]) para enviar o RPS para o webservice. O método ConsultarLote para consultar o resultado do processamento de um Lote de RPS enviado (se ocorreu falha no processamento será retornado a lista de rejeições, caso contrario será retornado o XML da(s) NFS-e). O método ConsultarNFSePorRPS para consultar o resultado do processamento de um RPS enviado (se ocorreu falha no processamento será retornado a lista de rejeições, caso contrario será retornado o XML da NFS-e). O método ConsultarNFSe para obter o XML da NFS-e informando o numero e serie da mesma. O método Cancelar para realizar o cancelamento de uma NFS-e. O arquivo INI do provedor lhe da o caminho das pedras.

Boa tarde Delcio, Se ocorreu a rejeição 682, significa que a sua aplicação esta permitindo que o usuário inutilize um numero mais de uma vez. É preciso ter uma tabela no banco de dados para controlar os números que foram inutilizados.

Bom dia Carlos, A cidade de Volta Redonda/RJ mudou de provedor? No arquivo Cidades.ini consta que o provedor é ISSNet.

Bom dia, Já coloquei na minha lista de tarefas, assim que possível vou analisar o que você já fez e fazer os ajustes necessários.

Verifique se nessas maquinas que estão ocorrendo o problema, não foi alterado alguma propriedade de configuração. Como por exemplo a versão e as configurações do certificado SSLLib, etc.

Boa tarde, Esse provedor é muito sem noção. Dois SoapAction um para homologação e outro para produção, em vez de um só. Incluir o nome da cidade na URL do SoapAction. Incluir o nome da cidade no NameSpace do XML. Tudo para ajudar. Não é a toa que ganharam a Licitação, fizeram uma porcaria, um webservice com apenas 4 serviços. Já descobri a URL de homologação correta. https://www.geisweb.com.br/homologacao/modelo/webservice/GeisWebServiceImpl.php Veja se eles tem XMLs (de envio, consulta e cancelamento) de exemplos.

Boa tarde Bruno, Não, somente eFrete. Estou aguardando as contribuições para os demais.

O seu GNRE foi rejeitado, pela mensagem ocorreu um erro quando o webservice tentou validar o XML. Algum campo deve estar faltando, pois não encontrei nenhum com o valor ".00"

Boa tarde, Não sei o que você esta fazendo de errado, mas acabo de fazer um teste tanto no ambiente de homologação, quando o de produção, veja os resultados: Inicio TMDFeStatusServico Versão Layout: 3.00 Ambiente: 2 Versão Aplicativo: RS20191021102650 Status Código: 107 Status Descrição: Servico em Operacao UF: SP Recebimento: 07/07/2020 15:50:56 Tempo Médio: 1 Retorno: Observação: Inicio TMDFeStatusServico Versão Layout: 3.00 Ambiente: 1 Versão Aplicativo: RS20191021102650 Status Código: 107 Status Descrição: Servico em Operacao UF: SP Recebimento: 07/07/2020 15:51:10 Tempo Médio: 1 Retorno: Observação:

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

Boa tarde, Esse erro esta ocorrendo no envio ou no retorno? Você utiliza o componente ACBrGNRE?