Cantu

01061200;;0;"--Baleias, golfinhos e botos (mamíferos da ordem dos cetáceos); peixes-boi (manatins) e dugongos (mamíferos da ordem dos sirênios); otárias e focas, leões-marinhos e morsas (mamíferos da subordem dos pinípedes)";26.75;29.50; O delimitador está entre aspas, então não é pra dar problema.

Putz, pior que eu tinha pesquisado antes de abrir o tópico, e não tinha encontrado nada. Fiz inclusive busca por 0.0.2 e não retornou nada... zzzZZ. Mas blz...

Acabei de receber a nova versão da tabela IBPTax (0.0.2), e percebi que adicionaram uma nova coluna chamada Descrição. Provavelmente o componente do ACBr terá que ser atualizado pra conseguir usar essa nova estrutura do csv.

Beto, tomei a liberdade de colocar na área de downloads da FireBase, com créditos para você.

Regys, realmente... no meu "try except" do cancelamento eu estava referenciando propriedades do retorno do cancelamento, que obviamente não existem nesse caso, pois a exceção aconteceu antes mesmo da transmissão. Estou ajustando o código. Desculpe, se quiser pode apagar o tópico.

O componente está retornando um Access Violation quando se tenta cancelar uma NFe e a justificativa tem menos de 15 caracteres. O correto seria dar uma exceção mencionando o problema. []s

Desculpe Regys, eu lembro de ter olhado todas as páginas do tópico e não ter encontrado esse link específico (não é o mesmo link que eu vi em alguns posts anteriores), por isso postei. Talvez tenha passado despercebido.

Aos que possam se interessar, recebi essa resposta da Mayara:

Só pra constar, me parece que o Rio Grande do Sul está se antecipando e já está obrigando TODAS as empresas a se manifestarem a partir de 1/abril/13, se a nota recebida tiver um valor maior que R$ 100.000. Vide: http://mauronegruni.com.br/2013/03/14/rs-nf-e-comunicado-da-receita-estadual-exige-manifestacao-do-destinatario-a-partir-de-1o-de-abril13/

Well, aparentemente houve uma série de problemas... Primeiro, o exemplo do Regys não trata o cstat 155, que é homologação fora do prazo (e que foi justamente o meu caso). Segundo, quando eu disparei a exceção com o erro, acabei pegando o cstat do lote ao invés do cstat do evento, aff... Well, fica aí as observações, talvez possa ajudar alguém, eheheh.

Estou seguindo o exemplo do Regys (http://www.regys.com.br/como-enviar-um-evento-de-cancelamento-utilizando-o-acbrnfe/) para cancelamento de NFe via evento. Fiz vários testes no ambiente de homologação e soltei a atualização para os clientes, no entanto, em um deles, em um único caso (até o momento), o valor de NFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat retornou 128 e não 135. Com isso, meu sistema fez um rollback das alterações (estoque, etc) e considerou que o cancelamento não foi efetuado, só que minutos depois, consultei a chave na Sefaz, e lá consta que a nota foi cancelada. Alguém já passou por isso ou sabe o que pode estar acontecendo? Detalhe: 1) Foi um cancelamento fora do prazo, mas foi autorizado pela Sefaz SP. 2) Meu lote sempre contém um único evento.

Com a obrigatoriedade do cancelamento de NFe por evento se aproximando, estou em duvida em relação ao retorno (cstat) do pedido de cancelamento: Se retornar 135, tudo certo. Mas se retornar 136 (Evento registrado, mas não vinculado a NF-e), devo entender que a NFe foi cancelada ou não?

Pessoal, alguém com acesso ao SVN, favor remover (ou arrumar) a função ChaveAcesso da classe NotaUtil, pois ela não funciona para NF-e 2.0, pois não leva em conta o Tipo de Emissão. Eu já tinha reportado o problema pro André em 2010 e ele disse que ia remover a função, mas acho que acabou esquecendo Já tem outra função (GerarChave) do PCN que gera a chave corretamente.

Valeu Regys!

Grande Daniel! Quando vai aparecer pra uma "pizzada" relembrando os tempos de BBS ? Eu já tinha enviado pro André, mas o bicho deve estar enrolado.

Alguém aí poderia incluir a correção no SVN antes que caia no esquecimento, please?

Já estava ficando louco aqui com um problema no envio de email de NFe pelo ACBr, usando thread, em alguns clientes. Simplesmente dava uma exceção, mas o que aparecia pro usuário não servia pra nada: Project xxx.exe raised exception class EAccessViolation with message 'Access violation at address 00404E96 in module 'xxx.exe'. Read of address 00000000 Com a nova opção de enviar o email sem usar threads, fui capaz de identificar o problema (o endereço do email que o cliente estava especificando estava incorreto), porque nesse caso, a exceção trazia a mensagem real do erro. Assim, ficou mais fácil de debugar o código do envio via thread, e achei o culpado: procedure TSendMailThread.DoHandleException; begin TACBrNFe(TNotasFiscais(FOwner.GetOwner).ACBrNFe).SetStatus( stIdle ); <- PAU!!!! FOwner.Alertas := FException.Message; if FException is Exception then Application.ShowException(FException) else SysUtils.ShowException(FException, nil); end; No caso, a linha TACBrNFe(TNotasFiscais(FOwner.GetOwner).ACBrNFe).SetStatus( stIdle ); sempre dá pau, pois FOwner sempre está nil. Enfim, a solução é comentar as duas primeiras linhas, ou então implementar o código que atribui à FOwner o objeto correto. Como não domino o código do componente, eu comentei as linhas aqui e agora consigo ver a mensagem real de erro, mesmo quando envio via Thread. Aos responsáveis, favor corrigirem o código oficial.

Valeu Regys, as vezes queremos complicar o que é simples

Com a instabilidade da Sefaz/SP de ontem, aconteceu de um cliente meu solicitar o cancelamento de uma NF-e, mas o webservice não respondeu por mais de 20 minutos, e o sistema abortou. No entanto, após normalização do serviços, consultando a chave da NF-e no site da Sefaz, ela está como cancelada. Dúvida: Nesse caso, como fazer para atualizar o XML original da NF-e de forma a incluir os dados do cancelamento? Normalmente isso é feito pelo próprio componente durante a rotina de cancelamento, mas como a rotina não finalizou normalmente, o XML não foi atualizado.

Até onde sei, minha alteração foi "commitada" na base de código do ACBr pelo André, na semana passada.

ACBrNFeWebServices.pas Adicionar: CCeRetorno.retEvento.Items[j].RetInfEvento.XML:=wProc.Text; na linha 3015. No pcnRetCCeNFe.pas: TRetInfEvento = class private FId: String; FtpAmb: TpcnTipoAmbiente; FverAplic: String; FcOrgao: Integer; FcStat: Integer; FxMotivo: String; FchNFe: String; FtpEvento: Integer; FxEvento: String; FnSeqEvento: Integer; FCNPJDest: String; FemailDest: String; FdhRegEvento: TDateTime; FnProt: String; FXML: AnsiString; // Adicionada public published property Id: string read FId write FId; property tpAmb: TpcnTipoAmbiente read FtpAmb write FtpAmb; property verAplic: string read FverAplic write FverAplic; property cOrgao: Integer read FcOrgao write FcOrgao; property cStat: integer read FcStat write FcStat; property xMotivo: string read FxMotivo write FxMotivo; property chNFe: String read FchNFe write FchNFe; property tpEvento: Integer read FtpEvento write FtpEvento; property xEvento: String read FxEvento write FxEvento; property nSeqEvento: Integer read FnSeqEvento write FnSeqEvento; property CNPJDest: string read FCNPJDest write FCNPJDest; property emailDest: String read FemailDest write FemailDest; property dhRegEvento: TDateTime read FdhRegEvento write FdhRegEvento; property nProt: String read FnProt write FnProt; property XML: AnsiString read FXML write FXML; // Adicionada end; Depois, na sua aplicação, após enviar pro webservice: tqCCeXML.asString := UTF8Encode(Nfe.WebServices.CartaCorrecao.CCeRetorno.retEvento.Items[0].RetInfEvento.XML);

Eu fiz uma pequena alteração no componente pra ele disponibilizar o XML "correto" após o envio da CCe ter sido aprovado. Já enviei pro André dar uma olhada e aprovar (ou reprovar, ehehe). Foram apenas 3 linhas de código inseridas, mas como não estou familiarizado com o código dos componentes, não sei se fiz da forma "correta".

Estou implementando a carta de correção no meu ERP usando o ACBr. Pensei em gravar o XML do retorno da CCe no BD assim: tqCCeXML.asString := UTF8Encode(NFe.WebServices.CartaCorrecao.RetWS); No entanto, esse é o retorno do processamento pelo webservice, e não o XML que deve ser armazenado e disponibilizado para o cliente (item 4.9 na NT2011.003). Dei uma procurada no código do ACBr, e me parece que o XML "correto" só é gerado no método executar quando o componente está configurado para gravar em arquivos: if FConfiguracoes.Geral.Salvar then FConfiguracoes.Geral.Save(FCCe.Evento.Items[i].InfEvento.chNFe + '-ProcEventoNFe.xml', wProc.Text); if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(FCCe.Evento.Items[i].InfEvento.chNFe + '-ProcEventoNFe.xml', wProc.Text, FConfiguracoes.Arquivos.GetPathCCe); Ou seja, aparentemente não há uma forma de recuperar esse XML a não ser configurando o componente para gravar em arquivo, e depois lendo o arquivo pra dentro do BD. A meu ver, deveria ser disponibilizada uma forma de recuperar esse XML diretamente via método/propriedade do componente, sem necessidade de gravar em arquivo. Dúvida: Isso vai ser (ou está sendo) implementado? Perdi alguma coisa?

Adilson, bem lembrado a questão de filiais... será que uma filial pode corrigir uma nota emitida pela matriz (ou vice-versa)?

Uma dúvida, quanto ao campo CNPJ da carta de Correção, na nota técnica, diz: "HP10 CNPJ - Informar o CNPJ ou o CPF do autor do Evento" Na minha interpretação, autor do evento é a empresa que emitiu a nota e que está fazendo a carta de correção, correto? Se sim, o componente não poderia já recuperar o valor desse campo pela chave da NFe que está sendo corrigida, ou mesmo pegando do certificado digital?