Italo Giurizzato Junior

Ricardo, A imagem que postei se refere a consulta completa no Portal Nacional da NF-e. Acabo de fazer uma consulta completa no site do SEFAZ-SP. Em ambos consta como cancelado.

Boa tarde Ricardo, Você tem certeza que a nota não foi cancelada?

Boa tarde Andre, Por favor, procure postar o conteúdo do XML como anexo.

Boa tarde Ailton, Essa alteração resolveu o problema? Se sim, por favor em vez de postar as linhas de códigos, post como anexo a Unit que foi alterada, desta forma fica fácil fazermos um merge e disponibilizar para todos.

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

Boa tarde multirac, Procure sempre baixar e ter em mãos os Manuais e Notas Técnicas. Esses documentos publicados pela SEFAZ no Portal Nacional da NF-e traz o tipo e o tamanho, não só das TAGs dos XML que são enviados para os Web Services como também dos Retornos. Lembre-se que o componente foi criado e é atualizado com base nessa documentação, portanto você pode se basear nela para definir o tipo e o tamanho de um campo em uma determinada tabela do seu banco de dados. Alem disso você vai ter uma breve explicação do que vem a ser cada TAG, importante ressaltar que o componente utiliza a mesma nomenclatura que consta nesses documentos. No componente temos a propriedade xMotivo, na documentação vamos encontrar também: xMotivo e no XML também teremos a TAG: xMotivo. Como todo regra tem exceção, no componente ACBrNFe também temos. É a TAG: mod que se refere ao modelo do documento fiscal, no componente a propriedade recebeu o nome: modelo, uma vez que mod é um operador em Delphi.

Bom dia Wesley, Já postei em outros tópicos, que o componente ACBrNFSe possui 3 comandos de envio: 1. Gerar - envia para o Web Services somente um RPS. 2. Enviar - envia um lote com até 50 RPS (modo assíncrono). 3. EnviarSincrono - envia um lote com até 50 PRS (modo síncrono). É preciso saber quais dos 3 o provedor implementou em seu Web Services. Existe provedores como o Ginfes que implementou somente o Enviar, mas tem provedores que implementaram 2 ou até os 3. Não existe um comando GerarNFSe no componente e sim o Gerar. Existe sim uma classe TNFSeGerarNFSe que tem haver com o Gerar.

Bom dia Junior, Pelo que pude ver já tem algumas coisas prontas. É preciso escrever agora a rotina que vai gerar o XML (unit: pnfsNFSeW.pas) e a que vai ler (unit: pnfsNFSeR.pas). Algo semelhante a que foi feita com o provedor Equiplano. Não é só isso, talvez seja necessário realizar mais algumas implementações para que o componente consiga realizar a assinatura, a validação etc.

Bom dia Marcelo, Post como anexo a Unit que você fez a alteração, desta forma possamos avaliar a sua alteração e disponibilizar ela a todos.

Bom dia Vand, Fiz diferente: Alterei de: Gerador.wCampoNFSe(tcStr, '', 'nrInscricaoEstadual', 00, 020, 1, NFSe.Tomador.IdentificacaoTomador.InscricaoEstadual, ''); para: Gerador.wCampoNFSe(tcStr, '', 'nrInscricaoEstadual', 00, 020, 0, NFSe.Tomador.IdentificacaoTomador.InscricaoEstadual, ''); O zero diz que a TAG é opcional, neste caso se o conteúdo de InscricaoEstadual for vazio a TAG não será gerada.

Bom dia Wener, Até onde sei, é tratando a execução do mesmo. Se não levantar nenhuma exceção é porque foi enviado.

Bom dia Cristian, Manual versão 2.00a do CT-e página 77 traz 4 situações: 1. Status = 134, indica que o evento foi registrado e vinculado ao CT-e, mas o mesmo contem situação diferente de Autorizado. Neste caso é retornado um alerta com a situação do CT-e. 2. Status = 135, indica que o evento foi registrado e vinculado ao CT-e. 3. Status = 136, indica que o evento foi registrado mas não foi vinculado pela inexistência do CT-e. 4. Status diferente dos 3 acimas, indica Rejeição, o evento não foi registrado e no campo Motivo temos o porque da rejeição. Veja bem esse é o retorno da SEFAZ ao processar um evento, que pode ser: Cancelamento, Carta de Correção, EPEC, etc. No caso do cancelamento, já mais teremos o status 136, uma vez que para cancelar um CT-e, o mesmo tem que existir e ter sido autorizado. O status 136, normalmente é retornado quando enviamos o evento EPEC, e depois é enviado o CT-e. Aconselho a você baixar esse manual do Portal Nacional do CT-e, para ter mais informações, inclusive no item 5 (página 78) é apresentado cada evento com as rejeições que podem ocorrer e status.

Bom dia Jair, Muito obrigado pela colaboração, já esta disponível.

Bom dia Wesley, Só tem esse arquivo? E o de retorno (1-rec-c.xml) ?

Bom dia Ailton, Quanto o valor da propriedade Transação já fiz as correções e não foi no pnfsNFSeG e sim em outra unit. Com relação a virgula em vez de ponto, verifique a configuração do Windows.

Bom dia Julio, Não sei se alguma SEFAZ já liberou essa forma de envio, mas uma coisa é certa o componente ACBrNFe2 ainda não contempla a geração do lote zipado.

Bom dia Rômulo, Favor atualizar os fontes com que esta no repositório, alem da sua alteração existe uma correção de ortografia na palavra Consumidor.

Boa noite Richard, Se você se refere a NF-e, vamos as respostas: Recibo = é um numero retornado pela SEFAZ acusando que um lote contendo 1 ou mais notas foi recebido. É através do numero do recibo que o componente ACBrNFe realiza uma consulta para saber se o lote foi processado ou não e se foi o resultado desse processamento. Protocolo = é um numero retornado pela SEFAZ acusando que a Nota foi processada com sucesso, portanto temos a Autorização de uso da NF-e. Recibo é único para todo o lote, já o protocolo é individual, ou seja, temos um para cada nota contida no lote. Ao realizar a consulta para saber se o lote foi processado com sucesso ou não, caso tenha temos nessa resposta da SEFAZ o protocolo de cada nota que constava no lote enviado. Lote = é um numero sequencial atribuído ao lote, a SEFAZ não faz uso dessa informação, mas eu sugiro que você tenha um controle sobre essa informação. Algo do tipo a data que o lote 10 foi enviado e qual era a faixa de numero de NF-e contida no lote. Espero ter respondido as suas perguntas.

Michel, Com a mudança da forma de cancelar, o XML do CT-e não sofre mais alteração. O XML do CT-e mesmo depois de ser cancelado permanece exatamente igual quando foi autorizado pela SEFAZ. O motivo disso é que agora você tem o arquivo: <chave>-procEventoCT-e.xml, trata-se de um XML que contem a solicitação de cancelamento e o retorno da SEFAZ acusando o registro do respectivo evento. Esse segundo XML é um documento valido que atesta que o <chave>-cte.xml foi cancelado. Estude o programa exemplo, existem botões que mostram como imprimir a representação gráfica de um evento, bem como o envio por e-mail para o tomador do serviço.

Boa noite Sérgio, Post como anexo o XML do MDF-e que foi enviado e rejeitado pela SEFAZ.

Boa noite Michel, Essa TAG só vai retornar algo se o CT-e a ser consultado for da versão 1.04, caso contrario ela não vai conter nada.

Boa tarde Ailton, Atualize os fontes e tente novamente.

Uendel, Sim, a Manifestação do Destinatário é composto por duas etapas: 1. A consulta; 2. A manifestação.

Boa tarde a todos, Por favor atualize os fontes e tente novamente.

Boa tarde Luis, No modo síncrono o que não temos é o numero do recibo. O numero do protocolo bem como a data/hora de recebimento constam no retorno do processamento da nota enviada, em qualquer caso.