Painel de líderes

Boa tarde Pessoal! Alguém já se deparo com essa situação? Ao processar um lote no portal da GNRE com a UF favorecida de MS é retornado o seguinte erro. Campo: c39_camposExtras/campoExtra Descricao: O Campo Extra 'Chave de Acesso da NFe' (Código: '27') deve ser informado! Anexo arquivo importado. GNRE23012017114425296.XML

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/

Para evitarmos diversos tópicos sobre o mesmo assunto, as alterações relativas a versão 4.00 da NFe/NFCe deverão ser concentradas neste tópico. Os fontes do componente já foram atualizados para permitir gerar os XMLs para essa nova versão. Também já foram ajustados para não gerar o SOAP Header quando configurado para a versão 4.0(ve400). Assim que os schemas e webservices forem disponibilizados pelo SEFAZ, iniciaremos os testes com o componente. Mais informações sobre as mudanças podem ser obtidas na NT 2016.002 - http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=c4S6yXTKpXY= Apenas como informação, neste manual fiquei com dúvida em dois campos: descANP - Campo numérico com tamanho de 2 - 95? O campo tem a seguinte descrição: Descrição do produto conforme ANP, então provavelmente deve ser do tipo carácter e não numérico. O campo vBCFCPSTRet possui o mesmo ID de outro campo na versão 3.10 - N27a - V3.10 vICMSDeson / V4.00 vBCFCPSTRet

Boa noite, eu monto como abaixo, e na versão atual do ACBrMonitorPLUS não informa a TAG <cRegTrib>1</cRegTrib> , esta TAG o SAT que completa. <?xml version="1.0"?> -<CFe> -<infCFe versaoDadosEnt="0.06"> -<ide> ..... Sds, Ricardo.

O Tipo do ACBr está corretamente definido, de acordo com as especificações do Manual da NFe 6.0... veja a página 66

Anexe um pdf ou imagem exemplificando seu problema! Obrigado

Este link pode te ajudar - http://www.djpdv.com.br/como-usar-o-djpdv-em-ambiente-de-homologacao/

Bom acho que agora você tem um problema com sua instalação ou algo especifico pois pelo que entendi do outro tópico um puxa o outro! reveja o fortes repor que está correto e pegou no github também o acbr e antes olhe senão tem arquivos dos dois perdidos no micro.

Anexe o xml usado!

é isso mesmo mas tem que atender tudo o que pede pois se o fiscal for em seu cliente você acaba levando as sanções

No Elgin você tem que usar a convenção (tipo) stdcall.

Aposto que Sergipe será o 2º a copiar isso, pois esse governo atual adoooora novidades pra enfiar certinho no ra.... do povo.

Após o retorno 6000 o componente não inicia a impressão de forma automática. Veja como eu faço aqui... if ACBrSAT.Resposta.codigoDeRetorno = 6000 then begin try PrepararImpressao; ACBrSAT.ImprimirExtrato; except ShowMessage('Houve um erro na impressão do extrato !'+#13+ 'A 2a. via poderá ser emitida através do F5-MENU'); end; end else ShowMessage(ACBrSAT.Resposta.RetornoStr);

Ricardo era justo porque? Qual o problema de emitir sem identificar o consumidor? Num dá ideia não!!! porque se não os caras vão cobrar n taxas... -".. após as 19 h, adicional de 0,02 por nfce, sábado e domingo adicional de 0,04 por nfce e por ai vai.

Exatamente amigos. Estou no estado da Paraíba e realmente o governo do estado está com essa parada de cobrar por cada documento emitido isso vale para NFe e NFCe. acredito que isso vai virar moda nos outros estados. Só tem mala nesse Brasil!! Cadê a economia que teria tirando o ECF e substituindo pela a NFCe???? Isso foi, e está sendo uma enrolação. Quem banca as custas de tantas alterações ficais? Somo nós soft house. Enxurradas de procedimentos a serem alterados, são varias NT uma atrás da outra e agente tomando fumo. Desculpa mais é isso mesmo. O pior que não temos escolha, temos que fazer o que esses imbecis julga e joga na lei tributária desse Brasil que só é bonito no papel, pois na prática vocês já sabem como é! Valeu

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.

Alguém conseguiu emitir uma NF conforme explicação acima no ambiente de Homologação para estado de SP ? Sem mais, Adilson Pazzini .