Alexsander

Você não entendeu...

Não é tão simples... porque o ZERO não existe nesta lista (pois zeros à direita após a vírgula não têm valor, lembra?). Na verdade é preciso estipular uma "regra de desempate" para usar quando o algarismo for 5, pois 0,125 está EXATAMENTE no meio entre 0,12 e 0,13. Uma das regras, por exemplo, usa o algarismo anterior para desempatar: "se depois do 5 não tiver número significativo, observa-se o algarismo anterior, se for par conserva e se for ímpar aumenta." [1] 1-2-3-4 = arredonda pra baixo 6-7-8-9 = arredonda pra cima 5 = usa alguma regra de desempate [1] http://professor.ucg.br/SiteDocente/adm ... AMENTO.doc

E se ela for IGUAL a 5?

Não estou pedindo ajuda pra resolver o problema... estou apenas tentando entender o que houve. Se a DANFE é impressa a partir do XML, como conseguiram imprimir um valor que NÃO está no XML? Se fosse o contrário, um valor do XML que não saiu impresso, até daria pra imaginar o erro. Mas imprimir algo que não existe é estranho, fico pensando que tipo de gambiarra eles fizeram. O único lugar do XML onde as datas aparecem é nas observações, no meio de um monte de texto. Aparentemente o software deles monta o PDF a partir do banco de dados, não a partir do XML!!! Eu achava que isso não era permitido, mas não achei nenhuma legislação mencionando isto explicitamente.

Não sei. Eis o trecho do XML que fala sobre o aplicativo: 0 V26.9.2

PS: Há uma diferença de 55 segundos entre o par (protocolo+datahora) da DANFE e do XML. O número do protocolo é o mesmo nos dois. Um BUG no aplicativo de NFe do fornecedor poderia causar isto?

Um cliente recebeu uma NFe cujo XML não tem as datas das duplicatas mas a DANFE imprimiu as datas. Isso é normal? 53756 9520.77 9520.77 53756 3173.59 53756 3173.59 53756 3173.59 DANFE:

A sefaz aceitou pq as chaves são diferentes. Seu sistema deverá controlar essa informação. Acho isso um absurdo, pois nada impede que o cliente emita uma NF pelo "aplicativo emissor" (ou por outro aplicativo qualquer) e repita números à vontade. Não posso controlar o que ocorre FORA do meu aplicativo. Na minha opinião a SEFAZ deveria no mínimo considerar o trio (cnpj + série + nº da nota) como chave primária e rejeitar duplicidade.

Comigo ocorreu o contrário. O cliente tinha emitido manualmente 2 notas em ambiente de produção pelo "Aplicativo Emissor", aquele feito pela SEFAZ de SP, no final do ano passado. Agora em janeiro, quando terminei os testes com o módulo emissor de NFe do meu ERP e mudei para o ambiente de produção, perguntei quantas NF eles tinham feito por aquele aplicativo. Por engano, me informaram que tinham emitido apenas UMA (esqueceram que foram duas). Resetei a SEQUENCE para a próxima NF ser de número 2 e fizemos uma NF. Ela foi emitida normalmente! Depois, quando perceberam o erro, cancelaram a "segunda" NF nº 2 pelo ERP (já testaram emissão e cancelamento logo de cara). O webservice da SEFAZ daqui não deveria ter rejeitado esta segunda NFe número 2, série 1 -- mesmo tendo sido em anos diferentes? As chaves delas foram as seguintes (removi apenas o CNPJ): 431012...550010000000021119800006 431101...550010000000021813588798

O que falta é gerar o PDF?

Era isso mesmo, obrigado!

Seguem os XML gerados pela aba "Teste" em anexo. 4311933247600010255001000000005000000005-ped-inu.xml 4311933247600010255001000000005000000005-inu.xml PS: Será que tem problema o inicial e o final serem os mesmos? Quero inutilizar apenas UM número.

Não consegui fazer funcionar, vejam imagem em anexo. ACBrNFeMonitor2 versão 0.6.0c.

Mais um "Caso de Sucesso": ontem emiti as primeiras NFe usando o ACBrNFeMonitor2 via Sockets. O cliente, uma rede de lojas, utiliza Linux Ubuntu (versões entre 9.04 e 10.10) nas estações, que são 32 e 64 bits. O meu ERP foi inicialmente feito em Delphi 7, mas está sendo convertido para Lazarus -- a emissão de NFe já está na "versão 3", em Lazarus. O servidor do ACBrNFeMonitor2 é uma máquina Windows XP que fica na Matriz; antes ele rodava apenas o servidor do TEF dedicado (da SiTef). Por enquanto apenas uma das filiais emite NFe, mas o plano é implantar em toda a rede, num total de 11 CNPJ (com 3 "raízes" diferentes). Estou fazendo agora a importação de XML para a "Entrada de Nota" dos fornecedores e implementando alguns detalhes de NFe que ficaram faltando, como anulação de numeração e outros comandos menos usados. Além da NFe, uso o ACBr também para acessar impressoras térmicas (Argox), inclusive já contribuí com patches. Eu também usava os componentes de ECF antes, mas com a chegada do TEF achei melhor focar no ERP (que inclui um WMS bem sofisticado) e terceirizar o PDV. Realmente foi um alívio, pois é complicado dar suporte ao PDV com TEF dedicado numa operação de varejo com tantas lojas.

No processo do meu ERP a DANFE é enviada por email para o cliente e para a expedição, que podem imprimir quantas cópias quiser a partir do PDF. Depois há um processo de "Confirmação de impressão da DANFE" onde o funcionário da expedição lê o código de barras da DANFE para informar ao sistema que ela já foi impressa, tirando da lista de "DANFE a imprimir".

Página 28 do manual: "Identificador de controle do envio do lote. Número seqüencial auto-incremental, de controle correspondente ao identificador único do lote enviado. A responsabilidade de gerar e controlar esse número é exclusiva do contribuinte."

Seu tag diz 2429.98 mas você não passou nenhum vBC nos itens.

Localizei o problema. As mensagens de erro estão vindo em algum ENCODING (aparentemente LATIN1 ou algo assim) que faz a rotina RecvString esvaziar o buffer e retornar uma string vazia. Coloquei um debug pra mostrar byte a byte o que está vindo e no primeiro acento de "ERRO: Falha na validação" já aborta ao tentar adicionar na string. Por enquanto coloquei um teste pra só adicionar na string se o ASCII for abaixo de 127 mas futuramente vou tentar alguma outra solução mais elegante.

Tentei fazer exatamente como o seu código e ainda não funcionou: function TfrmEmissaoNFe.ExecutaComando(cmd: string): string; var respbyte: Byte; resp: string; begin btnAbortar.Enabled := true; btnAbortar.Tag := 0; telnet.SetSendTimeout(200); telnet.SendString(cmd+CRLF+'.'+CRLF); resp := Trim(AnsiToUtf8(telnet.RecvTerminated(TIMEOUT,#03))); if resp = '' then begin respbyte := 0; while (respbyte <> 3) and (btnAbortar.Tag = 0) do begin respbyte := telnet.RecvByte(10); resp := resp + chr(respbyte); Application.ProcessMessages; end; resp := Trim(AnsiToUtf8(resp)); end; btnAbortar.Enabled := false; Result := resp; end; Ainda estou recebendo a string vazia quando há erro. Se não houver erro, funciona normalmente. A constante TIMEOUT está com o valor 500, como no seu exemplo, e declarei telnet:TTCPBlockSocket também. Alguma sugestão? Estou usando o synapse do SVN (revisão 129), FPC 2.4.0 (release) e Lazarus do SVN (branch "0.9.30 fixes", que será o release 0.9.30). Meu Linux é o Ubuntu 10.10 versão 32 bits rodando num vmware dentro de um Ubuntu 10.10 64 bits, o servidor do ACBrNFeMonitor2 0.6.0c é um Windows XP rodando direto na máquina, que além do ACBrNFeMonitor2 roda apenas o software de controle do SiTef.

Estou usando um TTelnetSend. Você declarou fsSock como o quê? Eu vi que no seu código o RecvTerminated pode retornar uma string vazia. Neste caso é preciso ler DE NOVO, desta vez byte a byte? Isso não é estranho?

Eu mostrei aqui os 2 códigos, da rotina de recepção e do teste do OK. Onde estou fazendo errado?

Mas veja o meu código: se "resp" não for 'OK' é executado um "ShowMessage(resp)" que deveria mostrar a mensagem de erro. Está aparecendo apenas uma caixa de diálogo em branco. PS: Estou usando Lazarus no Linux, mas a máquina com o monitor tem Windows XP.

NFE.CRIARNFE(" ... ") ERRO: Falha na validação dos dados da nota 6 TAG: ID:B04/natOp(Descrição da Natureza da Operação) - Tamanho maior que o máximo permitido [VENDA DE MERCADORIA, ADQUIRIDA OU RECEBIDA DE TERCEIROS, SUJEITA AO REGIME DE SUBSTITUICAO TRIBUTARIA, NA CONDICAO DE CONTRIBUINTE-SUBSTITUIDO]. 'VENDA DE MERCADORIA, ADQUIRIDA OU RECEBIDA DE TERCEIROS, SUJEITA AO REGIME DE SUBSTITUICAO TRIBUTARIA, NA CONDICAO DE C...' violates maxLenght constraint of '60'. The element '{http://www.portalfiscal.inf.br/nfe}natOp' with value 'VENDA DE MERCADORIA, ADQUIRIDA OU RECEBIDA DE TERCEIROS, SUJEITA AO REGIME DE SUBSTITUICAO TRIBUTARIA, NA CONDICAO DE C...' failed to parse. PS: Eu sei que a descrição está grande demais, já corrigi, mas gostaria de poder receber estes erros sem ter que olhar o log.

Estou usando ACBrNFeMonitor2 versão 0.6.0c via Sockets. Como obter o retorno dos erros? Tive um erro de validação no campo NATOP porque meu BD tinha uma "natureza de operação" muito grande, com mais de 60 caracteres, mas tive que ver o LOG para achar o erro. Aparentemente o comando "CRIANFE" via Sockets estava retornando em branco. Minha rotina para envio de comandos é bem simples: function TfrmEmissaoNFe.ExecutaComando(cmd: string): string; begin telnet.Send(cmd+sLineBreak+'.'+sLineBreak); Result := Trim(telnet.RecvTerminated(#03)); end; Estou fazendo assim para pegar os erros: resp := ExecutaComando(Format('NFE.CRIARNFE("%s")',[lstNFe.Text])); if LeftStr(resp,2) <> 'OK' then begin Screen.Cursor := crDefault; ShowMessage(resp); Exit; end; Alguma sugestão?

Localizei o problema, meu INI estava indo errado.