Carlos Tre

Olá Kathellyn, Não consegui, acabei desistindo, convencido de que se trata de um bug do lado da SEFAZ, e eles não estão muito interessados, talvez por se tratar de ambiente de homologação. Comigo ocorreu com apena um destinatário específico. Qual versão da nota vocês estão utilizando? Não testei com a versão 3.1 para ver ainda ocorre, mas, caso consiga um tempo, vou fazê-lo amanhã. Obrigado por me chamar a atenção de volta a este problema. Cordialmente, Carlos

Arnaldo, 1) quando usados corretamente, generators jamais geram valores duplicados. No caso específico do Firebird GEN_ID(generator,1) lhe devolve um valor único e automaticamente incrementa a sequência em 1. 2) tabelas de controle, para evitar duplicidade, devem ser acessadas por meio de stored procedures, cujo esqueleto seria update "TabelaControladora" set "UltimoUsado" = "UltimoUsado" + 1 where "TabelaControlada" = :TabelaControlada select "UltimoUsado" from "TabelaControladora" where "TabelaControlada" = :TabelaControlada Certifique-se de que esta stored procedure seja invocada em uma transação independente, configurada para repetir a tentativa em caso de deadlock. O "update" faz com que nenhuma outra transação possa gravar em "TabelaControladora" até que haja um commit ou rollback, garantindo assim a unicidade do "UltimoUsado". Cordilamente, Carlos

Olá Oscar, Verifique se os campos necessários para o SMTP processar corretamente o envio estão corretamente preenchidos. " MAILFROM" sugere que seja o remetente, eu começaria por ele. Cordialmente, Carlos

Olá Juaumkiko, Muito obrigado pelo esclarecimento. É a forma que havia codificado desde sempre, apenas nunca ocorreu de termos precisado de emitir em contingência. Estranhei a redação desde a versão 2.0, mas na revisão para a versão 3.1 o incômodo cresceu muito. Cordialmente, Carlos

Olá a todos, Apesar de abordado em vários tópicos, a busca por "dhCont" e "xJust" não gerou resultados que sanassem minha dúvida. Perdoem-me se for mais um dos cada vez mais frequentes momentos senis, mas não entra na minha cabeça preencher estes campos com, por exemplo, data e hora atuais, e "sem comunicação com a SEFAZ-SP". Estas informações seriam adequadas caso a descrição fosse "data e hora / justificativa para emissão em contingência" e não "entrada em contingência". No último caso entendo que eu deveria me informar sobre a entrada em contingência, e preencher tais campos de acordo com a informação obtida. Mas buscar onde? Não faz sentido ser na SEFAZ. O SVC-AN fornece estas informações? Muito obrigado de antemão. Cordialmente, Carlos

MySQL agora é da Oracle, e pode requerer o licenciamento comercial em função do uso que se fará. Além disso, na época em que tive contato com ele, mais de 10 anos com certeza, não oferecia suporte, ou apena limitado, a triggers, e por isto não me aprofundei mais na análise técnica, só por isso já não me atenderia. Não havendo a possibilidade de usar o Firebird, eu optaria então, por eliminação, pelo PostgreSQL. Cordialmente, Carlos

De fato não conheço nenhuma ferramenta gratuita para isto, mas como se trata de conversão apenas, creio que possa prescindir dos índices, correto? Sendo assim basta conferir a estrutura do arquivo, use este artigo como referência http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm Estes utilitários também poderão, esperançosamente, ser de ajuda: http://sourceforge.net/projects/dbfviewer/ http://sourceforge.net/projects/dbf/ Cordialmente, Carlos

Não sei se entendi bem a sua dúvida, mas você teria que converter tudo para a menor unidade - segundos se o tempo for medido por HH;MM:SS, ou minutos se HH:MM -, somar, converter o resultado de volta para o padrão de medição que você precisa. Assim de bate-pronto, se fosse para fazer em Firebird eu usaria uma stored procedure para fazer as totalizações. Cordialmente, Carlos.

Eu não costumo fazer este tipo de alteração no banco via Delphi de forma rotineira, uso apenas em situações isoladas, como importação de dados ou manutenção massiva. De qualquer modo, à primeira vista, acredito que o problema esteja no uso uso do TsqlQuery, embora não possa afirmar em virtude não usá-lo e, portanto, não estar familiarizado com ele. Fazendo uma analogia com componentes de nome parecido, acredito que ele se preste a executar uma única sentença SQL (select ... from.., [where], execute procedure ...). Se for este o caso, o problema é que o ";" é o terminador de comando default, e não pode ocorrer em meio a uma sentença. A solução é usar um componente que seja capaz de processar scripts, ou seja, uma ou mais sentenças em sequência, separadas umas das outras por um terminador específico. SET TERM ^ ; CREATE TRIGGER TRG_ITENS_ENTRADA_MOVIMENTO FOR ITENS_ENTRADA ACTIVE AFTER INSERT POSITION 0 AS declare variable DATA date; declare variable DESCRICAO varchar(30); begin SELECT ENT_DATA FROM ENTRADAS WHERE ID_ENTRADA = NEW.ITE_ENT INTO :DATA; DESCRICAO = 'REFERENTE A ENTRADA: ' || NEW.ITE_ENT; EXECUTE PROCEDURE INSERE_MOVIMENTO( NULL, NEW.ITE_PRO, NEW.ITE_ENT, 'ENTRADA', :DATA, 'E', :DESCRICAO, 'E', NEW.ITE_QUANTIDADE); end ^ SET TERM ; ^ Cordialmente, Carlos

A consulta continua a mesma, só que ao invés de ler o cStat sob retConsSitNFe será necessário varrer todo o retorno para determinar a situação corrente da nota. Impossível ou complicado? De forma alguma, mas uma mudança totalmente desnecessária não menos, visto que da forma que era estava mais coerente, retornando no status da consulta a situação corrente da nota. Cordialmente, Carlos Tré

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