Fabrício G. Araújo

Pessoal, não sei ao certo se tem relação com essa resolução, mas o meu sistema sempre foi informado os dados do pagamento do cartão como não integrado (tpIntegra = 2) e hoje apareceu um cliente dando a seguinte restrição: "Pagamento com cartao de credito em sistema de automacao nao integrado" Acredito que no MA alteraram as regras de validação em Produção. Especificamente a rejeição ocorreu em uma NF-e em Produção, vou tentar entrar em contato novamente com o cliente para saber se com NFC-e se ainda continua normal. PS - Pelo menos no dia 05/06 o ambiente de homologação de NFC-e no MA estava aceitando normal o tpIntegra = 2.

Realmente o ambiente de Homologação em GO v. 4.00 simplesmente não funciona com OpenSSL (também estou usando MinGW), então tive que efetuar testes (Homologação) com o certificado A1 de um cliente do MA, e então disponibilizei meu sistema em Produção para os clientes de GO e tem funcionado normalmente.

Pessoal, desconsiderem o post, na verdade o erro estava em minha aplicação, onde já chegava com os caracteres bugados quando ia chamar o método ACBrEcf.LinhaRelatorioGerencial.

Olá pessoal, Estou utilizando o componente ACBrECF, e estou com problemas com acentuação com minha Daruma FS600 no Relatório Gerencial. Pesquisei e vi em alguns posts a questão da Página de Código do componente, verifiquei no passo a passo, e está sendo mantido o defaul de 28591. O que mais posso testar para funcionar normalmente? Lembrando que com o uso da DarumaFramework.dll funciona normalmente. Qualquer ajuda será bem vinda, obrigado.

Em Goiás também foi estipulado prazos para encerramento do uso de ECFs, foram por etapas tipo Postos de Combustíveis um prazo, empresas do regime normal outro, até englobarem todas as empresas do estado com o prazo final em DEZ/17, ou seja, nesse ano de 2018 só é permitido NFC-e, portanto aqui, em GO, não permitiram o uso de ECF até o fim da memória não, mas cada estado pode estipular suas leis.

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.