Painel de líderes

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/

Bom dia, Estou utilizando a versão 3.0 e percebi que a chave de acesso do Redespacho não esta saindo na parte de Documentos Originarios no DACTE em Fortes, na versão 2.0 a chave de acesso sai normalmente. Olhando o fonte ACBrCteDACTeRLRetrato.pas na linha 834, 839, 1033 e 1038 esta pegando o valor da propriedade 'chave', porem na versão 3.0 o campo onde é gravado esta informação mudou para 'chCTe'. Fiz algumas alterações, por favor se puderem analizar e subir para o svn, fiz os testes e para mim esta funcionando normal. Obrigado! Adailson Rocha ACBrCTeDACTeRLRetrato.pas

O ACBrNFSe tem várias formas de envio, nem todos os provedores tem suporte a todas elas. Nesse caso o provedor não aceita o "Gerar e Enviar um RPS", tente o "Gerar e enviar Lote RPS", ou "Gerar e enviar Lote - Síncrono".

já corrigido.

Faltou o s2305 no esocial_conversao TTipoEvento = (teS1000, teS1005, teS1010, teS1020, teS1030, teS1035, teS1040, teS1050, teS1060, teS1070, teS1080, teS2100, teS1200, teS1202, teS1207, teS1210, teS1220, teS1250, teS1260, teS1270, teS1280, teS1295, teS1298, teS1299, teS1300, teS2190, teS2200, teS2205, teS2206, teS2210, teS2220, teS2230, teS2240, teS2241, teS2250, teS2298, teS2299, teS2300, // Sergio teS2305, // teS2306, teS2399, teS2400, teS3000, teS4000, teS4999); eSocial_Conversao.pas

Boa tarde no svn! Obrigado pela colaboração não necessita comentar no fonte pois o winmerge demonstra as mudanças

Fiz um Merge das correções... elas foram removidas acidentalmente no commit:

Bom dia, O Ajuste estará disponível na próxima versão do ACBrMonitorPlus. Foi adicionado um novo campo específico para configuração do logo para NFC-e e SAT.

Graça, No caso de MG só temos as URLs de homologação para a NF-e 4.00, não temos para a NFC-e versão 4.00 somente para a versão 3.10

A consulta ACBrNFe1.DistribuicaoDFe(StrToInt(cUFAutor), CNPJ, ultNSU, ''); deve ser feita enquanto o ultNSU for menor que o maxNSU para que todos os arquivos sejam baixados. Todos os demais comandos irão baixar documentos específicos ligados ao NSU ou a chave. Se vc recebeu o resumo de uma NFe no NSU X e depois fez a manifestação, a nota completa estará em outro NSU, não adianta tentar baixar o mesmo NSU para obter o XML completo.

Bom dia, considerando que ele ABASTECE o veículo (é consumidor final) o CFOP seria o mesmo 5656. Att Ricardo

Não! Apenas um mas já resolvi , fui em projects-install Packages e marquei a única opção que era false para true aí resolveu! Muito obrigado !!!

Valeu deu tudo correto, fui no fórum mas havia muita referencia foi ai que fiquei na duvida, mas deu tudo certo baixado conforme indicado no trunk2 e instalado com sucesso. valeu abraços...

Boa noite basta acessar a sessão downloads aqui do fórum e baixar o instalar que ele pode te ajudar já ou pesquisar um pouco e chegaria a :

No svn as alterações caso queira sugerir melhorias esteja a vontade.

@GuilhermeCosta, boa tarde! Bacana as alterações feitas nos eventos no eSocial! Apenas uma dúvida a classe, [ TSucessaoVinc ] implementada na unit eSocial_S1200 não poderia ser usada a mesma já existente da unit [ eSocial_Common ]?

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum.

Você deve ter conflitos de alterações não resolvidas no momento de atualizar os fontes pelo svn. Faça um backup da sua pasta do ACBr, baixe novamente os fontes, do zero e reinstale.

Boa tarde Srs, @Juliomar Marchetti Segue em anexo as alterações para validação com o novo leiaute 2.3 para os eventos iniciais/tabelas/periódicos e a criação do novo evento S-1295. Anexei também os schemas da nova versão. Obrigado. Acbr Branches.rar

O Campo cNF dentro do XML não é o mesmo que consta no nome do arquivo.

Vc deve entrar em contato com a SEFAZ do seu estado, pois esta validação é feita pelos servidores deles e provavelmente estão se baseando na lista divulgada no dia 07/07 que não continha alguns NCMs.

Apliquei uma revisão do método GetPathPDF, e enviei modificações para o SVN... Não estava sendo considerado, que esse método pode ser chamado pelo ObjectInspector, em tempo de Design...

@Fernando Di Pace @RicardoVoigt Substituam o arquivo anexo e testem. ACBrNFeWebServices.pas

Resolveu meu problema também. Obrigado!!

A NT apenas remove a validação, ou seja, caso não informe, não haverá rejeição. Mas segundo o Convênio 60/2017, indústria e importador ainda são obrigados a informar o CEST a partir de 01/07/2017.

Boa tarde @Damires, além do que o @willmom disse, dá uma olhada na NT 2015.003 (versão 1.94) http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=DRiCiO978HY= página 7, foi alterado o prazo para 01/04/2018. Sds, Ricardo.

Resolvido. Mandei um questionamento para o SEFAZ de Santa Catarina, e eles resolveram o problema, o problema era la no SEFAZ.

É isto mesmo, André. 1) Sua a aplicação gera o arquivo ENT.TXT na pasta C:\ACBrMonitorPLUS. Ele contém uma linha de comando solicitando que o ACBr gere o xml correspondente aos dados contidos contidos em ENT.TXT. 2) O monitor lê o arquivo, obedece ao comando de criar a Nfe e gera o arquivo SAI.TXT contendo o retorno da Sefaz que diz se deu certo ou não. 3) Sua a aplicação gera outro arquivo texto contendo o comando de validar o xml que o monitor criou. 4) O monitor lê o arquivo, obedece ao comando de validar o xml e gera outro arquivo SAI.TXT contendo o retorno da Sefaz. 5) Sua aplicação lê o arquivo SAI.TXT e, dependento de um conteúdo que indique sucesso, cria outro arquivo ENT.TXT contendo o comando de envio da NFe à Sefaz. 6) O monitor responde gerando mais um arquivo SAI.TXT informando se a nota foi autorizada ou não e por quê. 7) Sua aplicação lê o arquivo SAI.TXT e informa o resultado ao usuário. Sua primeira dificuldade será o que informar no arquivo ENT.TXT. Há um modelo no arquivo ACBrMonitorPLUS.chm. "Comandos\Comandos do objeto NFe/NFCe\NFE.CriarNFe". Você poderá, também, fazer o monitor gerar um arquivo INI a partir de um XML de NFe que você pode facilmente conseguir com o contador do seu cliente. Este comando, que é uma mão na roda pra quem não tem ideia de como deve ser o INI, se chama NFE.LerNFe. Ele também é explicado no arquivo de help do componente (ACBrMonitorPLUS.chm).

Veja no teu código, você faz um add para cada propriedade, isso é errado. Por isso lhe perguntei se estudou o demo, veja no demo que o Add, adiciona um novo item a lista, depois você preenche as propriedades deste item. Por exemplo: with ACBrBlocoX.ReducoesZ.TotalizadoresParciais.Add do begin ... ... with Servicos.Add do begin Codigo.Tipo := tpcProprio; Codigo.Numero := CodProduto; Descricao := DescProduto; Quantidade := QtdeProduto; Unidade := RetornaUnidadeMedida(CodUnidade); ValorUnitario := PrecoProduto; end; ... end;