Paulo Tenório

Perfeitamente... Anexado. log.txt

Bom dia amigos, Atualizo e compilo, semanalmente, uma versão atualizada do ACBrMonitorPlus. Como, atualmente, a maioria dos fornecedores enviam o XML por e-mail somente hoje percebi uma falha que não ocorre até a versão 0.3.08.2. O comando é executado, o XML é recebido (se encontra na pasta de troca de arquivos com a SEFAZ) e exibe a mensagem da imagem anexa.

Perfeitamente. Segue um XML que usa duas páginas... 32160927550193000100550010000237551484944575-nfe.xml

Boa tarde amigos, Dificilmente as notas geradas aqui na empresa ultrapassam o número máximo de itens que cabe em uma página. Hoje ocorreu uma grande transferência de itens e, ao visualizar o DANFE, percebi que o primeiro item da segunda página fica desalinhado em relação aos demais.

Antes da correção enviada pelo Daniel eu já usava o download pelo ACBrMonitorPlus e não tinha nenhum problema. Alguns terminais é que corrompiam o arquivo ao realizar uma cópia através do copyfile do Delphi ou do savetofile do ACBrMonitorPlus. Copiando pelo explorer, nunca corrompia. Removi o mapeamento da unidade de rede e passei a utilizar o caminho completo dos arquivos no servidor com o CopyFile e o problema acabou.

Eu migrei de TXT para Socket e não tenho do que reclamar, só agradecer. A performance melhorou, a necessidade de processamento diminuiu e a qualidade do componente se manteve. Se você está com problemas de comunicação, com certeza, não se deve ao componente.

Aparentemente você trocou a pasta padrão de 'WEBSERVICE_ENV-REC' para 'logs', correto? Isso não é problema, é só para alinhar o raciocínio. Eu já tive esse tipo de problema causado durante as operações de cópia de arquivo. O arquivo 100% confiável é o da sua pasta 'logs', pois é o arquivo original recebido diretamente do Webserver da SEFAZ. Ele chega com '-down' acrescentado ao nome. Qualquer outro derivado dele pode ser vítima do efeito página de código, que parece ser o seu caso. Outra possíbilidade é estar trabalhando com cópia de arquivos em rede. Tive problemas em algumas máquinas que não aceitaram bem trabalhar com unidades de rede mapeadas, uma boa prática é utilizar sempre o endereço IP e o caminho, sem uso de DNA, seja ele local ou remoto.

Foi resolvido o problema no Update 1 do Berlin. Instalei, testei e agora está redondinho.

Dei uma olhada na referida unit e parece que está mesmo remendada, tem linhas comentadas. Soltaram a versão final e esqueceram de revisar. Para corrigir precisaria estudar todas as outras units envolvidas. Alguém já resolveu?

Você pode entrar no repositório do projeto e solicitar que seja adicionado como commiter.

André, Acredita que será possível implementar essa funcionalidade ao componente ou devemos encontrar outra forma de fazê-lo? Não é algo imprescindível mas seria interessante ter. Obrigado.

Pelo ACBrNFe , a assinatura do anexo retorna como inválida mas, validando no site da SEFAZ-RS a assinatura é válida. TERCEIRO_OK_35160704054485000157550010000533001075008010-nfe.xml Execução do sistema com o erro apresentado.

Sim André, após carregar o XML do fornecedor eu chamei o método NotasFiscais.VerificarAssinatura(Erros) e deu como válidos os XMLs próprios e inválidos todos os de terceiros. Verifiquei no validador da SEFAZ-RS e todos foram validados.

As notas que eu emito e assino são validadas corretamente. Nenhuma nota de terceiro valida. Todas elas são rejeitadas, embora sejam validadas pelo site da SEFAZ-RS. Acho que o método é somente para assegurar que as notas próprias estejam ok. Para notas de terceiros, vi algumas coisas em JAVA. Seria excelente ter isso no ACBr.

Os fontes do repositório original estão incompatíveis com o Berlin. Alguém sabe de algum fork ou precisamos fazer na mão mesmo?

ES Idem. Acho que só manualmente, pelo portal, será possível baixar.

Isso é normal. Enfrento diariamente esse problema com notas de fornecedores, cada um calcula de um jeito. Até a SEFAZ tem uma faixa de tolerância com base no problema de arredondamentos por entender que seria trabalhoso demais controlar esses "milavos".

A SEFAZ informa sim. Na primeira consulta que você fizer após a manifestação de ciência, ela retornará como um evento para a referida chave. A única falha do processo, na minha opinião, reside no fato de você não receber nada sobre o documento antes de manifestar essa ciência. Somente no portal terá a história completa do documento. Você pode criar flags para marcar as manifestadas com ciência mas eu sugiro que você crie um campo mais genérico para a situação/status pois, existem tratamentos e validações que se baseiam na situação atual do documento. Eu montei um processo que envolve 3 tabelas: Uma de Documentos Fiscais (NFe), uma de Eventos e outra de Documentos Fiscais Destinados. Com essas 3 tabelas eu sei se posso fazer o download do XML, cancelar, manifestar como não-realizada, desconhecida, etc. Eu gostava mais do processo antigo, era mais confiável e completo mas é uma imposição da SEFAZ, portanto, temos que fazer com que funcione em nossos sistemas da melhor forma possível.

Na minha opinião, os componentes ACBr são uma ferramenta de apoio para programadores, não uma solução pronta para clientes. Eu resolvo a questão aqui da empresa em que trabalho abrindo uma sessão do ACBrMail e adicionando os parâmetros necessários para o envio. Monto uma consulta para retornar os registros do período desejado, faço um loop nesses registros, pego o nome do arquivo XML de cada uma e vou anexando. Terminado o loop, é só enviar. O trabalho pesado o ACBrMail faz todinho, é só somar à ele a habilidade do programador. Acho perigoso deixar esse trabalho para ser feito manualmente pelo cliente e também acho fora da alçada do projeto ACBr oferecer tal funcionalidade pois, cada sistema e cada banco de dados tem suas particularidades.

Se prepare para perder muitos detalhes que vinha acessando. O novo método destruiu o controle perfeito que eu tinha antes. Na ConsultaNFeDest eu ficava sabendo quando o emitente transmitia, cancelava e/ou inutilizava o documento, independente da minha manifestação. Eu mantinha toda a minha base de notas sincronizada com a SEFAZ e recebia todos os eventos. Agora, só recebo o que acontece após a minha manifestação, não sei mais se uma nota emitida foi cancelada caso o cancelamento tenha ocorrido antes da minha manifestação de ciência, etc. Se a mudança foi uma evolução, ou eu não entendi o novo conceito ou isso só melhorou para a SEFAZ. Boa sorte na empreitada..

Bruno, Não se esqueça de que o DANFE é somente um documento físico, sem validade fiscal, que serve simplesmente para acompanhar a(s) mercadoria(s) envolvidas na NF-e. Com raras ressalvas, seu layout é livre e os dados impressos são, resumidamente, os mais relevantes para uma conferência inicial em caso de fiscalização. Nenhum DANFE é aceito como prova de defesa ou acusação em casos de auditoria fiscal. Concluindo, o importante na geração de uma NF-e é o cuidado e correto preenchimento dos campos previstos e orientados pelos manuais, o resto é enfeite, comentário ou informação adicional julgada relevante nos processos de movimentação de estoque de cada empresa.

O objetivo foi alcançado. Agora, quando o servidor de e-mail demora na autenticação, os comandos seguintes não travam o ACBrNFeMonitor Plus..

Não seria a falta de aspas nos parâmetros?

Obrigado Daniel, vou compilar e testar. O envio pode continuar demorado ou "de castigo" esperando por um tempo. O que espero conseguir é fazer outras solicitações ao ACBrMonitor Plus sem a necessidade de esperar pela conclusão do envio. Volto para postar o resultado.

Bom dia amigos, Algumas vezes a Locaweb, onde está hospedado nosso domínio, demora muito para autenticar o usuário/senha. Em alguns casos chega à cinco minutos, acho que eles fazem de propósito quando o usuário envia muitos e-mails seguidos, mas não posso evitar pois tenho que enviar os XML/PDF. No componente acbrmail existe a propriedade configurável de utilizar ou não o recurso de thread. No ACBrMonitor Plus não existe esta opção. Existe alguma contra-indicação ou é somente falta de tempo ou baixa prioridade para essa implementação? Obrigado,