Painel de líderes

Olá amigos. Segue resposta da Sefaz SP, assumindo a "cagada" da antecipação da validação do GTIN: Prezado contribuinte , Identificamos que regras de validação envolvendo GTIN foram indevidamente inseridas na última versão do sistema NF-e publicada em produção. Já estamos atuando para sanar essa complicação. Agradecemos o contato e pedimos desculpas pelo transtorno. ” ________________________________________________________ Mensagem Original: Data de início da obrigatoriedade Bom dia. De acordo com a nota técnica 2017.001 da NF-e 4.0, a validação do GTIN (tags cEAN e cEANTrib) entrariam em vigor no ambiente de produção somente em 01/12/2018. Porém, desde ontem (23/07/2018) as notas estão sendo rejeitadas pelo motivo: "Rejeição 889: Obrigatória a informação do GTIN para o produto". Gostaria de saber se foi algum erro interno na Sefaz SP ou se realmente o prazo foi adiantado, pois não encontrei nenhuma referência a respeito. Aguardo retorno, obrigado.

Alecio Boa tarde eu realmente estava apontando para os Shemas errado apesar de te-los atualizado a pasta de trabalho estava olhando para os arquivos desatualizados

Já enviei trocentos emails pra eles e eles não respondem. Tenho um cliente que se filiou ao GS1 e nem esse cliente está conseguindo suporte lá. Coisas de Brasil. Sugiro que mandem email reclamando sobre isso ao SEFAZ do estado do emitente.

Imprime a nota tecnica 2017.001 e larga na mão do cara... att Ricardo

A obrigatoriedade não deveria ser agora, mas perdoe-os, eles não sabem o que fazem. Meu maior medo é ver o Brasil parar no dia 02/08, porque as grandes distribuidoras aqui da minha cidade ainda não aderiram à NFe 4.00 devido a todos esses problemas. Chegando dia 02/08 não conseguem emitir nota na versão nova, as transportadoras não conseguem emitir ct-e e por aí vai. Nunca vi uma versão de NFe dar tanto problema como essa.

Então... já tentei essa função, colocando ela após assinar e validar, mas não estou obtendo o xml completo. Tentei também utilizando as propriedades XMLOriginal e XMLAssinado, mas está na mesma. A dúvida é se dá pra fazer isso, pegar o xml completo antes de utilizar o método enviar. Obrigado pela força!

O componente tem um método -> ACBrNFe.NotasFiscais.GravarXML('.....') Veja se te ajuda.

O FCP deverá ser calculado quando o destinatário for Consumidor Final não contribuinte do ICMS, e existe uma relação de produtos que estão sujeitos ao FCP. Dercide.

Bom dia, Recentemente recebi um XML com a mesma característica: todas as tags possuíam o "xmlns". Assim o componente ACBr não conseguiu carregar o arquivo. Se alguém tiver uma sugestão para resolver o problema, agradeço. Att., Gabriel

@RicardoVoigt, Gostei .. crie um post na área privada. Atualizando as devidas versões de Danfe's - Fast / Fortes ( Paisagem / Retrato ) .com xml´s de teste. para facilitar a tomada decisão. Ps : Estamos em Refactoring de componentes de impressão.

Perfeito, Xará Simões. Valeu mais uma vez. A gente esquece o óbvio muitas vezes. Abraço. Daniel.

Opa André, Resolvido !!! Era isso mesmo, muito obrigado !!! Opa Ricardo, schemas já estão atualizados !!! Resolvi conforme orientação do André ! Muito obrigado pela atenção !!

Bom dia Também fomos surpreendidos com o mesmo problema ontem em SP e BA. Fizemos como outros colegas, passamos a enviar o literal "SEM GTIN" e atualizamos os Schemas. Os clientes desses Estados foram normalizados. A versão 1.30 da NT 2017.001(Junho/2018) coloca todos os CNAES e NCMs em produção para "Data Futura". Mas soltaram isso ontem e pegaram todos de surpresa no meio da tarde. A descrição da rejeição 889 ainda é clara e cita o anexo (tabela) de vigência: "Se não informado GTIN (cEAN=Nulo). Observação 1: Regra de validação se aplica por grupo de CNAE e NCM conforme vigência definida no ANEXO I.01; Observação 2: Para produtos que não possuem GTIN, utilizar a informação de "SEM GTIN"". No PA essa validação está valendo desde o dia 02/07, nossos clientes pararam lá também nesta data. Mas olha que estranho: o campo CNAE do emitente não é obrigatório no XML. Se mandamos sem CNAE não retorna rejeição 889 com GTIN em branco. Se mandamos com CNAE retorna a rejeição. Em SP ontem mandando sem CNAE rejeitava. RS, MG, RJ, GO, MT, MS, RR, SC todos emitindo NF-e e NFC-e normalmente com o GTIN em branco. Cada UF está interpretando as regras do seu próprio jeito.

Obrigado..

Fonte: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=Y6Lj7G0uHwc=

Olá pessoal, na geração de remessa da Caixa (240 e 400), o Titulo.DataBaixa é usado para determinar a data para Baixar (Efetuar a Devolução) do Boleto lá no banco. Os campos Titulo.DataBaixa e Titulo.DataLimitePagto tem funções similares de fato, e podem confundir um pouco. A dica que dou (e que fiz aqui) é ter apenas um campo no banco de dados (e para o usuário) e setar os dois sempre iguais. Vejam no exemplo abaixo (Inclusive coloquei um ToDo com uma questão filosófica, rs.): if FdmBoleto.qrCedenteDIAS_BAIXA.Asinteger > 0 then begin DataBaixa := Vencimento + FdmBoleto.qrCedenteDIAS_BAIXA.Asinteger; {ToDo: Eu estou usando o mesmo parametro para a DataBaixa e DataLimitePagto, mas, e se algum cliente/empresa desejar usar a DataBaixa (para baixar o boleto no banco) mas não quiser que saia a mensagem no boleto, como deveria proceder? Podemos até querer responder que se é para baixar após a data X, então este também é o limite de pagamento. A afirmação está correta, porém, sabendo como cliente(pagador) se comporta, ao ver a mensagem "Não receber após xx dias" ele pode usar de má fé e deixar passar os dias para tentar uma negociação e não pagar juros. O que podemos fazer em relação à isto? Opção 1: Criar um parametro que determina se a mensagem deve ser exibida? Opção 2: Não usar o DataLimitePagto, apenas o DataBaixa, mas, e a questão de DataLimitePagto em alguns bancos no ACBrBoleto ser usado como DataBaixa (como citado em um post do fórum) ? } DataLimitePagto := DataBaixa; //OBS: No meu caso não uso as mensagens do ACBr, uso personalziadas. sMensagem := sMensagem+'Não Receber após ' + IntToStr(DaysBetween(Vencimento, DataLimitePagto))+ ' dias' end;

Fontes\Terceiros\DelphiZXingQRCode

Ontem alguns clientes tiveram esse problema mas está aceitando 'SEM GTIN' NO CEAN E CEANTRIB pros produtos que não tenham gtin, vlw

Bom dia, André. Obrigado pela resposta. Era isso mesmo, teria que haver uma modificação no componente ACBrNFe, para que não precisássemos fazer POG (Programação Orientada a Gambiarras). Ficou Show de Bola. Para o SEFAZ-SP em Produção (por enquanto), tenho que deixar a propriedade "ACBrNFe1.Configuracoes.Geral.CamposFatObrigatorios := False", se não da Rejeição: "Falha no Schema XML". ?

Obrigado Ricardo. Faltava apontar corretamente o DANFE. Resolvido.

produtos sem gtin tem que ir com a tag SEM GTIN porem tem que atualizar a pasta schemas da nfe4

Aproveitando o tópico, percebi que os layouts do Fastreport tem o CIOT destacado e os do Fortes não tem. Teria como retirar do Fastreport esta informação para não aparecer quando for carga própria ou retirar e quando houver colocamos nas informações complementares?

Configure a propriedade DANFE.ImprimirUnQtVlComercial.

Olá pessoal, Acabei de enviar para o SVN, modificações para que o ACBrDFe e ACBrDFeOpenSSL suportem comunicação segura usando TLS 1.2 O componente ACBrNFe, já irá tentar ajustar a comunicação para TLS 1.2, se detectar que a versão é superior a 3.1 Atualizando o OpenSSL Para usar TLS 1.2, é necessário ter a versão do OpenSSL superior a 1.0.1, normalmente a versão usada é a 0.9.8.14, e portanto ela precisa ser substituída. Se você tentar utilizar uma versão inferior, o ACBrDFeOpenSSL acusará o seguinte erro: Porém não basta apenas baixar e copiar uma nova versão das DLLs do OpenSSL (libeay32.dll e ssleay32.dll). O problema, é que a libxmlsec, que se encontra na pasta: "ACBr\DLLs\XMLSec", não é compatível com OpenSSL superior a 0.9.8... e se você simplesmente atualizar as Libs do OpenSSL no seu sistema, provavelmente o ACBrNFe, passará a acusar Exceptions no momento de assinar o XML A solução, é utilizar um novo conjunto de DLLs, da OpenSSL e libXmlSec, libXML, e demais... você pode achar essas DLLs em: ftp://ftp.zlatkovic.com/libxml/ Essas DLLs foram compiladas com "MinGW", e portanto elas precisarão das DLLs de RunTime, da MinGW. Para sua conveniência, copiamos todas as DLLs necessárias para a pasta: \ACBr\\DLLs\XMLSec\MinGW. Observe que temos a versão 32 e 64 bits dessas DLLs... quais eu devo usar ? Em resumo, use 32 se o seu Compilador é 32 bits, e 64 apenas se você estiver usando um Compilador que gere .EXE em 64 bits... Leia esse tópico, para compreender melhor: Copie TODAS as DLLs (e não somente algumas) da pasta "\ACBr\DLLs\XMLSec\MinGW\32" ou "\ACBr\trunk2\DLLs\XMLSec\MinGW\64" (conforme o seu compilador), para o seu diretório de DLLs... (se não tem certeza para onde você deve copiar as DLLS, leia com atenção o Post indicado anteriormente) Outro problema, é que a MinGW, gera as DLLs com uma nomenclatura ligeiramente diferente do VisualC, exemplo: libxmlsec1.dll com MinGW, e "libxmlsec.dll" com VisualC. Portanto, o ACBr teria dificuldades em encontrar essas DLLs e carrega-las de forma dinâmica. Precisamos portanto, informar ao ACBr, que usaremos o conjunto de DLLs no formato da MinGW... Isso é feito, editando o arquivo: ACBr.inc. Repare que lá no final do ACBr.inc, temos a seguinte linha: {.$DEFINE USE_MINGW} Apenas remova o ".", alterando para: {$DEFINE USE_MINGW} Pronto... com isso você estará pronto para usar o ACBr com OpenSSL e TLS 1.2, seja em 32 ou 64 bits... Obrigado... e considere nos ajudar, contratando o SAC ocasionalmente: http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/

Boa tarde! Referente a solicitação de ajuda acima, consegui resolver o problema colocando a propriedade IdentarXML como FALSE.

O Rodrigo Mourão fez um live sobre esse assunto. Segue o link .. http://poo.rmfactory.com.br/poo-ad-01/aula02?utm_campaign=poo-nutricao_free_nil_ou_freeandnil&utm_medium=email&utm_source=RD+Station

Olha, desde a história do CEST, do DIFAL eles só têm crescido em uma coisa - A INSEGURANÇA que eles conseguem nos transmitir com atualizações. Tá faltando regra e respeito desse pessoal com a gente... e faz tempo!

Para informação segundo os Termo de Uso do Whatsapp isso é ilegal, salvo se o colega tenha autorização deles para faze-lo.

Aqui em MG já está dando rejeição do GTIN. Produtos que não possuem EAN ou o EAN não é válido (cadastrado no GS1) deve constar no cEAN e cEANTrib = 'SEM GTIN' Tem que ficar atentos porque grande parte dos códigos de barra que estão nos produtos brasileiros são códigos inventados ou comprados a fim de facilitar a exportação. Existe até uma reportagem sobre "EAN falsos". O código tem que ser válido, cadastrado no GS1 e além disso, conter todas as características exigidas como Marca, Peso em KG, Descrição, Foto, Unidade Coml....Um dos segmentos que tem sofrido com esses códigos "aparentemente válidos" são os revendedores de peças para veículos. Vira e mexe um código ean é rejeitado e, ao fazer a consulta no GS1, ele realmente não consta na lista.

Não entendo mais nada. Nenhum cliente nosso de SC reclamou até agora.