Painel de líderes

Na impressão do boleto carnê a informação com o endereço do cedente o objeto esta AutoSize=True e como o espaço é mais reduzido esta sobrepondo o texto mais a direita "Agência / Código Beneficiario". Somente setei a propriedade do objeto txtEndCedenteCarne para False. Segue o arquivo com alteração. P.S.: @Juliomar Marchetti Em lazarus não tem este objeto para o endereço do cedente, por isso não estou enviando o lfm, quando a implementar o objeto lá na verdade ainda estou entendendo como funciona o compartilhamento do mesmo.pas, por isso não fiz isso também. ACBrBoletoFCFortesFr.dfm

Boa tarde colegas! Estive fazendo o treinamento na Software Express, e de todo o conteúdo, 3 pontos eu achei bem relevantes destacar e informar aqui, pois pelo menos pra mim são novidades. 1 - A confirmação da transação pode ser feita já no momento que a aplicação receber as duas vias do comprovante. Antes era só após a impressão de todas as vias do CCD. Dessa forma caso ocorra qualquer problema basta reimprimir os comprovantes. OBS: Requer uma nova homologação para trabalhar dessa maneira. 2 - Caso ocorra algum problema de falta de energia, desligamento do equipamento, etc, passa a ser opcional o tratamento dado pela aplicação, ou seja, você escolhe se cancela ou se confirma o que tiver pendente. OBS: Requer uma nova homologação para trabalhar dessa maneira. 3 - Cobrança maior por parte das adquirentes por ambientes certificação PCI.

Olá Tudo Bem. Desculpa senão é aqui o local correto pra dúvida do Fortes Report CE com acbrTrunk2. Eu uso o delphi 2007 , acbrtrunk 2 e o fortesreport CE, e está acontecendo uma coisa muito estranha. Em determinadas impressoras um relatório feito no fortes imprimi normal sem problemas do tamanho certo as fontes enfim imprimi corretamente mas em outra impressora mesmo eu vendo as configurações da impressora como estar tipo papel A4, 1 pagina por folha tudo certo ele imprimi pequeno como se tivesse a opção 2 ou 3 paginas por folha. No caso testo em uma impressora lexmark e sai normal já em uma Hp laser ele imprimi pequeno com se tivesse configurado 3 paginas por folha mesmo não estando com essa configuração nas propriedades da impressora. Quando eu executo a versão do programa (versão gerada ainda no trunk1) esse problema não ocorre. Agora o executável gerado já na versão acbrtrunk 2 acontece esse problema. Já tentei mudar outras configurações da impressora, mas o problema persisti. Aguem já passou por isso? Desde já Muito Obrigado pela Atenção!!

José, No help estão os comandos a sequência você pode criar a sua lógica... NFe.CriarNFE NFe.ValidadeNFe NFe.AssinarNFe NFe.EnviarNFe NFe.ImprimirDANFE a rotina NFe.CiarEnviarNFe faz tudo de uma vez....

Parece fazer sentido, essa modificação... tentei aplicar a mesma, mas continuo sem conseguir a execução na assinatura... Poderia por favor anexar um Zip com as suas Units da ACBrDFeOpenSSL ?

Bom dia a todos, Por se tratar do documentos diferentes a numeração sequencial não pode ser a mesma. Para cada Documento devemos ter uma numeração sequencial. Outra coisa, suponha que essa empresa possua 3 PDV para venda ao consumidor ( emissão de NFC-e ) e uma maquina separada para venda a pessoa jurídica ( emissão de NF-e ). No minimo teremos duas sequencias numéricas de notas, uma para a NF-e e outra para NFC-e. Mas podemos ter uma sequencia numérica para cada PDV, neste caso teremos 3 séries, exemplo: Maquina que emite NF-e: Modelo 55 - Série: 1 - Sequencia: 1, 2, 3, 4.... PDV-1 que emite NFC-e: Modelo 65 - Série: 1 - Sequencia: 1, 2, 3, 4.... PDV-2 que emite NFC-e: Modelo 65 - Série: 2 - Sequencia: 1, 2, 3, 4.... PDV-3 que emite NFC-e: Modelo 65 - Série: 3 - Sequencia: 1, 2, 3, 4....

Para ver as mensagens de erro da libxmlsec, rode o programa diretamente pela linha de comando... Baixei os fontes da XMLSEC e fiz algumas modificações, para debugar melhor o problema... Notei que a Chave está chegando "nula", para a LibXMLSec.. (dsigCtx^.signKey = NULL)... porém nos fontes do ACBrDFeOpenSSL ela está corretamente atribuída... Deve ser alguma diferença de "tipos", entre 32 e 64 bits, que faz com que a chave fique Nula, quando é informada para a chamada do método da DLL

Waldir, Muito obrigado pela analise, correção e adição dos Testes Unitários... parabéns... Enviei para o SVN, com pequenas modificações...

Não encontrei no arquivo enviado o campo CRT.

Wayssoft, a coisa esta meio confusa. Olha se teu cliente é simples nacional , voce vai mandar o CSOSN se ele for Lucro Real ou Presumido você vai mandar o CST. O CSOSN 102 é para produto tributado ( que teria o cst 00 para não simples nacional). O CST 50 é para produto com SUSPENSÃO. Então precisa de ver o que o contador quer realmente. Outra coisa, não vi a parte do PIS e do CONFINS no fragmento que voce postou

Wayssoft. Analise com calma o manual da NFE e ve lá do qeu diz respeito estes valores CST 50 e 41 e CSOSN 102. E se você analisar com calma vai perceber que CST e CSOSN se trata do regime da empresa trabalhar "perante o governo". E CST=regime normal CSOSN para regime do simples nacional, ou melhor se a tag CRT = 1 – Simples Nacional – A empresa continua faturando dentro do limite de receita estabelecida pelo governo, por isso ela tem os benefícios e utiliza a CSOSN para indicar o tipo de ICMS que ela está tributando e os direitos a créditos relacionados à operação. 2 – Simples Nacional – excesso de sublimite de receita bruta – A empresa faturou muito, então agora ela irá utilizar o CST para tributar o ICMS, como qualquer outra empresa. Quando CRT = 2 não pode usar CSOSN. 3 – Regime Normal. Usa CST de ICMS normal. Resumindo... Tu vai usar um ou outro, na nota... e acima no teu código está os dois.

As modificações de TLibHandle realmente são necessárias... pois em Linux elas apontam para outra Unit. TLibHandle = PtrInt; Mesmo assim ele falha ao executar a assinatura, vazando o seguinte erro : SignResult := xmlSecDSigCtxSign(FdsigCtx, SignNode); func=xmlSecDSigCtxProcessKeyInfoNode:file=xmldsig.c:line=871:obj=unknown:subj=unknown:error=45:key is not found: func=xmlSecDSigCtxProcessSignatureNode:file=xmldsig.c:line=565:obj=unknown:subj=xmlSecDSigCtxProcessKeyInfoNode:error=1:xmlsec library function failed: func=xmlSecDSigCtxSign:file=xmldsig.c:line=303:obj=unknown:subj=xmlSecDSigCtxSignatureProcessNode:error=1:xmlsec library function failed: TApplication.HandleException Erro -1: Falha ao assinar o Documento Lendo os fontes do xmlsec, notei que o único ponto onde o erro 45 ( XMLSEC_ERRORS_R_KEY_NOT_FOUND ) poderia ocorrer é em: https://github.com/lsh123/xmlsec/blob/master/src/xmldsig.c#L947 Mas a chave foi carregada com sucesso em FdsigCtx^.signKey,.. e se chamarmos manualmente o método "xmlSecKeyMatch", ele retorna 1 (sucesso) Ret := xmlSecKeyMatch(FdsigCtx^.signKey, nil, @FdsigCtx^.keyInfoReadCtx.keyReq); Não sei qual pode ser o problema...

Pessoal após alguns meses posso dizer que estamos livres da grande maioria esmagadora dos avisos e para quem estiver disposto a zerar os avisos da IDE usando ACBr nas versões mais novas do Delphi. Nesses últimos commits o @Daniel Simoes incluiu a diretiva: Para quem quiser ver sua IDE livre dos milhares de avisos ative essa diretiva no seu ACBr.inc Para ativar é só remover o ponto na frente dela: Para quem usa o fortes precisa incluir no seu arquivo RLReport.inc seguinte trecho: Devem restar apenas poucas linhas das units do Synapse mas faz parte. Se sobrou algum aviso muito provável é decorrente das units de outros geradores de relatório, mas isso fica a cargo dos usuários dos mesmos. Um forte abraço a todos e pronto para outra.

Estou usando a versão 2.9.2 do emulador e esta cancelando sem problema. [2016-08-17 09:58:44.156]:INICIO CANCELAMENTO [2016-08-17 09:58:44.168]:Carregando arquivo de cancelamento. [2016-08-17 09:58:44.168]:Validando arquivo de cancelamento. [2016-08-17 09:58:44.168]:Completando arquivo de cancelamento. [2016-08-17 09:58:44.215]:Assinando arquivo de cancelamento. [2016-08-17 09:58:44.274]:CANCELADO COM SUCESSO Estou codificando desta forma: ... //Carrega o arquivo XML do CF-e ACBrSAT.CFe.LoadFromFile(arqSATLoc); //Solicito o cancelamento //O método "CancelarUltimaVenda" sem parametros já executa internamente o "CFe2CFeCanc" e carrega os dados do XML. respCan := ACBrSAT.CancelarUltimaVenda; if(ACBrSAT.Resposta.codigoDeRetorno = 7000)Then begin //Trato o sucesso no cancelamento. end else //trato o erro ...

Removi os anexos anteriores e removi a sobrecarga na função TruncTo como descrito. Anexei as units novamente com mais alguns ajustes e com mais testes que os valores não correspondiam com o resultado esperado. Se alguém puder baixar e rodar o teste para ver se a função atual do repositório está realmente com problemas em alguns valores. Segue units. acbrutiltest.pas ACBrUtil.pas