Fabrício G. Araújo

Isso mesmo @claudiomiguelmuller, conforme está na NT_2016_002_v1 51: Em relação a NFC-e, os prazos previstos são: - Desativação do versão 3.10 do leiaute da NFC-e: 01/10/2018; - Layout do QR-Code (tag: qrCode, Id:ZX02), versão “2.00”: - Ambiente de Homologação: 04/06/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Ambiente de Produção: 02/07/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Desativação da versão “1.00” do QR-Code em produção: 01/10/2018.

Me lembro que testei a 1 mês atrás e em MT ainda não estava disponível a NFC-e 4.00 em produção, mas em outros estados como GO e MA que já testei e está emitindo normalmente em produção NFC-e 4.00. Na prática todos os estados que possuem NFC-e já eram para estar emitindo desde DEZ/17, só MT que pelo jeito não conseguiram se adequar e aproveitaram os novos prazos para o Qr-Code 2.0 e até hoje não disponibilizaram... é complicado quando nem as SEFAZ cumprem os prazos definidos pelo governo... mas nós temos que cumprir né, fazer o quê.

Pessoal, vale lembrar que a nova versão 4.00 está documentada desde a NT_2016_002_V1.00, que é de novembro de 2016, na época os prazos eram esses: NT_2016_002_V1.00: Ambiente de Homologação (ambiente de teste das empresas): 01/06/2017 - Ambiente de Produção: 01/08/17 - Desativação da versão anterior: 06/11/17 Tudo bem que houveram algumas modificações nas notas técnicas seguintes, mas digamos assim o "grosso" da coisa já foi definido a muito tempo. Acredito que não cabe mais adiamentos para NF-e, mas a própria NFC-e já teve seu adiamento né, com o Qr-Code 2.0. E vamos que vamos... boa sorte a todos.

Olá @tiago Selecto, verifica a documentação das notas técnicas para saber quais campos disponíveis existem para cada situação tanto de CST quanto de CSOSN. Um tempo atrás postei um resumo com os diagramas de cada opção disponível na versão 4.00. Dá uma olhadinha lá, talvez ajude:

@thiagosabino, infelizmente não estou com certificado em mãos agora para testar, mas te digo que emiti várias notas na semana passada em GO em homologação e tenho vários clientes emitindo em GO já na 4.00 sem problemas em produção. E outra coisa, com certeza no .ini do componente já foi atualizado a bastante tempo. Repassa mais informações para ver se o pessoal consegue ajudar, como se seus fontes estão atualizados, que configuração está utilizando, qual versão e tudo mais.

@marcelolours, não sei se existe alguma margem, mas a regra é muito clara: No seu caso, deverá gerar as parcelas como algo do tipo: Parc1: 26,66 Parc1: 26,67 Parc1: 26,67.

@mdalmolin, acredito que isso atenda você:

Ok @Daniel Simoes, obrigado pelo retorno. Fico no aguardo...

Olá @Daniel Simoes, acredito que adquirimos a licença após o dia 26/03, acredito que foi 29/03, após e e-mail marketing... mas só agora estamos implantando o ambiente para migração do nosso Delphi. O que realmente é necessário repassar para vocês para tornar um usuário SAC? Qualquer coisa me informa no privado. Obrigado, Fabrício Gomes Araújo

Certamente que sim, por isso falei que não tem que se preocupar. Até porque, se estivesse incorreto, não tinha autorizado a sua NFC-e. O "estagiário" da Sefaz é quem tem que corrigir o site.

Se você está gerando o XML corretamente, não tem que se preocupar. No máximo entrar em contado com a Sefaz que está utilizando e informar que a página deles possui essa falha.

@carlosinfoteen, o que quer saber está um pouco fora do assunto do tópico, mas vamos lá... No meu sistema tenho as tabelas Produto, Estoque e EstoqueLote, garantindo que a soma das quantidades de EstoqueLote conferem com a quantidade na tabela Estoque. Então existem alguma regras, caso o produto controle lote/vencimento (configurável), é necessário ajustar o estoque (caso seja positivo) informando os devidos lotes (lote, fabricação, validade e qtde). As entradas são feitas através do XML, caso não tenha lote no XML é solicitado ao usuário o cadastro do mesmo. Nas saídas, ao informar um produto que possui controle de lotes, então é apresentada ao usuário uma lista com os lotes cadastrados, bastando o usuário informar qual quantidade está dando saída do lote correspondente, caso informe um que a validade não seja a mais baixa, então o usuário é notificado, mas não há impedimento caso queira registrar mesmo assim (configurável com permissões de acesso).

Acredito que seja só uma questão cadastral mesmo, tanto do Fornecedor (software house cadastra o software), quanto do Contribuinte que informará qual software está usando.

Deu uma lida rápida e não vi nada à respeito de informar alguma coisa na NFC-e. O artigo completo está aqui: https://www.sistemas.pa.gov.br/sisleis/legislacao/3929

Leonardo, no meu entendimento você não teria que preencher as tags de rastreabilidade para os NÃO medicamentos, afinal você pode ter no mesmo XML, tanto produtos com rastreabilidade (até o momento: medicamentos) como produtos sem rastreabilidade. Mas se você vai preencher, então não tem muito o que fazer (já que é uma regra técnica da NF-e), você terá que informar uma data de vencimento fictícia, exemplo 31/12/2050.

No seu caso, os hospitais não estariam exigindo apenas o preenchimento de lote, fabricação e validade para os medicamentos? Tem certeza que querem para os demais itens? No meu sistema o cadastro de produtos tem o "tipo" de produto, então se for medicamento ao emitir NF-e são exigidas todas as informações (lote, fabricação e validade), senão simplesmente não são preenchidos esses campos.

O que faço é verificar a validade do certificado antes de tentar emitir qualquer coisa, assim já são verificadas duas coisas a validade e se está ok com certificado, pois se não estiver conectado dará erro ao verificar o vencimento.

Até onde já vi em outros posts, o AM não disponibilizou ambiente de testes para usuários (certificados) de outros estados na versão 4.00, por isso que só funciona a 3.10. Você terá que utilizar a ambiente de homologação do estado do seu certificado.

E então pessoal... acompanhando a lista estou com a sensação que no geral o pessoal está com receio de implantar em produção a versão 4.00... Não tiro a razão. Por enquanto a único relato que posso fazer, em poucos clientes que ativei a versão 4.00, é que está dando muito trabalho por conta da atualização dos Windows dos clientes, pois simplesmente para funcionar com WinCrypt (e xmMsXml) ou até mesmo Capicom, tem que ter as atualizações em dia... pensa a loucura que será quando o prazo (menos de 3 meses para NF-e) estiver encerrando. Não faço uso de OpenSSL, pois possuo muitos clientes com certificado A3, mas quando a coisa afunilar e o prazo estiver encerrando, não está descartada a possibilidade de liberar essa configuração com clientes com certificado A1 para não ter a dependência da atualização do Windows. Estou encontrando diversos cenários, clientes que funcionam de primeira, clientes que precisam atualizar o Windows e funcionam, e inclusive clientes que mesmo com Windows atualizados não funciona de jeito nenhum (esses por enquanto mantive na versão 3.10)... e vamos que vamos...

@fernandesdouglas, para GO na versão 4.00, com WinCrypt da forma que está usando tem que setar essa configuração da SSLType: Foi o que resolveu para o Gilberto.

Todas notas que recebia de distribuidores de medicamentos sempre foi como o exemplo 1, ou seja, sim, a soma das quantidades dos lotes tem que ser a mesma da quantidade vendida do item.

O @Roberto.Godinho explicou muito bem. E ainda levando outra questão que acho bem relevante que seria digamos "roubo" das informações. Se você fornece a chave para uma empresa de terceiros que já está agindo ilegalmente, tendo acesso a toda a informação do xml, eles podem criar uma banco de dados com toda a informação do xml, tanto de produtos, com preços praticados, quanto de clientes (cpf/cnpj) e utilizá-las como bem entender, como, por exemplo, vender para concorrentes informações estratégicas de atuação comercial em alguma região e sei lá mais o quê.

@GILBERTO FARIA não utilizo o AcbrMonitorPlus, utilizo o componente ACBrNFe em DelphiXE6. Tem clientes utilizando em produção em GO tanto WinCrypt como Capicom. A WinCrypt está da seguinte forma:  Para versão 4.00 utilizei ACBrNFe.SSL.SSLType := LT_TLSv1_2; Para versão 3.10 utilizei ACBrNFe.SSL.SSLType := LT_all; A Capicom está da seguinte forma: E ainda para Capicom as configurações das Opções de Internet estão assim:

Vale lembrar que se o seu certificado é A3, você só tema opção de utilizar Capicom ou WinCrypt. Segue exemplo de como configurar com WinCrypt e tem funcionado (só tem que garantir que o Windows esteja atualizado):

Valeu pela dica @Daniel Simoes, mas infelizmente no meu caso a OpenSSL não é uma opção, pois tenho que aceitar os certificados A3. Até sei que você mesmo fala para fugir dos certificados A3 como o diabo da cruz , mas infelizmente o pessoal da empresa quer abraçar o mundo com as pernas e isso não é opção. Os nossos clientes já estão sendo notificados que o WinXP morre junto com a versão 4.00, só aceitaremos Win7 SP1 para frente, então relatei os cenários que estamos encontrando com nossos clientes e a decisão que teremos que tomar no post acima. Mais uma vez obrigado por tentar ajudar.