Alexsander

Hoje se alguém clicar no [X] do ACBrMonitorNFe o programa simplesmente fecha, sem fazer nenhuma pergunta. Acho que deveria haver pelo menos uma pergunta, tipo: "Tem certeza? A loja fechou por hoje, não vai mais emitir NF, é isso?". Um usuário ou mesmo alguém do "suporte" pode fechar sem querer e causar um monte de problemas. Meu pedido é inserir uma confirmação no fechamento da aplicação (no CanClose, por exemplo?).

Reinstalei os certificados e voltou a funcionar. Alguém sabe porque isto pode ter ocorrido?

Começou a acontecer num servidor de um cliente, Windows 2008 server, com monitor 0.7.1a instalado. Estava emitindo NFe normalmente até ONTEM, e sem motivo aparente começou a dar este erro. Não foi instalado nenhum software novo na máquina de ontem para hoje. O servidor tem 2 certificados (de duas empresas diferentes) e até ontem ambas estavam emitindo NFe normalmente. Alguma pista?

Conversando com uma contadora, ela disse que pode ser o seguinte: a Lotérica tinha CNAE de bomboniere, e portanto teve que fazer Inscrição Estadual. Depois o estabelecimento parou de vender bomboniere e deu BAIXA na I.E., passando a ser ISENTO. Nesse meio tempo mudou de endereço e de razão social, também. Assim, na Receita Federal ele está OK e na Receita Estadual ele está "não habilitado". A única coisa estranha é a baixa ter sido em 2007 na SEFAZ mas no site da RFB a última "situação" ser de 2005, mas a princípio pode estar ok. Neste caso, ao conferir CNPJ x IE na SEFAZ (para atender a NT 004/2011), se o "ConsultaCadastro" retornar cSit = 0 talvez a gente tenha que mandar IE=ISENTO mesmo que exista um IE numérico associado ao CNPJ. O que vocês acham?

Testando a NFe.ConsultaCadastro() via ACBrNFeMonitor encontrei uma situação curiosa: um CNPJ, ao ser pesquisado na SEFAZ estadual (via site ou via ACBrNFeMonitor), retorna como Inativo (cSit=0) com dBaixa=xx/xx/2007, estando registrado com uma IE normal e endereço de Porto Alegre/RS. Este mesmo CNPJ, ao ser pesquisado na RFB, retorna como ativo com endereço de Alvorada/RS; ele está cadastrado no sistema como IE=ISENTO. Detalhe: em ambos os casos trata-se de uma lotérica. Quando começarem a cruzar IE x CNPJ nos webservices, como faremos para emitir NFe para este cara?

O ideal é colocar um CHECK no próprio banco de dados. Exemplo: CREATE FUNCTION ean13_gtin14_valido(codigo) RETURNS boolean ... codigo que checa o DV ... CREATE TABLE codigo_barras ( cod_barras bigint primary key, cod_interno integer not null, CHECK (ean13_gtin14_valido(cod_barras)), FOREIGN KEY (cod_interno) REFERENCES produto (codigo) );

Qual é o padrão usado em Belo Horizonte? Porto Alegre vai adotar o mesmo padrão: http://jcrs.uol.com.br/site/noticia.php?codn=72175

Portal (AM): http://cle.sefaz.am.gov.br/portal/ Manual (MA): http://www.sefaz.ma.gov.br/CLe/Manual_d ... ao_1.2.pdf Pelo que entendi a CL-e serve para as transportadores que levam várias NF-e num mesmo frete. O objetivo é agilizar a fiscalização, o fiscal teria que ler apenas o código de barras da CL-e ao invés de ler todas as chaves das DANFE uma por uma. Aparentemente o "Módulo Emissor" roda no próprio site, onde o usuário apenas lê as chaves das DANFE e gera um documento único.

Estou no RS, usando o webservice do RS, e testei o ACBrNFeMonitor via TELNET com o seguinte retorno: NFE.CONSULTACADASTRO(MG,25773037000183) . ERRO: List index out of bounds (0) A NFe.ConsultaCadastro serve apenas para dados da mesma UF em que estamos logados? Existe alguma forma de consultar CNPJ de outros estados?

Estou usando ACBrNFeMonitor. Se duas (ou mais) conexões simultâneas usarem certificados diferentes, pode haver problema se ambas emitirem NFe ao mesmo tempo? Imaginem duas estações, uma da empresa X outra da empresa Y, a primeira dá um SETCERTIFICADO(cert.X), começa a enviar os dados, enquanto isso a estação 2 dá um SETCERTIFICADO(cert.Y), pra começar a enviar os dados, isso não pode corromper a primeira operação, da empresa X? Isso nunca aconteceu mas fico pensando se pode acontecer.

Eu gravo no banco de dados.

Eu tenho orientado os clientes a solicitar o XML aos fornecedores, via e-mail -- sem XML é preciso digitar a NFe de entrada como se fosse uma modelo 1. Assim a cobrança por parte do setor de compras é grande (pois naturalmente não querem ficar digitando) e os poucos fornecedores que não enviavam o XML rapidinho se prontificaram a enviar. Quem emite NF-e tem o XML, se não envia é por "descuido". Tem funcionado.

Estava em zero... este campo é novo? Antes estava funcionando.

Estou com este mesmo problema, começou a ocorrer depois que troquei da 0.6.0c para a 0.6.1c CAPICOM. Alguém tem alguma pista do que pode estar acontecendo? O arquivo XML está correto.

Perfeito, funcionou. Obrigado!

Usando ACBrNFeMonitor2 CAPICOM 0.6.0c (já devidamente atualizado para 0.6.1c) num Windows XP. A NF-e foi gerada e emitida, mas deu "Access Violation" e não foi gravado no XML o protocolo de autorização. No site da SEFAZ, via chave de acesso, a NF-e consta como autorizada normalmente. Tem algum comando do ACBrMonitor pra fazer isso depois da NF-e já emitida?

Geralmente as mensagens de erro estão em ordem inversa: o TAG que causou erro é o último a ser mencionado.

http://anfm.blogspot.com/2009/09/campos ... ndo-o.html

http://anfm.blogspot.com/2010/02/comand ... nitor.html

Você monta o TXT naquele formato que lembra um INI, manda pro monitor (via diretório ou sockets) e, com o comando "CriarNFe", ele monta o XML. Além de montar o XML o ACBrMonitor também pode validar o XML, assinar o XML, mandar o XML pra Sefaz, enviar XML e PDF por email para o cliente, imprimir a DANFE, lavar, passar e cozinhar.

Há duas maneiras: - via um arquivo TXT em um diretório específico do computador onde o ACBrMonitor está instalado - via sockets, conectando e enviando comandos para o computador onde o ACBrMonitor está instalado

The element '{http://www.portalfiscal.inf.br/nfe}NCM' with value '4011' failed to parse O campo NCM tem que ter 8 dígitos.

DANFE que difere da XML abre margem até mesmo para fraudes!

Não era este o problema, Mauricio, mas obrigado mesmo assim. O problema está resolvido pra mim: era uma questão de ENCODING.

Claro q sim .. Alexsander Sem problemas .e vamos para outra. Você não entendeu! Eu usei o exemplo de 0,125 que pode ser 0,12 ou 0,13 conforme a "regra de desempate" escolhida pelo aplicativo (ou humano). Você usou os exemplos 0,1253 e 0,1252 que, obviamente, devem ser arredondados SEMPRE para 0,13 porque não requerem desempate, visto que HÁ algarismo depois do 5. Leia o artigo que indiquei pra entender. Eu nem deveria estar dando explicação, mas 7 anos como professor universitário me deixaram com este hábito...