wrmedeiros

Antes de criar o tópico fiz várias buscas no fórum, e a recomendação é entrar em contato com o SEFAZ já que a mensagem é genérica (com certeza não teremos resposta no fim de semana rsrs). O tópico em questão é esse (espero que os moderadores não reclamem de duplicidade, pois no tópico fala sobre MT e não AM): Li em algum lugar recomendando aos estados que quando for retornado o erro 999 (não catalogado), o campo xMotivo deveria exibir o exception (CEP inválido, IE inválida, etc.), mas isso não está ocorrendo no AM.

Acredito que é algo no SEFAZ mesmo. Utilizei o UniNFE para testar o SEFAZ-AM e tenho o mesmo retorno. Vejam: https://www.dropbox.com/s/hm7764xsnutfees/UniNFE_Erro_AM.png?dl=0

Pois é, o erro ainda persiste. Atualizei cadeia de certificados e mesmo assim não consigo emitir o NFCe. Alguém está conseguindo via SEFAZ-AM via ACBrNFe2Demo?

Senhores, boa noite! A cerca de 2 meses fiz alguns testes usando o ACBrNFe2Demo e consegui emitir alguns NFCe's utilizando o SEFAZ AM (homologação). Passei algum tempo mexendo em outra coisa (PAF-ECF maldito ), e hoje voltei a brincar com NFCe (fiz o update no repositório do ACBr via SVN, recompilei packages, etc.). Compilei novamente o ACBrNFe2Demo, usei um certificado aqui do RN, configurei os campos, mas informei a UF como "AM" (lembro que precisava disso), em seguida informei uma IE de 9 dígitos e um código IBGE do estado do AM como orientado em outros tópicos, no entanto ao tentar emitir o NFCe surge a mensagem: "Rejeição: Erro não catalogado". Pelo que vi no portal do SEFAZ AM mudaram o esquema para configurar o token (que agora chamam de CSC): Usuários do ambiente de desenvolvedores deverão utilizar o valor fixo “0123456789” para o CSC e o identificador “000001”. Configurei esses valores na propriedade Token e IdToken respectivamente, mas o erro persiste. Estou fazendo algo errado ou o SEFAZ AM está com problemas hoje?

Andei pesquisando, acredito que essa opção de "exportar" um certificado A3 não existe (a chave privada é gravada no token, e a segurança está exatamente no sentido de não ser possível exportá-la). Para clientes que usam A3, a opção seria comprar um A1 para ser configurado em cada PDV (ou comprar um leitor + token para cada PDV, que na minha opinião é inviável).

Bom dia pessoal. Acompanho esse (e outros) tópicos referente a NFCe há algum tempo (leio TODAS as mensagens), e estou começando a implementação do NFCe no meu sistema. Estou avaliando qual a melhor abordagem para implementar no PDV, usando o componente ou monitor. A princípio iniciei o desenvolvimento usando o componente. Minha dúvida é referente ao certificado, tenho que instalar um A3 (token) em cada PDV? (sei que possível comprar A1 com validade de 1 ano) Em um post vi alguém comentando que é possível EXPORTAR o certificado do token e usar como um A1, alguém já fez? funciona mesmo?

Pessoal, desconsiderem esse tópico. Como se trata de um bug do componente, achei melhor registrá-lo na seção "tracker": http://www.projetoacbr.com.br/forum/index.php?/tracker/issue-22-acbrdownload-ignora-erros-404-403-queda-de-conex%C3%A3o-etc/

Boa tarde. Implementei uma operação de download de arquivos usando ACBrDownload, está funcionando sem qualquer problema (barra de progresso, etc.). Nos testes finais decidi simular quedas de conexão, apontamento para URL's erradas, etc., e detectei que existe um problema no ACBrDownload, pois ele não reconhece quedas de conexão, erros de página não encontrada (http 404), acesso negado (403), etc. Por exemplo, abra o demo do ACBrDownload, e informe o link para um arquivo qualquer existente. Ao clicar em download o sistema irá baixar o arquivo sem qualquer problema. Repita o mesmo teste, mas dessa vez usando um domínio inexistente, ex: http://www.testandoumdominioquenaoexiste.com/teste.zip Observe que o sistema irá informar que o download foi concluído com êxito (mesmo o domínio e o arquivo não existindo). Um outro problema se encontra no Demo (exemplo), pois no onDownloadClick é exigido que as URl's contenham WWW, e todos sabemos que isso não é obrigatório (e em muitos casos não tem como colocar, como por exemplo, http;//intranet.meusite.com.br/download.zip). O www é como se fosse um subdomínio, e como tal, pode ser www ou outro nome qualquer.

Bom dia. Italo, posso também ser chato? rsrs PDV 100% online não é uma boa ideia... independente da tecnologia que você usar, uma hora pode falhar (rompimento de fibra, interferência na wifi, etc.), ou pior, o servidor travar, pegar um vírus, problemas de hardware, update quebrar o SO, etc. Existe dezenas de ferramentas e equipamentos para fazer redundância, o que ajuda bastante, mas ninguém garante 100% de disponibilidade. Trabalho com automação comercial não faz esse tempo todo (12 anos), e já perdi as contas de quantas vezes o PDV off-line salvou lojas inteiras de ficar sem vender. Nesse momento inicial talvez o projeto NFCe não esteja preocupado com a disponibilidade, mas deveria =)

Perfeito Ítalo. Obrigado pelos esclarecimentos.

Pois é Diego, eu também venho acompanhando o tópico desde o começo (cada nova mensagem recebo um e-mail), e até então estava sabendo que o código do NFCe ainda estava fechado (apenas para empresas pilotos). Vi as mensagens onde o Ítalo informou que estava usando como base o ACBrNFe (com ajustes), mas ainda não estava no repositório oficial. Mas enfim, mãos a massa!

Pessoal, E a contingência? utilizará as mesmas da NFe? (FS-DA, etc.)

Entrei em contato com o fisco aqui do estado (RN) e fui informado que algumas empresas aderiram voluntariamente ao projeto piloto. Pensei em me candidatar nos testes, mas pelo que vi o código ainda não está no SVN, certo? (pelo que vi no histórico dessa thread, vai ser disponibilizado quando a documentação oficial for publicada). Quando o código for publicado, se puder, avisa nesse tópico. Obrigado a todos.

Sérgio, Aqui no RN só libera o ECF com toda documentação OK (PAF, TEF, e outras dezenas de documentos que o fisco exige)... - ANTES do PAF-ECF nunca exigiram documentação de TEF.... tinha software-house que passva anos sem fazer a re-certificação do TEF.

Sérgio, Eu acredito que a homologação do TEF sempre foi anual... o problema é que antes ninguém cobrava os certificados do TEF... agora com o PAF-ECF ficou bem mais complicado... os certificados do TEF fazem parte da documentação exigida em cada estado. Pelo menos agora podemos fazer a homologação do TEF remota;

Show de bola Daniel. Fiz todos os testes, tudo OK! Obrigado mais uma vez.

Segue diff e pas completo (testei usando ECF Urano, tudo OK). Daniel, por favor, quando revisar e publicar no trunk avise-me aqui pelo fórum. ACBrECFFiscNET_patch_rev2.zip

Beleza Daniel. A tarde estarei na Focus e testo isso. Obrigado.

Senhores, boa tarde! Fiz o update no código, e percebi o seguinte: LMFC......: OK LMFC ARQ..: OK LMFC ATO17: Gerou com a data errada (solicitei 20/04/2012 a 30/04/2012, gerou 17/02/2011 A 04/01/2013) LMFS......: OK LMFS ARQ..: OK ESPELHO...: OK ARQ MFD...: Gerou com data errada também (pelo que lembro ARQ MFD usa o mesmo método de baixar mfd que o LMFC ATO 17) Renomeei o ACBrECFFiscNET.pas, copiei o PAS que enviei pra vocês... refiz todos os testes, os arquivos foram gerados corretamente. Em resumo: LMFC ATO17 e ARQ MFD continuam errados. Vou fazer um diff, se encontrar o que pode está causando esse erro na versão que está no trunk eu envio o patch pra vocês. Obrigado a todos.

Obrigado pelo retorno Daniel. Antes de começar a alterar eu fiz o update no código... mas enfim, na segunda ou terça eu vou está na empresa e faço os testes usando a última revisão. Abraços.

Bom dia Juliomar. Os arquivos estão nesse link (diff, pas completo, documentação, etc.): https://dl.dropbox.com/u/92482115/FOCUS/Urano_ACBr_patch.zip Mas se preferir, eu faço o anexo.

Senhores, boa tarde! A aproximadamente 1 ano testei algumas funções do Menu Fiscal via ACBr e tive alguns problemas para gerar Espelho MFD, Arq. MFD, etc. usando a ECF "Urano" (DLL retornava um erro qualquer, e não gerava o arquivo). Na época recordo-me que cheguei a entrar em contato com a Urano, peguei alguns exemplos, e conversando com um amigo conseguimos corrigir os erros (Douglas da Totall), e enviei para o fórum do ACBr (não lembro o link =). Depois de algum tempo por descuido meu fiz o update no repositório ACBr do SVN, e não atentei que o patch ainda não tinha sido incluído no repositório oficial... liberei a versão do sistema, e alguns clientes começaram a reclamar que o espelho e arq. mfd não estavam sendo gerados. Procurei o patch, encontrei, e fiz a implementação novamente no ACBrECFFiscNET.pas que está no trunk (última revisão): https://dl.dropbox.com/u/92482115/FOCUS/Urano_ACBr_patch.zip Algumas observações: * Geralmente os métodos para gerar CAT-52 das DLL's solicitam apenas o diretório. O nome dos arquivos fica por conta da própria DLL. No caso da Urano isso não ocorre... como não sei se o ACBr tem alguma função para gerar o nome no padrão que o CAT52 pede, eu deixei apenas como "CAT52.TXT"; * É o primeiro patch que submeto ao ACBr, talvez meu código não esteja no "estilo" que vocês codificam; * Eu tive que mudar o tipo da variável de algumas assinaturas dos métodos (sem isso a DLL gerava datas malucas); Talvez isso quebre a implementação para Elgin|Dataregis|Termoprinter que também usam Fiscnet; (não tenho como testar pois não tenho essas impressoras aqui). Qualquer sugestão será bem vinda.

Fala Daniel, beleza? Verifiquei com o blame (SVN), e essa alteração foi feita em 30/07. Quando eu postei a pergunta (13/07) o método "PafMF_GerarCAT52" ainda não existia. De qualquer forma fiz um update no repositório e estou modificando o sistema para usar esse novo método. Obrigado pela dica.

Resolvido. ACBrImpressora.ArquivoMFD_DLL(Inicio, Fim, IncludeTrailingBackslash(Diretorio) + NomeArquivo, [docTodos], finTDM); Welkson

Senhores, Lendo o próprio fórum acredito que encontrei a resposta: viewtopic.php?f=10&t=6522 Vou tentar utilizar o método ArquivoMFD_DLL passando "docTodos" e "FinTDM". Welkson