Alexsander

Eu gerei uma NFe com o ACBrNFeMonitor 2 versão 0.6.0c e passei um valor em "[identificacao] ... Codigo=" (conforme [1]) mas aparentemente ele foi ignorado, pois a chave da NFe foi gerada com o número "55" neste campo. Estou fazendo algo errado ou é algum bug? [1] http://anfm.blogspot.com/2009/09/campos ... ndo-o.html

Como estão as homologações ultimamente? Continuam reprovando a maioria dos que tentam fazê-las? Os custos continuam os mesmos?

Eu fiz uma modelagem de layouts que permite ao usuário criar qualquer modelo de etiqueta, ele informa o número de etiquetas por linha e todas as dimensões (altura, largura, espaçamentos, etc). O sistema tem um modo "teste" que imprime retângulos dos tamanhos informados, para testar o layout. O sistema permite que sejam salvos infinitos layouts. Claro que isto tudo está vinculado ao ERP, pois o usuário escolhe os campos que vai imprimir em cada layout, a partir das tabelas do banco de dados.

Coloque "00", veja o documento abaixo: http://www.nfe.fazenda.gov.br/portal/do ... 10.001.pdf

Acho que ele se refere a uma legislação específica de SP: http://www.a2office.com.br/Inf_06.htm http://www.contabilpirituba.com.br/contabil/dicas.php Pelo que diz no manual, a NFe não tem suporte a isto.

Sim, eu pensei nisso, mas achei que seria interessante ter uma opção mais elegante.

Sim, imprime. Eu uso no meu software -- até colaborei com o ACBr enviando alguns patches.

Alguns fornecedores de SP têm uma IE no RS para recolher o ICMS ST. Provavelmente eles repetem o IE para as NFe dentro do estado de origem deles (SP) mas quando emitem uma NFe para o RS eles usam a IE do RS. Talvez seja o seu caso.

Estou testando o ACBr CAPICOM com um certificado, e em breve o cliente vai obter outro certificado para uma empresa do mesmo grupo que não é filial (não tem a mesma raiz do CNPJ). Vi que posso alternar entre certificados usando o comando "SetCertificado" mas não achei nenhum comando para LER qual certificado está em uso. Gostaria de poder testar, antes de enviar, se o certificado em uso é o correto -- e alterar para o correto, se necessário. Vi que existe um comando para ver da DATA do certificado, mas sinto falta de um que retorne algum tipo de identificador. Alguém mais está usando mais de um certificado na mesma máquina, alternando conforme o emissor?

Somente consultar a nota na Sefaz não resolve. A nota pode estar OK na sefaz, porém se XML recebido não tiver o protocolo de autorização da receita ou estiver fora de padrão, você não poderia contabilizar o mesmo. conforme dito antes, a NFe é o XML, nada pode substituir o mesmo (desconsiderando os casos de contigência é claro). Temos vários casos: - XML com protocolo, SEFAZ autorizada (tudo certo) - XML com protocolo, SEFAZ não autorizada - rejeitada, denegada, etc. (fraude ou emissor bugado) - XML sem protocolo (ou fora do padrão), SEFAZ autorizada (enviaram o XML errado) - XML sem protocolo (ou fora do padrão), SEFAZ não autorizada (fraude ou emissor bugado) - XML sem protocolo (ou fora do padrão), SEFAZ desconhece a NFe (fraude ou emissor bugado) Entendo que SOMENTE consultar na SEFAZ não é suficiente, mas somente olhar o XML também não é. A não ser que eu esteja enganado, o ideal -- para estarmos 100% cobertos -- seria verificar todas as NFe recebidas pra ver se o XML bate com a SEFAZ.

Testei aqui, para UF diferente da minha deu erro, mas para os emitidos aqui no estado deu OK. Eu tinha pensado em algo assim: no momento do recebimento da mercadoria, ao descarregar do caminhão, o usuário poderia ler o código de barras da DANFE para que o sistema 1) localize a NF com os itens, previamente carregada via XML e 2) verifique se a NFe está OK, se o DANFE não foi falsificado ou se a NFe não foi cancelada/rejeitada. O problema é que (aparentemente) não dá pra consultar NFe emitidas em outros estados usando os componentes, logo é impossível checar de forma automatizada se a NFe recebida foi de fato autorizada e está OK. Se o fornecedor inventou aqueles números de protocolo ou mesmo se a NFe foi rejeitada, não temos como saber... ou temos?

Mas não seria interessante checar via webservice na SEFAZ? E se o fornecedor falsificou as tags de autorização?

Estou desenhando um processo em duas etapas: 1) Carga do XML (em lote, com FindFirst/FindNext) - apenas carrega o XML para o BD sem maiores processamentos além de extrair a chave de acesso e algumas informações bem básicas; 2) Processamento da NFe de Entrada - tenta identificar os produtos automaticamente pelo mapeamento CNPJ x cProd (que é o código interno do fornecedor, cadastrado como "referência" no cadastro do meu ERP). Se não encontrar, tenta pelo EAN -- e se tudo mais falhar, pede pro usuário fazer o mapeamento (e o salva para uso futuro). Depois que todos os produtos da NFe forem identificados o sistema segue o processo normal de recebimento de NF (conferência, entrada no estoque, etc).

Exemplo: 0 10 0 990.13 12.00 118.81 4 1675.46 61.16 166.01 Veja o campo "pICMSST", ele deveria ser o % do ICMS (17.00) mas no XML veio o MVA (61.16). O campo "pMVAST", que é opcional, não foi enviado. No final, o valor do ICMS ST está correto, apesar do % errado enviado -- aparentemente o software emissor dele enviou o conteúdo do campo "pMVAST" no campo "pICMSST". vBCST = (vBC + vIPI) * pMVAST = (990,13 + 49.50) + 61.16% = 1675.46 vICMSST = (vBCST * pICMSST) - vICMS = (61.16% de 1675.46) - 118.81 = 905.90 (!) Na prática o campo vICMSST foi calculado certo: (17% de 1675.46) - 118.81 = 166.01 Segundo o manual 4.01 (p. 40), apenas o ICMS "padrão" (vBC * pICMS) é checado. Quando há S.T. nenhum cálculo é feito nos campos adicionais -- pelo menos por enquanto. Isto é um problema para quem vende com ST 60 porque o grupo ICMS60 (p. 133) requer os campos vBCSTRet e vICMSSTRet -- que em teoria são calculados a partir de valores informados pelo fornecedor, na sua NFe, nos campos vBCST e vICMSST. Pra piorar, quando não houver estar informação será preciso calcular via MVA -- que no exemplo acima, sequer foi informada.

Vocês têm importado XML dos fornecedores? Tenho visto várias coisas estranhas, como campos opcionais como o EAN vindo com zeros (0000000000000) ou erros de preenchimento (um fornecedor colocou a MVA de 61.71 no campo pICMSST (que devia ser 17.00). Parece que tem muita gente fazendo emissão de NFe "nas coxas". No comércio, para emitir uma NFe de um produto com S.T. geralmente se usa CST 60, e teoricamente o fornecedor teria que ter colocado CST 10 na sua NFe. Há exceções, como sempre, conforme os estados de origem e destino -- há casos em que a NFe vem com tudo CST 00 e a cobrança de S.T. vem em guias separadas. O caso é que no registro ICMS60 tem dois campos, BC da ST e Valor da ST, que em teoria teriam que vir direto da NFe de entrada com CST 10. Quais as validações que a SEFAZ faz no XML? Naquele caso em que o fornecedor colocou 61.71% como percentual de ICMS, o valor vICMSST estava correto, calculado com 17%, apesar dele ter informado 61.71%. Até que ponto pode-se confiar no que vem no XML?

Não seria Frete=9 (sem frete) na versão 2.0?

Outra pergunta: estão salvando o XML da Nf-e no banco de dados? Se sim, em campo TEXT ou BLOB?

Eu pergunto porque a maioria dos softwares que emitiam NF modelo 1 em formulário contínuo tinham apenas um campo para volumes e, quando adaptados para NF-e, continuaram mandando apenas uma ocorrência. Peguei um lote com centenas de XML de NF-e de fornecedores para carregar e não vi nenhum caso de enviarem o grupo "vol" com mais de uma ocorrência. Alguém já viu uma NF-e real com múltiplas ocorrências?

Alguém já recebeu ou emitiu uma NFe com mais de uma ocorrência da tag "vol"? O manual diz 0-N mas no layout da DANFE só tem espaço para uma ocorrência.

Estou pensando em criar tabelas separadas para ICMS, IPI, II, ISSQN, PIS, COFINS, etc. Elas teriam como chave primária um ID resumido da NFe + a seqüência do item. Por exemplo, id_imposto = cod_imposto(2) + campos AAMM (4) + cNF da chave (8) + nItem (3) concatenados num BIGINT. Assim, na tabela de itens eu poderia ter uma coluna "icms" com NULL ou id_imposto, outra coluna "ipi" com NULL ou id_imposto e assim por diante.

Continuando: quando vocês importam os XML recebidos dos fornecedores, como armazenam? Gravam o XML bruto em algum lugar e pesquisam dentro dele (usando as tags) conforme a necessidade ou decodificam o arquivo e gravam num banco de dados?

A minha modelagem atual não tem lugar para gravar informações como "Tipo de Emissão da NF-e" (tpEmis) ou "Quantidade Tributável" (qTrib) nas NF de entrada dos fornecedores, entre outros. Pelo que vi, para emitir a NF-e de venda no comércio vou precisar de muitas informações que vêm nos XML das NF-e dos fornecedores -- por exemplo, cada produto vendido com CST 060 tem que informar BC e valor do ICMS-ST retido, que foi informado na NF-e do fornecedor, onde ele veio com CST 010. Antes de simplesmente sair adicionando campos em tabelas conforme a necessidade, pensei em aproveitar o momento para fazer uma REFORMA na modelagem para suportar todos os tipos de NF-e possíveis, inclusive de produtos que nenhum cliente meu vende hoje como carros 0 km e armamentos. Parece interessante ter um "espelho" da NF-e do fornecedor no banco de dados -- importado a partir do XML.

Acho que deve ser 2C ou 2D, que são os cupons fiscais.

Jaime, a versão CAPICOM eu consegui fazer funcionar. Estou tentando usar a versão OPENSSL porque futuramente quero ajudar o Daniel a portar o ACBrNFeMonitor para Lazarus. Por enquanto não chega a ser problema usar a versão CAPICOM porque este cliente tem uma máquina Windows XP que roda exclusivamente o software do TEF, esta mesma máquina poderia rodar o ACBrNFeMonitor com folga. No entanto, nem todo mundo usa TEF; seria interessante ter uma solução 100% Linux.

Baixei a versão CAPICOM 0.6.0c e funcionou. Eu exportei o certificado seguindo estas instruções: http://www1.serpro.gov.br/servicos/help ... t_cert.htm Preciso fazer algo mais para o arquivo PFX funcione, alguma forma diferente de exportar, algo assim? Ah, outra coisa: a versão CAPICOM pede senha (da CrypyoAPI) na primeira vez em que um comando é enviado (quando o monitor é reiniciado), tem como evitar isso? A opção "salvar senha" da janela da CryptoAPI aparentemente esquece a senha quando o monitor é reiniciado.