Fabrício G. Araújo

No meu sistema, caso aconteça a questão da duplicidade, como aconteceu com você, já envio uma tentativa de consulta e se estiver tudo ok, ou seja, inclusive com digest value ok, o usuário nem fica sabendo o que ocorreu, como se estivesse autorizado de primeira. Assim armazeno tudo direitinho com os protocolos de autorização e tudo e emito o DANFE. Mas a única diferença é que não utilizo o ACBrMonitor, utilizo os componentes mesmo, mas acredito que a lógica seria a mesma para ser tratada na sua aplicação.

Realmente @Gr@c@, não sei de onde tirei que se informasse o tPag = 03 ou 04 teria que ter a tag do card e consequentemente a tag tpIntegra, mas confesso que nunca testei autorizar como tiNaoInformado. Também acredito que tpIntegra = 1 seja para TEF, que atualmente não disponibilizo no meu sistema com NFC-e ou NF-e, só POS. Mas caso continue a ocorrer a restrição e não funcione para mim a opção tpIntegra = tiNaoInformado, não pensaria duas vezes em disponibilizar para o cliente uma telinha para informar os dados e assim passaria tpIntegra = 1 com todos os dados (mesmo não sendo TEF). Vou esperar para ver. Associei o fato dessa resolução ao meu problema, mas por enquanto NFC-e está passando tudo normal. Obrigado pelas informações, inté.

@Fr. Silva e @Gr@c@, o sistema de vocês já trabalha informando o tpIntegra = 1? E informando os demais dados, como CNPJ da credenciadora do cartão, além do tBand e cAut? Ah, só lembrando que a restrição ocorreu em produção com NF-e, segundo o cliente a NFC-e em produção está normal (menos pior).

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.

Obrigado por responder @José M. S. Junior. Ok, as configurações que me sugeriu são para especificamente MinGW, essa entendi bem, vou aplicá-las dessa forma. O que ainda não consegui entender direito com a WinCrypt e LibXml2, é que parece que a LibXml2 usa boa parte de dlls da OpenSSL, meio que tem uma dependência, é isso mesmo? Em outras palavras, a melhor forma de usar essa configuração abaixo: 1 - WinCrypt: SSLCryptLib = cryWinCrypt; SSLHttpLib = httpWinHttp; SSLXmlSignLib = xsLibXml2; Seria: {$DEFINE DFE_SEM_OPENSSL} {$DEFINE DFE_SEM_XMLSEC} {.$DEFINE DFE_SEM_LIBXML2} {$DEFINE DFE_SEM_CAPICOM} {$DEFINE DFE_SEM_MSXML} {$DEFINE DFE_SEM_INDY} {.$DEFINE USE_MINGW} Outra coisa, quando fiz uma distribuição do meu sistema com as diretivas default, ou seja, sem alterar nada, ao subir minha aplicação tinha a dependência da MSVCR120.dll, não entendi muito bem o porquê.

Olá pessoal, Utilizo o componente TACBrNFe, sei que é possível alterar no ACBr.inc as diretivas de compilação para deixar mais "enxuta" a aplicação em relação as dependências de dlls, confesso que fico meio confuso em relação a algumas dependências, até assisti ao vídeo que explica direitinho, mas ainda estou meio inseguro. O meu interesse é distribuir a minha aplicação com duas compilações bem definidas, uma para uso com certificados A3 com WinCrypt e outra com certificados A1 com OpenSSL. Sabendo que possuímos as seguintes diretivas: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_XMLSEC} {.$DEFINE DFE_SEM_LIBXML2} {.$DEFINE DFE_SEM_CAPICOM} {.$DEFINE DFE_SEM_MSXML} {.$DEFINE DFE_SEM_INDY} {.$DEFINE USE_MINGW} Qual seria a melhor configuração das diretivas para essas duas situações de configuração do componente, sendo: 1 - WinCrypt: SSLCryptLib = cryWinCrypt; SSLHttpLib = httpWinHttp; SSLXmlSignLib = xsLibXml2; 2 - OpenSSL (com MinGW): SSLCryptLib = cryOpenSSL; SSLHttpLib = httpOpenSSL; SSLXmlSignLib = xsXmlSec; Agradeço desde já.

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.