Painel de líderes

Sempre acreditei que a informação deve ser algo democrático e acessível... Pensando nisso, tornei pública a nossa área de Base de Conhecimentos Nela você encontrará excelentes artigos, escritos pelos nossos experientes Consultores, e que tornarão o uso dos os componentes ACBr algo mais simples e funcional... Espero que gostem... e fiquem a vontade para sugerir novos artigos...

???, Isso nem é novidade, partindo do ACBR. []s,

Galera Ainda uso CAPICOM e tive necessidade de saber se o CERTIFICADO estava carregado antes de começar a operação. Encontrei no forum solução para WINCRYPT Abaixo a solução que achei pesquisando o fonte de ACBrCAPICOM_TLB NFSE.SSL.CarregarCertificado; if (NFSE.SSL.SSLCryptClass is TDFeCapicom) and (TDFeCapicom(NFSE.SSL.SSLCryptClass).Certificado.Get_PrivateKey.IsAccessible) then begin mmo_status.Text := mmo_status.Text + 'INFORMAÇÕES CERTIFICADO' +cr+ 'CertSubjectName : ' + NFSE.SSL.CertSubjectName+cr+ 'Razão Social : ' + NFSE.SSL.CertRazaoSocial+cr+ 'CNPJ : ' + NFSE.SSL.CertCNPJ+cr+ 'Numero Serie : ' + NFSE.SSL.CertNumeroSerie+cr+ 'Data Vcto : ' + FormatDateTime('DD/MM/YYYY', NFSE.SSL.CertDataVenc)+cr+ 'Certificado Tipo: ' + tipo_cert+cr; if TDFeCapicom(NFSE.SSL.SSLCryptClass).Certificado.Get_PrivateKey.IsHardwareDevice then mmo_status.Text := mmo_status.Text + 'IsHardwareDevice: TRUE' +cr; mmo_status.Text := mmo_status.Text + '++++++++++++++++++++++++++++++++++++'+cr+ '+++ CERTICADO LIDO COM SUCESSO +++'+CR+ '++++++++++++++++++++++++++++++++++++'; end else mmo_status.Text := mmo_status.Text + '+++++++++++++++++++++++++++++++++++++++++'+cr+ '+++ ERRO CERTIFICADO INACESSÍVEL ERRO +++'+CR+ '+++++++++++++++++++++++++++++++++++++++++'; mmo_status.Lines.SaveToFile( sPathExe+'log.txt');

O seu erro indica uma falha na autenticação de Proxy da sua rede a URL é exibida na msg do Erro

Bom dia, pradilsoncarlos. Copie as DLLs do OpenSSL, superior a 1.0 para a pasta do seu .EXE. Basta encontrá-las em: \ACBr\DLLs\OpenSSL\1.0.2.13, utilize a versão de acordo com o seu compilador (32 ou 64).

Boa tarde. No caso isto seria na hipótese do produto ter redução na base de cálculo caso estivesse no regime comum, assim como nos outros campos, mas é contraditório porque se você revende o produto com ST a principio ele nem tem base de cálculo, quanto menos redução.

Boa tarde Lucca. O propósito do ACBrMonitorPLUS é pegar uma informação, levar ao servidor SEFAZ e trazer o retorno por comunicação TXT ou TCP e desta forma poder ser usado por várias linguagens de programação integrando aos seus sistemas. Porém o restante se espera que estes que estão desenvolvendo o sistema para integração com o monitor, façam os ajustes necessários ao sistema para poder interpretar os retornos de forma correta. Se você programa, basta você passar a linha toda para maiúscula quando coletar o retorno (leitura) da linha. Se for uma empresa e não necessariamente você, então solicite ao desenvolvedor que a leitura possa ser feito de qualquer forma que eles saberão o que fazer.

Boa tarde! Sim, pertence ao ACBrMonitorPLUS Link: https://acbr.sourceforge.io/ACBrMonitor/NFEDistribuicaoDFe.html https://acbr.sourceforge.io/ACBrMonitor/DistribuicaoDFePorChaveNFe.html https://acbr.sourceforge.io/ACBrMonitor/DistribuicaoDFePorNSU.html https://acbr.sourceforge.io/ACBrMonitor/DistribuicaoDFePorUltNSU.html Modelo de resposta: https://acbr.sourceforge.io/ACBrMonitor/ModeloRespostaDistribuicaoDFePor.html

Também implementei o loop... O duro é atualizar mais de 2000 clientes... Obrigado @Fausto pela dica matadora!

Estava com o mesmo problema: O Documento XML deve ter um elemento de nivel superior. Line:0 Fiz o loop de 5 tentativas e solucionou, geralmente na 2a tentativa recebo o retorno.

Olá, Como você está preenchendo o campo Servico.Valores.IssRetido?

Realmente é instabilidade! Hora ele passa normalmente, hora não vai de jeito nenhum! Não fiz nenhuma alteração, como o izair citou! Creio que o melhor a fazer seria um loop mesmo, como sugerido pelo Fausto! Eu fiz como abaixo! repeat inc(k); Confirma := GetServicoSolicitacaoWS().confirmarAutorizacao(Confirmacao, Usuario); if (Confirma.inAutorizacaoSolicitacao = '00A') or (Confirma.inAutorizacaoSolicitacao = '01A') then begin if not clietDS.Active then clietDS.Active; with clietDS do begin Edit; FieldByName('FP_CUPOMVINCULADO').AsString := Confirmacao.nuCupomFiscal; Post; end; ATUALIZA_clietDS(clietDS,0); FP_CUPOMFISCAL.Text := Confirmacao.nuCupomFiscal; end; until (Confirma.inAutorizacaoSolicitacao = '00A') or (Confirma.inAutorizacaoSolicitacao = '01A') or (K = 7);

Agradeço pelo excelente trabalho... Agora está funcionando perfeitamente... Muito obrigado... grande abraço...

Algumas configurações das opções da internet podem ajudar, tente desmarcar todas as opções deixando apenas TLS1.1 e SSL 3.0

Ontem, quando escrevi essa resposta estava de cabeça cheia, por isso não ficou explicito. É bem simples, é só fazer um loop e dentro um try except tanto na solicitação, quanto na autorização da transação, pois dessa forma capturamos o erro e tentamos novamente ,ou não, o reenvio das informações. No meu caso algumas vendas vão na primeira, sem levantar exceção. Olhando melhor agora dá para melhorar o código ao invés da estrutura while =true, o reapeat until ficaria mais "didático".

Adilson, Em vez de anexar a imagem da tela inteira, poderia apenas anexar a imagem do form que contem a mensagem de erro? Além de economizar um baita espaço fica mais nítido para poder ler.

Bom dia Veja o tópico abaixo, no demo ACBrNFe tem um exemplo utilizando o método DistribuicaoDFe também...

Obrigado a todos, o problema foi resolvido.

Veja esta postagem: Postado por giulianon em 29/12/2017 https://www.projetoacbr.com.br/forum/topic/39273-clisitef-autoatendimento/ Para iniciar direto no débito ACBrTEFD.TEFCliSiTef.OperacaoCRT := 2; Para iniciar direto no crédito ACBrTEFD.TEFCliSiTef.OperacaoCRT := 3; Na documentação do clisitef tem todos os códigos de todas as operações que você pode utilizar. Qualquer dúvida estamos a disposição.

O ideal é programar o Logo na memória da impressora... Porque transmiti-lo em BMP a cada DANFCe, se ele pode já ficar na memória da impressora ? Usando o SATTeste.exe ou o Elgin Utility você conseguirá programar um Logo na memória da impressora, e depois imprimi-lo, usando referência as índices dele na memória da impressora

while true do begin try inc(k); LblTent.Caption := IntToStr(k); PanelServer.Visible := True; LblFase.Caption := '1ª FASE - Solicitação de Pré-Autorização'; Application.ProcessMessages; AutorizaFP := WSDataSus.executarSolicitacao(SolicitaFP, UsuarioFP); PanelServer.Visible := False; Break; except on E: Exception do begin PanelServer.Visible := False; if not Confirma('Tentativa número [' + inttostr(k) + '] Não foi possível uma conexão com o servidor.' + #13 + #13 + 'Mensagem retornada do servidor:' + #13 + #13 + E.Message + #13 + #13 + 'Tentar novamente?') then begin Result := False; Exit; end; end; end; end; Amigo, eu tenho o código acima, onde tenho um TPanel->PanelServidor e passo pela exception onde o usuário tenta reenviar a solicitação, depois do novo dns esta dando esse erro ai que você mencionou acima, mas quando clico em reenviar(Nova tentativa) passa.

Boa tarde Pessoal, Primeiro foi o CT-e e o MDF-e a ter o seu layout alterado para contemplar um novo grupo: <infRespTec> Informações do Responsável Técnico, agora esta chegando a vez da NF-e. Os 3 componentes já estão preparados para gerar esse grupo. Alguns desenvolvedores já estão gerando o grupo <infRespTec> para o CT-e e MDF-e, tanto em homologação quanto em produção. No caso da NF-e as datas previstas são: para o ambiente de homologação é 25/02/2019 e para produção é 29/04/2019 alterado para 03/06/2019 (conforme consta na versão 1.30 da NT 2018/005). Quero deixar claro que essas datas se referem ao prazo para que as SEFAZ finalizem a implementação em seus webservices, portanto somente a partir dessas datas é que poderemos enviar o XML da NF-e com esse grupo. Portanto, a partir do dia 25/02/2019 teremos um prazo de 3 meses para realizar os testes em ambiente de homologação. Outra coisa importante a ser dita é que esse grupo é opcional, mas vai ficar a critério de cada UF torna-lo obrigatório ou não. Quais são as informações que compõe esse grupo? O grupo <infRespTec> é composto pelos campos: CNPJ da empresa que desenvolveu o software, xContato é o nome da pessoa responsável pelo software, email e fone dessa pessoa ou da empresa. Caso você opte por gerar esse grupo independente da UF exigir ou não, as 4 informações acima deveram constar. Como dito acima os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec>, para que isso ocorra basta acrescentar na sua rotina que alimenta o componente com os dados que vão fazer parte do XML as seguintes linhas... O exemplo abaixo é para a NF-e: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) infRespTec.CNPJ := xCNPJ_RespTec; // CNPJ da Empresa infRespTec.xContato := xContato_RespTec; // Nome do Contato infRespTec.email := xEmail_RespTec; // email do Contato ou Empresa infRespTec.fone := xFone_RespTec; // fone do Contato ou Empresa end; As linhas em negrito acima são exatamente iguais para o CT-e e MDF-e. Nas Notas Técnicas da NF-e, CT-e e MDF-e que se refere a esse grupo tempos ainda mais dois campos: idCSRT e hashCSRT que vão ficar para uma segunda etapa. O CSRT - Código de Segurança do Responsável Técnico, trata-se de um código alfa numérico que será fornecido pela SEFAZ através de uma página própria ou por um webservice, conforme consta na Nota Técnica. Sendo assim, enquanto a SEFAZ não criar essa página ou webservice não temos como solicitar o CSRT e portanto não podemos incluir no XML o idCSRT que é um numero sequencial e o hashCSRT que é o resultado do hash (SHA1 - Base64) da concatenação do CSRT mais a chave do documento. Os componentes já possuem no rol de configurações, as propriedades idCSRT (Integer) e CSRT (String), nessa primeira etapa devemos atribuir o valor zero a idCSRT e uma string vazia para o CSRT, para que os campos: idCSRT e hashCSRT não sejam gerados. Os valores padrões estabelecidos pelo componente são: idCSRT = 0 e CSRT = '' (string vazia). Reforço que o preenchimento dessas propriedades só devem ser feitas a partir do momento que a SEFAZ lhe fornecer o idCSRT e o CSRT. Vamos supor que as UF: x, y e z venham a exigir o grupo <infRespTec> e criem uma pagina ou webservice para fornecer o CSRT, caso você tenha clientes usando ou seu software para emitir NF-e ou CT-e ou MDF-e será necessário solicitar o CSRT em cada uma das UF. Resumindo o CSRT fornecido pela UF x só é valida para os seus clientes dessa UF que usam o seu software. Quais são as UF que vão exigir o grupo <infRespTec> não sabemos, logo devemos ficar atentos. A minha sugestão é que o seu software gere esse grupo independente da UF exigir ou não, pois o dia que ela resolver exigir você não vai precisar fazer nada, pois já consta no XML o grupo. A questão agora é quanto ao CSRT, como dito anteriormente, vai ficar para uma segunda etapa visto que, se faz necessário a SEFAZ criar a página ou webservice. O meu conselho é que no seu software na tela de configuração tenha os campos: idCSRT e CSRT para que você possa informa-los assim que obter. Detalhe importante, os campos idCSRT e hashCSRT só serão gerados no XML e de forma automática dentro do grupo <infRespTec> a partir do momento que as propriedades de configuração: idCSRT e CSRT passarem a ter valores validos. O texto ficou longo, mas espero ter passado todas as informações necessárias para que vocês possam fazer as alterações em seus softwares e desta forma ficarem em conformidade com as nas Notas Técnicas. Para quem não leu as NT, por favor leiam. NT 2018/005 versão 1.20 - Alteração do layout da NF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/NFe/NT/2018/ NT 2018/002 versão 1.01 - Alteração do layout do CT-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/CTe/NT/2018/ NT 2018/002 versão 1.02 - Alteração do layout do MDF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/MDFe/NT/2018/

Bom dia Tulio, Tentou mudar para libCapicom ou libWinCrypt?

Bom dia Filipe, Muito obrigado pela colaboração, já corrigi o arquivo Cidades.ini e ainda hoje vou enviar para o repositório.

" Sugerimos que procure as demais UFs autorizadas para saber a posição destas. " Dá pra ver claramente, que até eles estão meio perdidos quanto a isso. rs Pessoal, não sei vocês, mas, não vejo isso com bons olhos. Assim como o PAF-ECF era burocrático e "fechado", estou especulando aqui que, em algum momento veremos uma movimentação semelhante para o rumo das DF-e's. Além disso, a Receita e Sefaz dos estados, depois de tentar fechar o cerco pra cima dos clientes, agora estão começando voltar seus olhos pra nós, pobres mortais. Não acredito que a finalidade será "inicialmente identificar consumo indevido". Tem coisa "preta" vindo por aí.

Boa tarde Italo, Então .. ainda desconheço o padrão para emissão.. mas parece que temos novidades Esta sendo realizado um Evento hoje em BH explicando e fazendo realização de testes Segue o link http://www.pbh.gov.br/bhissdigital/portal/index.php?content=avisos/index.php&data=20190204anexo

Boa tarde Tulio, Qual é o valor de SSLLib?

Olá Pessoal, Vejo muitos XML de CT-e que contem as informações sobre o Expedidor e o Recebedor. Quando devemos informa-los e em quais situações? Em um transporte de carga normal, ou seja, a transportadora pega a carga do Remetente e leva até o Destinatário não devemos informar o Expedidor e o Recebedor. O Expedidor e ou Recebedor só aparecem quando existe uma outra transportadora envolvida no transporte da carga e é essa transportadora que é informada como Expedidor ou como Recebedor. Vamos a um exemplo onde temos o transporte Normal, Redespacho e Redespacho Intermediário. Exemplo: Transportadoras envolvidas: A, B e C Remetente -> A -> B -> C -> Destinatário A transportadora A emite um CT-e Normal informando: Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Recebedor: Transportadora B (o Recebedor foi informado pois a transportadora A não vai levar a carga até o Destinatário. o Expedidor não foi informado pois quem expediu a carga foi o Remetente que já esta informado) A transportadora B emite um CT-e de Redespacho Intermediário Remetente: o remetente da mercadoria (quem vendeu) - Opcional Destinatário: o destinatário da mercadoria (quem comprou) - Opcional Expedidor: Transportadora A (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora A) Recebedor: Transportadora C (o Recebedor foi informado pois a transportadora B não vai levar a carga até o Destinatário) A transportadora C emite um CT-e de Redespacho Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Expedidor: Transportadora B (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora B. o Recebedor não foi informado pois quem vai receber a carga é o Destinatário que já esta informado) Note que a transportadora A pegou a carga do Remetente e levou até a transportadora B, esta por sua vez levou até a transportadora C, e esta por sua vez levou a carga até o destinatário.

Vou relacionar algumas que considero muito importantes. 1. Procure ter no banco de dados todas as informações do documento, pois se o seu cliente vir a perder o XML, será possível gerar e assinar ele novamente com as mesmas informações e por fim executar o método Consultar para obter o protocolo de autorização e com isso deixar o XML completo, ou seja, assinado e protocolado, tornando-o desta forma um documento com validade jurídica. 2. Jamais informe o numero do documento como sendo o código do documento, a titulo de exemplo a NF-e: muitos atribuem o valor de nNF (numero da nota fiscal) a cNF (código da nota fiscal). Essas duas informações fazem parte da chave, logo não faz nenhum sentido serem iguais. Por recomendação da SEFAZ o valor de cNF tem que ser um numero aleatório. Logo devemos gerar esse numero e armazena-lo no banco de dados junto com os demais dados da nota. Outro detalhe importante o tamanho de nNF é de 9 dígitos, já o tamanho de cNF é 8, portanto quando o numero do documento atingir a casa dos 9 dígitos, como você vai passar esse numero para o código que só aceita 8 dígitos? Todo o que foi dito acima referente a NF-e, devemos também levar em consideração aos demais Documentos Fiscais Eletrônicos. No CT-e temos nCT (numero do Conhecimento) e cCT (código do Conhecimento), sendo que este último deve ser um numero aleatório e diferente do nCT. No MDF-e temos nMDF (numero do Manifesto) e cMDF (código do Manifesto), mesma recomendação do CT-e. No BP-e temos nBP (numero do Bilhete) e cBP (código do Bilhete), mesma recomendação do CT-e. 3. Prefira armazenar os XMLs no banco de dados em vez no Disco, isso evita que algum usuário apague sem quer os XMLs. 4. Para quem utiliza o certificado A1, prefira armazenar o seu conteúdo no banco de dados, pois desta forma não se faz necessário instalar o mesmo na maquina.

Atualize sua pasta schemas e teste novamente. Veja tbm:

realmente era isso eu mudei a Uses para Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.Imaging.jpeg e funcionou perfeitamente, agora alguem sabe que cag... eu fiz, e como eu poderia resolver isso, pois ja olhei todos os paths e estão todos certos.