Italo Giurizzato Junior

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;

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.

Boa tarde, Esse erro foi detectado e corrigido, se não me falha a memória uns 15 dias atrás. Procure manter todos os fontes de todas as pastas atualizados diariamente.

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.

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.

Boa tarde Roger, Depende do provedor, uns temos que informar 4,26 mesmo outros 0,0426.

Junior, Estou estudando a melhor forma de se fazer isso.

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

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.

Bom dia Celso, Desculpe pessoal, esqueci, por favor atualize os fontes.

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.

Bom dia, Você esta tentando utilizar o Valida, para validar o XML de um RPS? Se sim, não vai funcionar, pois o Valida é usado internamente pelo componente para validar o Lote de RPS.

Bom dia pjunior, Esse XML que você postou, não é gerado pelo componente ACBrCTe e sim baixado do Site da SEFAZ (link Download). A estrutura dele é diferente o LoadFromFile do componente não esta preparado para ler esse XML. A alteração que você fez parece estar correta em partes, pois esse arquivo poderá conter também os eventos vinculados ao CT-e, e neste caso o LoadFromFile não vai ler eles. Independente disso, para ler as informações desejadas: ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.cStat ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.xMotivo ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.nProt

Bom dia Thales, Ou o Ginfes alterou alguma coisa na estrutura, ou o Web Services esta com problema.