Carlos Tre

Juaumkiko, Acho que está mesmo havendo um certo mal entendido, pois a questão inicial, levantada pelo Clóvis F. S. Júnior, não é a mesma que o Erick Fabiano Elias levantou, ao menos da forma que vejo não é. Explicando melhor: No mês passado eu precisei implementar um procedimento de consulta de nota, de nossa emissão, conhecida a sua chave. A tag cStat sob o ramo retConsSitNFe em caso de nota cancelada, retornava 101, como pode ser visto no meu comentário anterior. Note que esta consulta foi feita em Fevereiro de 2014, ou seja, *muito* depois da implementação do cancelamento por eventos. Recentemente, como também pode ser visto no mesmo comentário, o cStat passou a ser 100, forçando a varredura do XML para determinar o efetivo cancelamento ou não da nota. Nada a ver com alteração do XML original, apenas uma mudança, ao meu ver desnecessária, feita pela sefaz, no *retorno* de uma consulta. Além de desnecessária, mudança para pior, pois antes o retorno da consulta informava a situação corrente da nota, e agora não mais. Como benefício adicional, quem já tinha o código testado, depurado, e implementado vai ter que começar tudo de novo... Cordialmente, Carlos Tré

Juliomar, Acho que o que o nosso colega Erik quis dizer é que o retorno da consulta mudou recentemente, muito depois da implementação de cancelamento por eventos. A rotina de consulta pela chave eu implementei apenas no mês passado e o retorno vinha, por exemplo, desta forma: Efetuando a mesma consulta hoje, obtive: Então a mudança não está necessariamente atrelada à nota técnica, que já está em feito há muito tempo, e a SEFAZ-SP simplesmente mudou o retorno nos últimos dias. Pessoalmente sou da opinião de que deveria haver mais estabilidade em serviços essenciais e desta magnitude. Um mês depois ter feito, testado e depurado, lá vamos nós outra vez como se nada mais tivéssemos para fazer a não ser programar para satisfazer ao humor da secretária da fazenda. Esta mudança é totalmente desprovida de sentido, o retorno da consulta indicava que a nota estava cancelada, e as tags protNFe e procEventoNFe descreviam o seu histórico. Respondendo ao Erik, ainda não pensei em como fazer, mas creio que não há outra alternativa senão varrer o XML em busca da tag procEventoNFe de cancelamento. XML Antes: 35140208520909000182550010000006201777646345-sit_Org.xml XML Atual: 35140208520909000182550010000006201777646345-sit.xml Cordialmente, Carlos Tré

Na verdade eu ainda não o resolvi satisfatoriamente. No meu caso ocorreu com emissão de nota para uma empresa domiciliada em MG, no ambiente de homologação apenas. Consultei a sefaz e recebi como resposta um texto padrão sobre irregularidades com o cadastro no CADESP, o que não deveria acontecer com contribuintes de MG. Como no ambiente de produção as notas para este cliente estão sendo processadas sem problemas, a nossa assessoria contábil não está dando muito bola para o assunto. Sugiro pressionar o contador do seu cliente para esclarecer o motivo desta rejeição, talvez o fato de ser uma filial de contribuinte de SP tenha alguma implicação. Cordialmente, Carlos Tré

Dall'ara, O componente está configurado para salvar automaticamente? Para quais pastas as propriedades PathNFe e PathSalvar apontam?. Cordialmente, Carlos

igcastro, Várias vezes, nas mais diversas situações. Geralmente o motivo é servidor com problemas em processar as requisições, por sobrecarga ou mal funcionamento. Não me lembro, entretanto, de ter viso esta mensagem de erro durante conexões com os servidores da secretaria da fazenda. Cordialmente, Carlos

Olá edsonalves, Observe a captura de tela em anexo e verá que não. Este é o retorno da consulta de uma nota com duas correções aplicadas, e posteriormente cancelada. https://www.dropbox.com/s/rwgv5ld6kgbabf9/3514020852090900018255001000000620177764.jpg Cordialmente, Carlos

Não sei quem tem a receita pronta, eu particularmente não uso o ACBrNFe para enviar email, mas posso tentar ajudar. Como respondi antes, os erros apontados sugerem problema na configuração do SMTP. Você pode postar o trecho de código que comanda o envio? Se for pelo ACBrNFe será algo do tipo ACBrNFe1.NotasFiscais.Items[0].EnviarEmail(edtSmtpHost.Text , edtSmtpPort.Text , edtSmtpUser.Text , edtSmtpPass.Text , edtSmtpUser.Text , Para , edtEmailAssunto.Text , mmEmailMsg.Lines , cbEmailSSL.Checked // SSL - Conexão Segura , True //Enviar PDF junto , CC //Lista com emails que serão enviado cópias - TStrings , nil // Lista de anexos - TStrings , False //Pede confirmação de leitura do email , False //Aguarda Envio do Email(não usa thread) , 'ACBrNFe2' // Nome do Rementente , cbEmailSSL.Checked ); // Auto TLS Cordialmente, Carlos

Olá Siro. Descobri o caminho das pedras sim, apenas não codifiquei ainda porque outras prioridades se intrometeram. O xml da consulta você obtem assim: ACBrNFe1.WebServices.Consulta.NFeChave := AChaveNFe; ACBrNFe1.WebServices.Consulta.Executar; XMLConsulta := ACBrNFe1.WebServices.Consulta.RetWS; o xml obtido será similar a este: 35140208520909000182550010000006201777646345-sit.xml que pode ser visto, parcialmente, aqui: https://www.dropbox.com/s/65b4zisvssv4v67/2014-02-12%2010_54_32-MiTeC%20XML%20Viewer%20-%20%5B35140208520909000182550010000006201777646345-sit.xml%5D.jpg Esta nota de teste tem dois eventos de correção e um de cancelamento, e seus xmls podem ser obtidos dos nós 'procEventoNFe', e então processados conforme a sua conveniência - gravados em arquivo, banco de dados, etc. Cordialmente, Carlos

Dall'ara, Nunca usei o demo para esta finalidade ou, se usei para testar, não me lembro mais dos detalhes, mas comece revisando as propriedades do componente ACBrNFe1. Se a nota for salva automaticamente, será na pasta apontada por PathNFe ou PathSalvar. Cordialmente, Carlos

Dayane, O problema deve ser de configuração do servidor ou usuário SMTP. Veja a descrição dos erros de socket (em inglês) aqui: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx Cordialmente, Carlos

Olá Ítalo, Muito obrigado pela sua atenção. Fiz conforme sugerido por você e, de fato, quando da consulta da nota, o componente grava um arquivo "*-sit.xml" que contem uma seção "procEventoNFe" que é o XML de cancelamento procurado. Creio que agora é apenas uma questão de carregá-lo e extrair a parte que me interessa. Não sou muito versado em XML, mas deve ser apenas uma questão de meter a mão na massa e descobrir como se faz. Cordialmente, Carlos

Olá a todos, Me desculpem o provável momento senil, mas não estou conseguindo me encontrar nesta questão. Pesquisei por várias combinações de palavras-chave, e mesmo com alguns tópicos chegando muito próximo daquilo que preciso, não consegui resolver o meu problema. Por uma pane ocorrida logo após enviar o evento de cancelamento, fiquei sem o arquivo para enviar ao destinatário. Pesquisando no fórum e estudando o demo, vi que o caminho a seguir é consultar a nota, seja pela chave ou pela carga do xml original. Após a consulta obtenho ACBrNFe1.WebServices.Consulta.cStat = 101 ACBrNFe1.WebServices.Consulta.procEventoNFe.Count = 1 indicando que a nota foi efetivamente cancelada, e tem um evento associado. A partir daí eu preciso fazer algo do tipo varXMLCancelamento := ACBrNFe1.<???>; para atribuir o XML de cancelamento a uma variável, e poder então prosseguir nas diversas etapas necessárias. Alguma alma gentil poderia me dar uma mão nesta questão? Cordialmente, Carlos

Muito obrigado pela sua atenção ao meu problema, É o que eu estou imaginando ser o caminho a seguir, apenas estava querendo me certificar de que não há nada errado com o xml enviado no lote antes de entrar em contato com o atendimento, mas como já somos dois a acreditar que esta nota não deveria ser rejeitada por este motivo, vou fazê-lo hoje mais tarde. Cordialmente, Carlos

Olá Sérgio, muito grato pela sua atenção. Não creio que seja este o caso, o destinatário é de Minas Gerais, e não faz sentido, ao menos ao meu ver, que possa então ser registrado no CADESP. O erro deve estar em outro lugar, provavelmente alguma bobagem que não estou conseguindo perceber, e que induz o processo de validação da SEFAZ/SP a tentar validá-lo no CADESP. Cordialmente, Carlos

Olá a todos, Achei melhor abrir um novo tópico porque os demais que encontrei pela busca do fórum não se encaixam exatamente, apesar de ser o mesmo erro estavam em sua maioria relacionados a isentos. Estou com um problema de emissão para um determinado destinatário instalado no estado de Minas Gerais. Nossa empresa está instalada em SP. A inscrição estadual e CNPJ estão corretos, confirmei pelo http://consultasintegra.fazenda.mg.gov.br. A consulta ao CADESP, conforme sugerida pelo Kiko Fernandes em outro tópico, creio que se aplica apenas aos contribuintes de SP, não sendo, portanto, válida neste caso. Ao transmitir nota para este cliente em particular, pelo ambiente de homologação, ocorre a rejeição pelo motivo acima. Tentei há pouco com um outro destinatário também instalado em MG e a nota foi autorizada, o que me faz acreditar que o problema aconteça apenas com este destinatário. Anexo os arquivos XML de envio do lote, 120-env-lot.xml recibo 120-rec.xml e consulta do lote 351000076969309-pro-rec.xml pois não consigo pensar em outra coisa senão uma bobeada de minha parte que não estou conseguindo perceber. Já emitimos notas para este destinatário, via emissor gratuito, em outubro de 2012, portanto após a entrada em vigor da verificação associada ao erro. Agradeço antecipadamente a quem puder indicar um caminho para desatar este nó. Cordialmente, Carlos Tré 120-env-lot.xml 120-rec.xml 351000076969309-pro-rec.xml

Olá a todos, Nunca passei por esta situação específica, mas em outras situações parecidas, em que o sistema fecha misteriosamente, ou se comporta de forma errática, em computadores específicos, o que sempre fiz foi me valer do CodeSite para gerar um passo a passo e determinar o ponto onde o programa falha. Cordialmente, Carlos

Fausto, A opção que destaquei tem que ser desmarcada, como está na captura de tela, e não marcada como o seu comentário acima sugere que você tenha feito. Se ela for marcada a senha será pedida a cada acesso. Cordialmente, Carlos

Valdecir, Tente este: http://svn.code.sf.net/p/acbr/code/trunk Cordialmente, Carlos

Olá Fausto, Eu não consigo imaginar outra situação em que a senha seja solicitada a cada acesso. Veja a captura de tela abaixo, é a segunda tela do instalador do arquivo PFX: https://www.dropbox.com/s/fok8h0z9hp4wfou/ProtecaoChavePrivada.jpg Cordialmente, Carlos

Ola Harison, Embora meus sistemas baseados no componentes ACBr executem em Windows Server 2008, não faço uso do monitor, e nunca me deparei com este erro em outras situações. Você já considerou a possibilidade de hardware defeituoso, neste caso em particular, a placa de rede? "If any dhcpcsvc.dll errors persist after a clean install of Windows, your DLL problem can only be hardware related". http://pcsupport.about.com/od/fixtheproblem/ht/dll-hardware-error-troubleshoot.htm. Acho que vale a pena ainda peneirar os links retornados em http://search.microsoft.com/en-us/supportresults.aspx?form=mssupport&q=dhcpcsvc.dll Cordialmente, Carlos

Josadac, Segundo o fabricante você precisa de uma licença por servidor e assim, pelo que entendi, você pode ter várias estações compartilhando um mesmo dispositivo USB: 1 servidor (certificado) -> N estações emissoras. Como eu disse anteriormente você pode baixar a versão de testes sem custo algum, usá-la por até 15 dias, e confirmar se resolve ou não o problema. Não se esqueça de nos manter a par do seu progresso. Cordialmente, Carlos

Segundo o Helton, este programa http://www.fabulatech.com/usb-over-network.html resolve o problema a um custo razoável (US$ 149,00 + 6,38% IOF). A versão de testes permite compartilhar 1 dispositivo USB por até 15 dias, acredito que seja o suficiente para testar e decidir. Cordialmente, Carlos

Olá Harison, Mas não há mensagem de erro alguma? Pelo que você descreveu acima o erro parece estar relacionado ao módulo 'dhcpcsvc.DLL'. Veja se este artigo ajuda: http://pcsupport.about.com/od/findbyerrormessage/a/dhcpcsvc-dll-not-found-missing-error.htm Cordialmente, Carlos

Fausto, Apenas pelo que você detalhou acima é difícil, ao menos para mim, descobrir qual seja a causa. Entretanto vou arriscar um palpite: se não me engano, durante a instalação do certificado é oferecida uma opção de segurança que implica em solicitação da senha a cada utilização, e é muito provável que a causa do seu problema esteja aí. Cordialmente, Carlos

Se eu entendi bem o que acontece, a primeira coisa que eu faria é atribuir o valor de ACBrNFe1.Configuracoes.Geral.PathSalvar+'\'+copy(ACBrNFe1.NotasFiscais.Items[0].NFe.infNFe.ID, (length(ACBrNFe1.NotasFiscais.Items[0].NFe.infNFe.ID)-44)+1, 44)+'-NFe.xml' a uma variável. Se a rotina GerarDigito funciona em alguns casos e em outros não, a simples exposição do valor problemático já mostra onde está o erro.