Alexsander

Aqui no RS funciona com certificado, acredito que com o tempo todas as UF seguirão o mesmo caminho. Além do download do XML existe até um portal onde o usuário pode tirar um EXTRATO das NF emitidas e recebidas num período. Mesmo assim o original fica guardado, mesmo que o usuário mande errado ou delete. Basta o cliente pedir -- e se o cadastro for corrigido, os próximos vão pro endereço certo. Nós gravamos o XML também no banco de dados e não existe opção na interface para o usuário deletar de lá. A maioria das grandes fábricas no Brasil envia o XML por email quando solicitado. Uma pressão tipo "a direção determinou que a partir do dia X não deixaremos o caminhão descarregar se o XML não tiver sido enviado" (mesmo que depois o prazo seja prorrogado várias vezes) AJUDA, ainda mais se vier de vários clientes. Pelo menos aqui no RS, se mesmo assim o fabricante insistir em não enviar, no portal da SEFAZ dá pra baixar o XML. Na minha opinião o único problema é com as transportadoras, que AINDA não podem baixar o XML via portal mesmo com certificado. Mas tenho certeza que isso vai ser contornado em breve, pois é trivial checar o CNPJ do certificado com o CNPJ da transportadora informada no XML.

Exatamente. Nosso ERP, por exemplo, envia automaticamente um email para o destinatário/remetente MAIS uma cópia para uma lista de emails configurado por filial MAIS uma cópia para uma segunda lista (opcional) configurável por parâmetro global. Se o campo "email_nfe" do cliente estiver em branco, o sistema simplesmente NÃO emite a NFe, avisando que este campo PRECISA estar preenchido. Da mesma forma, o campo CC: do cadastro do emitente também precisa estar preenchido. Ambos os campos exigem emails válidos, checados via CONSTRAINT no banco de dados. O sistema permite ainda ; como separador de múltiplos emails. Por exemplo: numa rede de lojas, a filial 15 pode ter seu CC: (obrigatório) com "[email protected];[email protected]" e o email extra (opcional) pode estar configurado globalmente como "[email protected];[email protected]". Assim todo mundo recebe os emails com PDF + XML automaticamente.

Se as empresas clientes destes contadores e transportadores tivessem um sistema melhor, que salvasse os XML emitidos e recebidos, nada disso seria necessário. Pronto, fiz o meu merchan.

Pra mim deveria haver um site para download com certificado. Assim todo mundo poderia baixar, mas somente as suas NF-e. Para isto bastaria comparar o CNPJ da NF-e (emitente, destinatário ou transportadora) com o CNPJ do certificado. Hoje o RS faz quase isso, mas não contempla as transportadoras.

Vai ficar obsoleto, tenho certeza disso. No RS e em SP ele já está obsoleto pra quem tem certificado digital, porque o site da SEFAZ permite o download do XML -- e muito mais: existe um "Extrato do Contribuinte" que permite ver, em forma de tabela e individualmente, todas as NF-e emitidas e recebidas num período. O problema vai ser pra quem AINDA não emite NF-e, só recebe, e não tem certificado. As alternativas são a) adquirir um certificado ou adquirir um sistema que emita NF-e. Mas quem quiser continuar emitindo apenas Modelo 1 que fique esperto: podem ter certeza que em breve terão que emitir NF-e. Tudo é apenas uma questão de tempo.

Aqui fizemos assim: pode cadastrar sem email, mas não emite nota. Na hora de emitir, o sistema mostra a mensagem: informe o email de NF-e. Sem este e-mail, não emite. Ponto. Se reclamarem, mostro a legislação de 2010 e digo que o sistema do outro está defasado. Além disso eu gravo o XML numa tabela do banco de dados (além da pasta que o ACBrNFeMonitor grava), se precisar mandar novamente o e-mail (ou mesmo mandar para outro email), basta alguns cliques. Eu sempre insisto na tecla de que a NF-e é o XML, a DANFE é apenas um papel que se torna irrelevante depois que a mercadoria circulou. O problema é que as empresas (e os contadores) têm o hábito arraigado de querer um monte de papel, é quase uma segurança psicológica. Uma coisa que ajuda a esclarecer o usuário é mostrar, no site da Receita, o quanto de informação tem numa NF-e que não sai impressa no DANFE. E mais: a NT 001/2012 permite que o DANFE seja impresso num papel térmico, daqueles amarelos de 55 mm, só com a chave e mais meia dúzia de coisas. Diga algo assim: "não duvido que daqui a uns anos o DANFE seja apenas uma etiqueta com a chave impressa, em que o fiscal lerá o código de barras num PC portátil e pegará os dados da NF-e". Isso costuma abrir os olhos das pessoas. Mas este é o caminho: mostre a legislação e mencione o caso do colega aqui do Fórum (tópico "Sefaz na minha cola"), que foi indiciado pelo Ministério Público por conta de bugs na emissão na NF-e. A fiscalização não quer saber: bug ou má-fé, entra todo mundo no mesmo bolo. Eu não quero como cliente uma empresa que deseja burlar o fisco, prefiro perder o negócio. Agora, com a NF-e, a casa sempre cai, é só uma questão de tempo.

Aqui no RS o site da SEFAZ tornou obsoleto o Recupera XML.

Concordo que é o momento para nossos clientes pressionarem seus fornecedores, e quem sabe com esta atitude a Receita está pensando justamente nisso: em forçar as empresas a seguir a legislação: Ajuste SINIEF 07/2005, cláusula 7ª, § 7º, conforme alterado pelo Ajuste SINIEF 08/2010) http://www.fazenda.gov.br/confaz/confaz ... 007_05.htm

A pergunta é: como exigir dos fornecedores (geralmente fábricas) o envio do XML? No meu software o "Recupera XML" só era usado na "Entrada de NF de Fornecedor", para obter os XML de NF-e emitidas por fornecedores que não enviam o XML por email, como deveriam. Muitos simplesmente não enviam NADA, só o DANFE com as mercadorias.

Isto afeta o suporte ao Lazarus de alguma forma?

Parabéns!

Troquei hoje para a 0.7.1c e melhorou bastante, especialmente o acúmulo de consumo de RAM depois de algumas horas de uso.

Baixei esta versão e vi que ela LIMPA o "Memo" da tela principal de tempos em tempos. Isso talvez solucione o problema de ocupar centenas de megabytes de RAM depois de ficar algumas horas emitindo notas, o que fazia até dar umas travadas.

Qual versão você usa, Adilson?

Estou com um problema sério na emissão das NF-e: somente uma conexão consegue emitir NF-e de cada vez, mesmo que eu coloque "conexões simultâneas" com 5, 10, etc. Se alguém tem isto funcionando, por favor me explique qual foi o truque. São várias filiais emitindo com o mesmo certificado, se uma delas estiver mandando um comando (digamos, NFE.ENVIARNFE) as demais não conseguem enviar comandos. Nem mesmo o NFE.ATIVO responde. As filiais estão orientadas a "seguir tentando" até conseguir "pegar" a conexão. O processo mais demorado é o envio do email; às vezes a emissão ocorre em 4 ou 5 segundos mas o envio do email demora dezenas de segundos, conforme o servidor SMTP de destino. Nesse meio tempo ninguém consegue emitir nota alguma, ficam todas as filiais esperando. Pensei em criar uma FILA para gerenciar isto, e me ocorreu que esta FILA poderia estar no próprio componente (ou no aplicativo ACBrNFeMonitor). O monitor retornaria uma mensagem tipo "Colocada na fila, posição X"; poderia ser criado um novo comando para consultar a posição na fila, de modo que a GUI lá na ponta pudesse ficar atualizada, dando ao usuário uma noção de quanto tempo vai ter que esperar. 1) As conexões simultâneas funcionam? Se sim, como? 2) Se não funcionam, esta idéia da fila faz sentido? Posso fazer um patch. PS: ACBrNFeMonitor 0.7.1a - CAPICOM num Windows XP (i5 2500 c/ 4Gb RAM) rodando só o monitor. O link de Internet da matriz é de 35 megabits; as filiais têm entre 10 e 15 megabits.

Gostaria que o pessoal aqui desse um relato de como está usando o ACBrNFeMonitor 0.7.1a via sockets. Tenho a nítida impressão de que ele não permite mais de uma conexão ao mesmo tempo, apesar do "conexões simultâneas" estar em 5, pois seguidamente os usuários reclamam da mensagem "Servidor NFe OFFLINE", que aparece quando o "NFE.ATIVO" dá timeout ou não retorna OK. Olhando nos logs, assim que um usuário termina de enviar a NFe o "NFE.ATIVO" volta a funcionar. Além disso, depois de algumas horas de uso o monitor começa a ocupar 200, 300 mega de memória e trava, precisando ser parado via Gerenciador de Tarefas. A máquina é um i5 2500 (quadcore) com XP 32 e 4 Gb de RAM (só reconhece 3,4 Gb). No servidor anterior, um Windows SERVER 2008 com 16 Gb de RAM, que era 64 bits, o monitor funcionava pior ainda, travava a cada 10 minutos. O que estou fazendo de errado?

Algum dia um contador vai pedir que seu cliente emita uma NF-e de ajuste. No meu caso, foi somente neste dia que eu descobri que o "Manual" do ACBrNFeMonitor [1] e [2] estava ERRADO e que bastava colocar o código de 1 a 3 diretamente no campo Finalidade= para tudo funcionar. [1] http://acbr.sourceforge.net/drupal/?q=node/40 [2] http://anfm.blogspot.com/2009/09/campos ... ndo-o.html

Nunca testei, mas provavelmente se mandar os acentos em UTF-8 deve funcionar. No início de cada arquivo XML tem o encoding dele, veja: <?xml version="1.0" encoding="UTF-8"?>

Isso poderia estar numa configuração, não? Por exemplo, na classe TGeralConf da unit ACBrNFeConfiguracoes poderia haver uma propriedade FQuebraLinha: Char com valor default ';' definido no Create. Até no ACBrNFeMonitor poderia haver uma opção na GUI e no INI com este valor.

Passa, sim. Tenho um cliente que faz transferência entre filiais usando 4 casas decimais no preço unitário e está emitindo normalmente. Quem usa o ACBrNFeMonitor tem que olhar o campo "Decimais do preço unitário" da configuração da DANFE.

Tive um problema similar, uma sugestão seria o ACBrMonitor se negar a criar NFe com mais de 500 Kb na chamada ao CRIARNFE.

Acho que o mínimo seria: 1) Criar NFE 2) Enviar NFE 3) Enviar email (com CC: para o setor que vai imprimir)

http://www.tecnospeed.com.br/blog/nfe-f ... a-fraudes/

Você está usando em cNF o mesmo valor de nNF, nunca faça isso. Conforme o manual, o valor de cNF deve ser um número aleatório, use o Random() para gerá-lo. Se você tivesse usado um número aleatório as duas chaves seriam diferentes, não teria ocorrido este problema e não haveria suspeita de fraude. Além disso, com cNF e nNF iguais os clientes do seu cliente podem facilmente consultar as NFe dos outros clientes do seu cliente, apenas variando o número das tags cNF/nNF e calculando o dígito. Se o seu cliente é uma fábrica, todos os lojistas que compram dele podem ver as compras dos concorrentes, o que pode causar stress desnecessário: um lojista pode reclamar algo tipo "porque a loja tal comprou menos que eu e teve um desconto maior?". Um dos motivos deste número ser aleatório é justamente a privacidade.

Desde o início de 2012 tenho visto em meus clientes um aumento significativo no número de NF denegadas por irregularidade fiscal do destinatário (cStat=302), pelo menos aqui na SEFAZ do RS. Alguém sabe se houve alguma mudança em relação a isto recentemente?