Italo Giurizzato Junior

Boa tarde Jorge, Obrigado pelas informações. Como não utilizo e nem faço parte do desenvolvimento do ACBrNFeMonitor, não sei se o mesmo trata de forma amigável os retornos, mais precisamente quando ocorre Rejeição.

Boa tarde Luis, Com certeza deve ser alguma falha no Web Services da SEFAZ-SP.

Boa tarde Ailton, Atribua o valor True a propriedade ACBrNFSe.Configuracoes.WebServices.Salvar. Realize os testes novamente. Com a propriedade acima setada com o valor true será gerado vários arquivos *-soap.xml eles possui a estrutura completa dos XMLs de envio e de retorno do Web Services. Os de retorno podem lhe dar alguma dica do problema que esta ocorrendo.

Bom dia Carlos, Se você atribuir o valor True a propriedade: ACBrNFe.Configuracoes.Arquivos.Salvar o retorno da consulta será salvo automaticamente pelo componente.

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.

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.

Bom dia, Sem os schemas, Name Space, URLs dos ambientes de Homologação e Produção utilizados pelo provedor, não tem como implementar.

Bom dia Ailton, Tente desta forma: sProt := ACBrNFSe1.WebServices.Enviar.Protocolo;

Bom dia Jorge, Esse aplicativo X, você sabe me dizer se ele utiliza o componente ACBrNFe para emitir NF-e?

Bom dia, Realmente a mensagem "Homologação - Sem Valor Fiscal", estava sendo impresso na área errada. Fiz a correção. Se o tipo de emissão for offline será impresso na área VI o titulo Emissão em Contingência. Quanto ao QR-Code nos meus testes ele esta sendo impresso com o tamanho de 3,2 x 3,2 portanto maior que o mínimo estabelecido que é 2,5 x 2,5. Entre a área que é impresso o valor aproximado dos tributos e a área de mensagem fiscal foi incluída a área de mensagem de interesse do contribuinte (campo Va) conforme consta em: Especificações Técnicas do DANFE NFC-e QR-Code Versão 3.2 01/04/2014 (página 5). Lembrando que o conteúdo a ser impresso nessa área tem que constar no XML na TAG: infCpl. Esta faltando incluir mais uma área após o QR-Code, que é destinada a mensagens para o consumidor e que não consta no XML (página 8). "Importante - Caso o contribuinte queira imprimir, no mesmo papel do DANFE NFCe, mensagens institucionais ou outras informações que não estejam no arquivo XML da NFCe, as mesmas deverão ser apresentadas após o final do DANFE NFCe (imediatamente após protocolo de autorização da NFCe – divisão VIII)." Favor atualizar os fontes e testar.

Bom dia, Muito estranho, a principio com exceção da linha a mais na assinatura do resto não vejo algo que poderia estar provocando esse erro.

Bom dia Caejr, Você utiliza o componente ou o Monitor? Se é o componente, qual é o Report utilizado para imprimir o DANFE?

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

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.

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.

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?

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.

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.

Notei que você informou como série o texto RPS. <Serie>RPS</Serie> Verifique junto ao provedor se isso pode ser feito sem problemas. E com relação a data de emissão, utilize o Now em vez do Date para atribuir a data ao componente, pois ela deve conter a data e a hora. Do resto não encontrei nada que pudesse estar causando a rejeição.

Boa tarde André, Esta com os fontes atualizado?

Boa tarde, Se possível, post como anexo o XML do RPS que esta sendo rejeitado.

Boa tarde Rick, Muito obrigado pela colaboração, já esta disponível.

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.

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?

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;