Fabrício G. Araújo

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.

Só um esclarecimento... a Capicom está funcionando normal em GO na versão 4.00 (tanto homologação quanto produção), foi só manezada minha mesmo que esqueci que a Capicom tem as dependências das configurações das Opções da Internet. Agora terei que decidir se utilizarei a Capicom ou a WinCrypt na versão 4.00. WinCrypt: Como já falei em outras postagens, com a WinCrypt pode funcionar de primeira em alguns clientes, mas em outros que estão com Windows desatualizados tem que atualizar até o fim para funcionar, não basta ter, por exemplo, um Win7 com SP1, tem que ter todas as atualizações após o SP1 para funcionar. Em um cliente demorou dois dias para conseguir preparar um computador e ver funcionando com WinCrypt. A grande vantagem é que após a atualização tudo funciona, sem ter que configurar nada. Capicom: Já com a Capicom percebi que, por exemplo, um Win7 com SP1 já funciona, sem as últimas atualizações. Mas aí tem todo o transtorno de instalar Capicom, registrar dlls e alterar as configurações das Opções da Internet. Enfim, agora teremos que tomar a decisão aqui na empresa que caminho seguir para a versão 4.00, pois ambos tem os prós e contras.

Hummm... que estranho, para mim só ocorre o erro 495 (ou 403) em GO se tentar utilizar Capicom. No geral funciona com WinCrypt, mas existem muitos clientes com Windows desatualizados e bugamos, que estou quase desistindo de utilizar a WinCrypt e voltar a utilizar a Capicom, mas infelizmente só em GO não funciona a Capicom na 4.00, em outros estados funciona normal. Nem sequer o ambiente de homologação funciona em GO com Capicom na versão 4.00 (na 3.10 normal). Estou em uma sinuca de bico, pois estou acreditando ser inviável atualizar todos os computadores de todos os clientes para manter o uso da WinCrypt, mas a Capicom não funciona em GO sei lá por quê.

@GILBERTO FARIA, erro erro que acontece com você em GO é porque está utilizando Capicom, certo?

Conseguiu resolver o erro "12175 - um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor"? Estou começando a liberar o meu sistema em produção em GO na versão 4.00 e até estava indo muito bem, funcionando de primeira em alguns clientes, até que surgiu um bendito com com esse erro (vale lembrar que é o mesmo executável, com as mesmas configurações), ainda vamos investigar, mas a princípio deixamos fazendo as atualizações do Windows para ver no que dá. Estamos utilizando as mesmas configurações que você (WinCrypt (do print) e SSLType LT_TLSv1_2).

Pessoal, gostaria de sugerir aos moderadores, se possível, fixar um tópico para ter o feedback da comunidade, com a informação de quem já está emitindo em PRODUÇÃO a versão 4.00 tanto para NF-e quanto NFC-e. Acredito que assim possa encorajar mais pessoas a ativar a nova versão ao saber que outros já estão utilizando com sucesso. A princípio já consegui ativar em dois estados com sucesso e ainda não tive problemas, que foi em GO e MA, então vou criar uma listinha, se os moderadores acharem interessante, poderão editá-la com o feedback do pessoal. Seque uma sugestão simplificada da lista: Quais estados estão aceitando em PRODUÇÃO a versão 4.00? AC= AL= AM= AP= BA= CE= DF= ES= GO=NF-e/NFC-e MA=NF-e/NFC-e MG= MS= MT= PA= PB= PE= PI= PR= RJ= RN= RO= RR= RS= SC= SE= SP= TO= Fabrício Gomes Araújo

@carlosinfoteen Veja a documentação, a tag ICMSSN102 aceita: Tributação ICMS pelo Simples Nacional, CSOSN=102, 103, 300 ou 400. Provavelmente está informando 103. Aqui tem um resumo em pdf com diagramas das tributações aceitas:

A única coisa que posso dizer é que é a opção 1, o resto é maluquice de contador ou sei lá o quê. Digo isso por seguir a mesma regra que era aplicada para medicamentos, onde os lotes ficavam na tag med e agora foram para o rastro, e todos os grandes distribuidores faziam na tag med exatamente como a opção 1 que agora será a tag rastro. Que com certeza é a mais lógica. A estrutura foi criada justamente para aceitar mais de 1 lote por produto.

Estou utilizando WinCrypt com essas configurações: Para versão 4.00 utilizei ACBrNFe.SSL.SSLType := LT_TLSv1_2; Para versão 3.10 utilizei ACBrNFe.SSL.SSLType := LT_all; Lembrando que os testes que fiz foram em homologação.

Olha pessoal, a única coisa que posso dizer é que estou testando agora à tarde em GO em Homologação e está funcionando tudo normal, tanto NF-e (3.10 e 4.00) quanto NFC-e (3.10 e 4.00).

@Claudiomir, não sei que prazo é esse de 01/04/2018 que te passaram... mas só para te deixar ainda mais confuso em relação à NFC-e, olha esse post:

No meu entendimento, NFC-e 4.0 já está em produção a muito tempo (NT_2016_002_V1.41, produção 04/12/2017), apesar das SEFAZ não estarem cumprindo o prazo estipulado pelo próprio governo. Mas houveram pequenas modificações como a NT_2016_002_v1.42, onde essas modificações entraram em vigor em produção em 22/01/2018, agora estão modificando novamente a versão da NFC-e 4.0 (que já está em produção), com essa questão do QR-CODE 2.0, com novos prazos para essas modificações que é para entrar em produção em 02/07/2018, e ainda adiando o término da versão da NFC-e 3.10 para 01/10/2018. O complicado que vejo nessa confusão toda é que a SEFAZ de MT já está se abraçando com a nova nota técnica para ter a desculpa que não tem ambiente de produção funcionando atualmente, que é um absurdo. Conforme esse entendi nesse post:

@carlosinfoteen, sobre o que gerar para os contadores, pode até variar pelo sistema que eles utilizam, por exemplo, no meu caso, para notas canceladas, estava gerando apenas o arquivo xml do evento de cancelamento, mas o contador não conseguia importar no sistema deles, então a equipe técnica informou que teria que gerar também o xml da nota original autorizada e também o xml do evento de cancelamento de cada nota cancelada, então funcionou para eles.

@alexandrebarbosa, veja o que diz a nota técnica NT_2016_002_v1.42, na última página (60). 6 Campos do DANFE Nesta nova versão não haverá alteração no leiaute do DANFE. As informações relativas ao Fundo de Combate à Pobreza (FCP) devem ser informadas: No campo de "Informações Adicionais do Produto, tag: indAdProd", os valores informados por item nos campos (vBCFCP, pFCP, vFCP, vBCFCPST, pFCPST, vFCPST), quando existirem. Os valores de totais do FCP (id: W04b e W06a) devem ser informados em "Informações Adicionais de Interesse do Fisco, campo “infAdFisco", quando existirem."

Chegou a testar? Valida isso primeiro... as vezes as mensagens de rejeição da SEFAZ são meio sem noção.

Pelo que vi, o seu valor da forma de pagamento da duplicata não confere, não deveria ser 133,57?