Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    42.684
  • Registro em

  • Última visita

  • Days Won

    1.241

Tudo que Italo Giurizzato Junior postou

  1. Bom dia Marcelo, Por favor, procure sempre postar alterações/correções e sugestões em fontes, postando como anexo o fonte alterado. Fica mais fácil realizarmos um merge.
  2. Bom dia Renato, Podemos concluir que emitir a NFS-e via Site é uma coisa, pelo Web Service é outra. Rotinas diferentes, requisitos diferentes, portanto sem nenhuma padronização, depois vem o cliente e diz pelo site da para fazer pelo seu programa não.
  3. Bom dia, Sem os schemas, Name Space, URLs dos ambientes de Homologação e Produção utilizados pelo provedor, não tem como implementar.
  4. Bom dia Jorge, Esse aplicativo X, você sabe me dizer se ele utiliza o componente ACBrNFe para emitir NF-e?
  5. Bom dia Caejr, Você utiliza o componente ou o Monitor? Se é o componente, qual é o Report utilizado para imprimir o DANFE?
  6. Bom dia a todos, Evitem ao máximo o uso do Consultar Status para uma tomada de decisão automática. A SEFAZ cogita em acabar com esse Web Services. Segundo a SEFAZ o caminho é: 1. Tentar enviar para o Web Service que recepciona a NF-e/NFC-e 2. Se falhar o envio, consultar o status do SVC 3. Se ativo, enviar a NF-e/NFC-e para o SVC. A volta: 1. Tentar enviar para o SVC. 2. Se falhar o envio, enviar para o Web Service que recepciona a NF-e/NFC-e
  7. Bom dia Daniel, No meu entendimento, se a nota esta sendo emitida para um destinatário (consumidor final) devemos atribuir o valor cfConsumidorFinal caso contrario cfNao, não importa o que o destinatário vai fazer com os itens adquiridos. Lembrando que se tradando de NFC-e: indFinal sempre será cfConsumidorFinal. Acredito que no caso da NF-e o indFinal poderá receber um dos dois valores, visto que não encontrei nenhuma regra na Nota Técnica 2013/005 versão 1.03, que impede o uso do valor cfConsumidorFinal para uma NF-e.
  8. Bom dia Jorge, Acredito que no ambiente de homologação a SEFAZ não realiza todas as validações que são realizadas no ambiente de Produção. Dai o motivo de enviar uma nota em ambiente de homologação e ela ser aceita e a mesma nota em produção não ser.
  9. Bom dia Mary, Todos os fontes da pasta PCN2 estão com o seu ícone uma bolinha verde? Tentou compilar o pacote do PCN2 com a opção Build?
  10. Bom dia André, O problema não é os schemas, uma vez que os mesmos são os mesmos tanto para o ambiente de homologação quanto o de produção. O ACBrNFeMonitor se utiliza dos schemas para validar o XML da NF-e que foi gerada e não o cancelamento ou a consulta. Lembre-se que se estiver funcionando o ambiente de homologação não significa que esta funcionando o de produção. Esquece também o Consultar Status, pois este pode retornar que o serviço esta em operação, mas quem garante que essa resposta se refere a todos os Web Services do ambiente selecionado. Como algumas SEFAZ implementaram Web Services específicos para a versão 3.10, estes podem estar com algum problema.
  11. Bom dia a todos, Como a viagem de volta com o resíduo é paga, acredito que o caminho seja esse mesmo. O Destinatário emitir uma Nota Fiscal de devolução e a transportadora emitir o CT-e informando essa nota como documento originário. No meu entendimento para a transportadora não muda nada pois ela vai pegar uma carga emitir um CT-e com base em um documento originário (nota fiscal) e transportar essa carga do ponto A até o ponto B. Entendo como Redespacho como sendo passar a carga para outra transportadora para que esta de continuidade ao transporte da mesma, exemplo: Transportadora 1 transporta a carga do ponto A até B e esta é redespachada pela Transportadora 2 que vai transportar do ponto B até C.
  12. Boa tarde André, Esta com os fontes atualizado?
  13. Boa tarde Rick, Muito obrigado pela colaboração, já esta disponível.
  14. Boa tarde Thales, A coisa que eu mais quero é que a SEFAZ tome as rédias da NFS-e e passe a recepcionar esse modelo de documento fiscal também e depois repasse para as prefeituras. Ai meu caro, teremos um padrão em todo o território nacional e não essa zorra que é hoje. E essa cambada de mau educados vão ficar chupando o dedo. E lhe digo mais, não é sonho não, já existem indícios que isso vai ocorrer.
  15. Boa tarde a todos, Vanessa, lembre-se que o modo Síncrono foi criado para atender as necessidades da NFC-e. Sendo assim fica a critério de cada SEFAZ implementar essa possibilidade para NF-e ou não. Outra coisa importante, no modo Síncrono o lote só pode conter apenas uma Nota. Detalhe, o retorno da SEFAZ no modo Síncrono logo após o envio do lote, poderá não conter o numero do recibo e sim o protocolo de autorização juntamente com as demais informações. Alexandre, inclui as URLs de produção da SEFAZ-PR esta semana se não me falha a memória, você atualizou os fontes?
  16. Boa tarde Ricardo, Nota Técnica 2013/005 Versão 1.03 Quanto ao componente: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve310;
  17. Boa tarde, O arquivo <chave>-CTeDFe.XML só é gerado quando se realiza uma consulta e se o CT-e possuir eventos vinculados ao mesmo, caso contrario ele não é gerado.
  18. Boa tarde João, Depois do envio do evento a SEFAZ retornou o protocolo de evento registrado e vinculado ao CT-e? Se sim, fique tranquilo. Com certeza o problema é o site que não contempla a visualização de todas as correções.
  19. Boa tarde AAldenor, Favor entrar em contato com a prefeitura ou com o provedor e solicitar um XML de exemplo completo ou seja com as TAGs do Soap.
  20. Boa tarde Roger, Depende do provedor, uns temos que informar 4,26 mesmo outros 0,0426.
  21. Junior, Estou estudando a melhor forma de se fazer isso.
  22. Bom dia Wanderson, Todos os fontes de todas as pastas estão atualizados? Se sim, o componente ACBrNFe agora possui uma propriedade nova: ACBrNFe.Configuracoes.WebServices.Salvar := False | True; (False é o valor padrão) Se alterarmos esse valor para True será gravado tanto os arquivos de envio como de retorno com as TAGs do Soap. Neste caso teremos o arquivo, por exemplo: 130000004259370-pro-rec-soap.xml Atualize os fontes se necessário, atribua o valor True a propriedade acima e realize os testes novamente. Post como anexo o arquivo: <numrecibo>-pro-rec-soap.xml
  23. Bom dia Ricardo, Você realizou testes no ambiente de homologação depois do dia 30/11/2013 (data que foi feita a alteração das cifras no ambiente de homologação)? Funcionou? Se sim, esquece. Se tiver que ser feita alguma alteração será nas opções do Internet Explorer, do resto não muda absolutamente nada.
  24. Bom dia Celso, Desculpe pessoal, esqueci, por favor atualize os fontes.
  25. Bom dia Dêivide, Desculpa, não entendi o que você deseja fazer. Você quer validar o XML que será enviado para SEFAZ para realizar a consulta de um lote de CT-e pelo numero do Recibo (consReciCTe) ? Se sim, não vejo motivo para isso, pois esse XML tem meia-duzia de linhas e não tem variações, diferente do XML de envio de um lote de CT-e, que pode ter centenas de linhas e com variações. Se você utiliza o componente ACBrCTe, mais um motivo para não se preocupar com isso, pois todos os colegas do fórum que tem clientes que emitem CT-e e utilizam o ACBrCTe em suas aplicações não relataram nenhum problema quanto a essa consulta.
×
×
  • 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.

The popup will be closed in 10 segundos...