Ir para conteúdo
  • Cadastre-se

andre@prodez

Membros
  • Total de ítens

    93
  • Registro em

  • Última visita

  • Days Won

    1

andre@prodez last won the day on 22 Agosto 2015

andre@prodez had the most liked content!

Últimos Visitantes

1.459 visualizações

andre@prodez's Achievements

Collaborator

Collaborator (7/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

28

Reputação

6

Community Answers

  1. Boa noite Italo. O que ocorreria caso eu executasse a Consulta a Situação do Lote em um provedor que não esteja na versão 1 do layout da ABRASF (esteja na versão 2 por ex.)? Como eu identifico em qual versão determinado provedor está? Obs.: no mesmo sistema eu tb trabalho com o provedor SimplISS. Obrigado, André Luis.
  2. Boa tarde Gabriel. Guarda em propriedades, armazenadas no componente ao Enviar ou Carregar um XML de nota, como por exemplo: acbrNFSe.NotasFiscais.Items[0].NomeArqRps; acbrNFSe.WebServices.EnviarLoteRPS.Protocolo; acbrNFSe.NotasFiscais.Items[0].NFSe.CodigoVerificacao; acbrNFSe.NotasFiscais.Items[0].NomeArq; acbrNFSe.NotasFiscais.Items[0].NFSe.Numero; André Luis.
  3. Boa noite Italo, desculpe a demora em retornar... Sim, ao enviar o lote o provedor retorna o protocolo. Estou conseguindo consultar posteriormente o lote usando o RPS e esse número de protocolo. O que está ocorrendo é que nos casos que ao enviar o lote ele permanece um certo tempo na fila sem processamento, caso nesse meio tempo eu faça uma consulta ao lote, o componente acaba gerando uma exceção indicando como lote processado com erro, veja o erro abaixo retornado pelo provedor (mensagem retornada na exception do ConsultarLoteRps): Na realidade o lote ainda não foi processado e em consultas futuras ele poderá gerar a NFs-e normalmente. Portanto, nessas situações tenho tido dificuldade de diferenciar, após uma consulta, um lote ainda não processado de um de fato processado com erro, pois nas duas situações está gerando uma exceção de erro. O ideal seria a consulta entender isso como lote não processado, mas talvez a forma como o provedor reporta não é possível identificar. Não sei se alguém conseguiu tratar essa situação. Me ocorreu a ideia de tratar de forma manual, testando realmente a string da mensagem procurando pelo texto "Nota nao processada" e, nesses casos, não indicar o RPS como processado com erro, mantendo ele ainda pendente de processamento. Não sei se to falando bobeira...rs. André Luis.
  4. Boa tarde Italo. O problema estava meio absurdo mesmo, não sei se por conta do início das operações semana passada (troca do GINFES pelo ISSNet), mas eu estava com as seguintes configurações nessas propriedades: AguardarConsultaRet: 2000 IntervaloTentativas: 3000 Tentativas: 600; (isso mesmo, 600, o que leva a ficar por 30 minutos tentando, e depois de todo esse tempo retornava um "erro desconhecido" - e o problema era não ter a resposta, pois em testes durante a madrugada funcionava) TimeOut: 60000 Por isso acabei acreditando que a única solução nesse caso seria apenas enviar os RPSs pra depois ir consultando os retornos e gerando a NFS-e... realmente não sei se teria alguma outra saída pra isso. Mas ai surgiu apenas aquela questão que citei acima, sobre o lote estar na fila e qual seria o retorno da consulta nesses casos. De qq forma, muito obrigado pelos retornos. André Luis.
  5. Italo, na verdade, minha preocupação é para seguinte situação: - enviei o RPS para o provedor; - depois de um tempo fiz a consulta ao RPS (usando ConsultarLoteRps por ex.) - caso o lote desse RPS ainda esteja na fila no provedor, ele ainda não foi processado, qual retorno o componente da após executar essa consulta: gera uma exceção (erro); ou faz a consulta sem gerar erro e atualiza as informações de lote não processado. Essa é a minha principal dúvida nisso. Obrigado!!! André Luis.
  6. Bom dia Italo. Obrigado pelo retorno. Para fazer funcionar com o ISSNet passei a usar o componente com a propriedade ConsultaLoteAposEnvio como false; devido ao retorno desse provedor ser muito lento; dai passei a fazer apenas o envio do RPS num primeiro momento. Após isso, libero o usuário pra consultar os RPSs enviados, e faço isso usando direto a função ConsultarLoteRps; - teria algum problema? Nesse caso após executar essa função, pra eu saber se o lote foi processado (independente se com erro ou autorizado) eu posso verificar a propriedade ACBrNFSe.WebServices.ConsLote.LoteNaoProc ? Vi tb que tem a propriedade "Situação" em WebServicess.ConsLote; ou seja o ConsultarLoteRps atualiza essas informações no componente... pois ai nem precisaria passar primeiro pelo ConsultarSituacao... Obrigado!!! André Luis.
  7. Essa informação seria a propriedade : ACBrNFSe.WebServices.ConsLote.LoteNaoProc ? Alguém pode confirmar isso?
  8. Boa tarde pessoal. Estou caminhando aqui... Passei a Enviar o lote sem fazer a consulta logo após o envio... Para consultar o lote posteriormente estou usando a função: ConsultarLoteRps Alguém saberia me dizer como faço para identificar (usando essa função) se um determinado lote ainda não foi processado? Percebi que essa função gera uma exceção qdo a NFs-e contem algum erro, mas qdo o lote ainda não tiver sido processada pelo provedor, ela tb irá gerar exceção ou algum código de erro? A questão seria: tem como diferenciar um "erro na emissão da NFS-e" de um "retorno de lote ainda não processado"? Ou sempre irá gerar uma exceção nos dois casos (não processada / erro) e ficaria a cargo do usuário interpretar a situação através da descrição da mensagem de retorno, seria isso? Por favor, aguardo alguma orientação. Obrigado desde já. André Luis.
  9. Bom dia pessoal. Alguém já conseguindo emitir NFs-e para Ribeirão Preto com ISSNet de uma forma que funcione? Obrigado!!!
  10. Bom dia Juliomar, obrigado pelo retorno. Sim olhei os tópicos. Dei uma boa pesquisada no forum; eu já utilizo os componente ACBrNFSe para emissão da nota, fiz a implementação já faz um bom tempo, na época segui os fontes de exemplo; sempre funcionou certinho com o GINFES; mas com o ISSNet me parece que o tempo de resposta deles é muito lento e talvez a forma como estou trabalhando não seja adequada. Por isso estou pedindo ajuda para alguém que já esteja conseguindo emitir a NFS-e de Ribeirão Preto com o ISSNet, postei acima o esqueleto de como implementei (incluindo um txt com o fonte de como configuro o componente); pra ver se alguém me dar um norte de qual é a forma correta de trabalhar com esse provedor. Por favor, se alguém puder me ajudar agradeço muito... Obrigado. André Luis.
  11. Boa noite pessoal. Já deixo aqui meus agradecimentos a quem puder me ajudar. Estou tendo dificuldades com a emissão da NFS-e para o novo provedor em Ribeirão Preto - o ISSNet. Não sei se todos já conseguiram fazer seus sistemas funcionarem nesse novo provedor. Eu ainda não, infelizmente. No GINFES sempre trabalhei enviando o RPS e aguardo o retorno do XML aprovado da nota, esse processo sempre se resolveu em alguns segundos. No ISSNet isso não está ocorrendo, demora cerca de 30 minutos e acaba retornando um erro de nota não processada. Por email, tive um retorno do suporte da Nota Control informando para informar os links de acesso aos Web Services utilizando "https://..."; verifiquei que no aquivo ISSNet.ini todas as urls são informadas apenas com "http://..."; alguém precisou corrigir isso no arquivo ini desse provedor? Será que esse método que uso hj de enviar o RPS e ficar consultando (no mesmo instante) o retorno da nota aprovada não irá funcionar com o ISSNet? Vcs estão trabalhando de forma diferente em seus sistema? Abaixo vou mostrar um esqueleto de como implemento o envio da NFS-e, por favor, se puderem orientar uma forma mais correta que funcione com o ISSNet eu agradeceria muito, pois usava dessa forma com o GINFES e nunca tive problemas (isso já a muito tempo): //carrega as configuracoes para o Componente ConfigurarNFSe; //carrega os dados da NFS-e para o Componente CarregarNFSe; //envia o RPS para o provedor acbrNFSe.Enviar(QryNotasSe.FieldByName('NumRPS').AsInteger, false); //armazena as informacoes retornadas apos envio do RPS e autorizacao da NFS-e if acbrNFSe.NotasFiscais.Items[0].NFSe.Numero <> '' then begin QryNotasSe.FieldByName('NumNF').AsString := acbrNFSe.NotasFiscais.Items[0].NFSe.Numero; end; QryNotasSe.FieldByName('CodVerificacao').AsString := acbrNFSe.NotasFiscais.Items[0].NFSe.CodigoVerificacao; QryNotasSe.FieldByName('NrProtocolo').AsString := acbrNFSe.WebServices.EnviarLoteRPS.Protocolo; QryNotasSe.FieldByName('NomeArq').AsString := acbrNFSe.NotasFiscais.Items[0].NomeArq; //grava a NFS-e QryNotasSe.Post; Estou tb anexando um txt com as configurações que utilizo no componente "ACBrNFSe". Por favor, agradeço desde já quem puder apontar o que estou fazendo de errado e me indicar um norte para conseguir emitir NFS-e com esse provedor ISSNet. Obrigado. André Luis. ConfigurarNFSe.txt
  12. Boa tarde pessoal. Tb estou tentando enviar o primeiro teste no ISSNet. Estou com erro na validação da Alíquota do ISS. Sempre alimentava o componente com o valor porcentual, por ex: 5% => 5: ficando: Servico.Valores.Aliquota := 5; ai no XML do RPS ficava 0.0500; No entanto verifiquei olhando o XML do RPS que está ficando o valor sem dividir por 100 => 5.0000; Alguém sabe me dizer se agora é necessário dividir por 100 para alimentar a alíquota no componente para todos os provedores ? obs.: tb trabalho com o SimplISS. Obrigado, André Luis.
  13. Boa tarde Augusto. Base de Cálculo do ICMS = Total dos Produtos + Frete + Seguro + Despesas Acessórias - Descontos André Luis.
  14. Bom dia. Esse tipo de erro é normalmente devido aos schemas desatualizados. Verifique se o arquivo "leiauteNFe_v4.00.xsd" dentro da sua pasta de schemas é da data de modificação 06/05/2019. Att., André Luis.
  15. Bom dia Thiago. Já estou com o layout 4.00 configurado no componente... mesmo assim continua o erro... SEFAZ de SP.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.