Painel de líderes

Provavelmente o erro está associado com a 2015.002 que incluiu novas regras para documentos fiscais referenciados. Não adianta mesmo... Espero que um dia estes senhores tenham um pouco de bom senso e nunca façam atualizações de sistemas críticos no período de 15 de dezembro a 15 de janeiro. Tem dia que é para trabalhar, tem dia que é para descansar. A cada dia que passa, parece que somos governados cada vez mais por incompetentes. Um brinde a todos que neste dia 31 ainda estão remendando as mazelas do nosso governo! Feliz 2016!

Prezados, Estou homologando a cobrança bancária do banco HSBC, porém, foi rejeitado tanto o boleto quanto o arquivo remessa CNAB 400. Resposta do Banco sobre o arquivo remessa: Segue algumas considerações sobre como resolver alguns dos problemas que observei. Pelo visto essa informação deveria constar tanto a agencia quanto a conta para que dê os 11 dígitos conforme diz o manual. No meu caso a agencia sendo 1256 e a conta 00775-17, deveria constar 12560077517. Liguei para o suporte do HSBC no telefone 31-3503-5342 e falei com Sr. Rodrigo G. Rodrigues o qual está acompanhando o processo de homologação e esclareci com ele o seguinte: A conta do HSBC é de 7 números, porém, será sempre 5 + 2, sendo os 5 primeiros da conta e 2 do dígito. Isso é padrão do HSBC no mundo todo. Assim sendo, observei que alguns pontos da unit “ACBrBancoHSBC” não estão trazendo os dados da conta corretos, pois como ele atribui 7 para conta, o numero da conta sem o digito que é 00775, e a conta fica 0000775. Dessa maneira, nos locais que ele junta conta + digito para resultar em 7, ele não faz pois a conta já está com 7 digitos. Exemplo: wConta := PadLeft( OnlyNumber(Conta) + ContaDigito, 7, '0'); Neste caso a conta já está com 7 digitos e não acrescenta o digito da conta, fazendo com que fique errado o valor final da variável. Fica com valor 0000775 sendo que o correto seria 00775 para que ao somar com o digito fique 0077517. Vamos as modificações: No “create” do “ACBrBancoHSBC”, na linha 119, a conta está sendo fixada com tamanho de 7. fpTamanhoConta := 7; Sugiro que seja alterado para: fpTamanhoConta := 5; Na procedure “GerarRegistroHeader400” na linha 265 consta o seguinte: wConta + // Conta Corrente //Removi agencia repetido //ALFEU MOTA // Sugiro a alteração para: wAgencia + wConta + // Conta Corrente (Agência + Conta Corrente) Visto que no manual é tratado agencia e conta junto totalizando 11 digitos. Também na linha 356 onde consta PadLeft(OnlyNumber(Cedente.Agencia) + OnlyNumber(Cedente.Conta)+Cedente.ContaDigito, 11, '0') + Deverá ser alterado para: PadLeft(OnlyNumber(Cedente.Agencia) + OnlyNumber(Cedente.Conta)+Cedente.ContaDigito, 11, '0') + //Conta Corrente (Agência + Conta Corrente) Visto que no manual é tratado agencia e conta junto totalizando 11 digitos. Obs: Lembrando que para as variáveis ficarem corretas, o tamanho da conta tem que ficar 5. Resposta do Banco sobre o boleto: Minhas Considerações: Observei no fonte “ACBrBancoHSBC.pas” na function “MontarCodigoBarras” na linha 224 consta o seguinte: PadLeft(IfThen(ACBrBoleto.Cedente.Conta[1] = '0', RightStr(OnlyNumber(ACBrBoleto.Cedente.Conta),6) + Observem que a conta está ficando com 6 digitos, sendo que o correto seria 7. Como iremos setar a conta para 5 digitos, o copy deverá ser de 5 para que ao somar com o digito resulte em 7. Sugiro a alteração para: PadLeft(IfThen(ACBrBoleto.Cedente.Conta[1] = '0', RightStr(OnlyNumber(ACBrBoleto.Cedente.Conta),5) + Fiz essa alterações no componente e enviei para o banco para novos testes. Obs.: Embora o desenvolvimento do arquivo retorno irei fazer após a homologação da cobrança, resolvi fazer uma conferencia entre o código fonte e o manual, onde observei alguns pontos a ajustar, sendo eles. Na procedure "LerRetorno400" é atribuído os seguintes valores para as variáveis: rCodigoCedente := Copy(ARetorno[0], 109, 10); rConta := trim(Copy(ARetorno[0], 38, 6)); rDigitoConta := Copy(ARetorno[0], 44, 1); No manual na página 16, observei que na posição 109 com tamanho de 11 contém a seguinte informação "Uso do Banco", então embora não tenha um arquivo retorno, o copy está errado. Ajustei para o seguinte: rCodigoCedente := Copy(ARetorno[0], 109, 11); rConta := trim(Copy(ARetorno[0], 38, 5)); rDigitoConta := Copy(ARetorno[0], 43, 2); Segue manual e unit alterada para disponibilizar. Grato. cob400_jan.pdf Codigo Barras COB.pdf ACBrBancoHSBC.pas

Bem, talvez seja algo da versão do FastReport, eu sei que testei aqui e na versão 5.x que tenho aqui que é registrada, realmente acontecia o relatado, tudo ficava maluco.

Bom dia Gostaria de saber dos colegas como tratam a liberação de funcionalidades com cartão magnético ou código de barras em um cartão ex: Cancelar cupom fiscal somente com autorização do supervisor. beleza ele vai lá com o cartão e passa assim libera a ação Estive conversando com o Daniel, que sugeriu usar tipo login + senha como código de barras sendo mais fácil a substituição do que cartão magnético mas corre o risco de passar e ler no bloco de notas as informações ali contidas gostaria de saber opiniões e sugestões como vocês trabalham com isso.

Bom dia Dener, que coincidência, me cadastrei exatamente pra buscar uma resposta pra esse problema. Obrigado! suas alterações me ajudaram muito!

@RobertoSFilho em teoria é isso mesmo, o que existia se mantem.

Não acho que seja não, eu uso windows 10 em 5 maquinas de desenvolvimento e vários clientes já o adotaram e tudo roda normal.

Boa noite, realizei as alterações conforme sugestões do amigo @hleorj. Segue as imagens com os tributos separados e não separados. segue os fontes alterados. Fico no aguardo para ver se esta de acordo com os padrões. Att:, ACBrDANFCeFortesFrA4.dfm ACBrDANFCeFortesFrA4.pas

Utilize assim: ACBrECF1.InfoRodapeCupom.PostoCombustivel.Imprimir := true; ACBrECF1.InfoRodapeCupom.PostoCombustivel.Clear; with ACBrECF1.InfoRodapeCupom.PostoCombustivel.New do begin Bico := ; EI := ; EF := ; Volume := ; Automatico := ; end; Lembrando que pode ter mais de um, por isso o método .new, para criar um novo.

Ja tentou fazer um checkout em vez de relocate?

Não funcionará da maneira que você implementou... pois o relatório não existirá o tempo todo, ele é criado apenas para a impressão... e depois destruído... Veja: procedure TACBrNFeDANFeRL.ImprimirDANFE(NFE: TNFe = nil); var i : Integer; begin try case TipoDANFE of tiRetrato : frlDANFeRL := TfrlDANFeRLRetrato.Create(Self); tiPaisagem : frlDANFeRL := TfrlDANFeRLPaisagem.Create(Self); tiSimplificado : frlDANFeRL := TfrlDANFeRLSimplificado.Create(Self); else frlDANFeRL := TfrlDANFeRLRetrato.Create(Self); end; ................. finally FreeAndNil(frlDANFeRL); end; Na verdade, você está seguindo uma estratégia errada... você não deve tentar expor o TRLReport... isso é além de tudo perigoso, pois o usuário ganhará muito controle sobre o Relatório e poderá causar erros difíceis (ou impossíveis) de debugar... Você precisa é criar uma nova propriedade do mesmo tipo do Dialogo de Preview do Fortes (TRLPreview)... e permitir que o usuário associe (ou não) algo a ela, usando o object inspector ou em tempo de execução... se ela for Nil, o default seria usado... o componente usa o valor dessa propriedade, logo após a criação do relatório... Ex: frlDANFeRL.RLNFe.Preview(PropPreview);

Bom dia, Nas minhas postagens a dica que dou é o seguinte: Se ocorrer falha após o envio, não devemos enviar a nota novamente, uma vez que não sabemos se a falha ocorreu de fato no envio ou no retorno da SEFAZ. Sendo assim o que devemos fazer é carregar o componente com o XML assinado usando o LoadFromFile e em seguida executar o método Consultar. Exemplo: ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.NotasFiscais.LoadFromFile(XmlNFe); // o XML da NF-e a ser carregado esta assinado ACBrNFe1.Consultar; Se obtivermos uma resposta da SEFAZ informando que a nota não existe no banco de dados dela, isso significa que a falha ocorreu no envio, portanto devemos envia-la novamente. Por outro lado se a nota foi enviada e processada com sucesso vamos ter como resposta o protocolo de autorização, neste caso o método Consultar se encarrega de atualizar o XML deixando-o completo, ou seja, assinado e protocolo, pronto para ser enviado ao destinatário. Como você pode ver em nenhum momento foi necessário usar o GerarNFe e GravarXML.

Obrigado Cleber. Adicionei lá.

Segue refatoração da Revisão - Incluída a variavél sQuebraLinha : String; sQuebraLinha := QuebraLinha; - Incluída a Função Quebralinha. Para Fast : Function .TACBrNFeFRClass.QuebraLinha : String; begin if fQuebraLinhaEmDetalhamentoEspecifico then Result := ';' else Result := ' - '; end; Para Fortes : Function TfrlDANFeRL.QuebraLinha : String; begin if fQuebraLinhaEmDetalhamentoEspecifico then Result := #13#10 else Result := ' - '; end; == == unit === DAnfes.rar ========

Bom dia Duarte, Favor atualizar os fontes e testar novamente.

Estive ausente nos últimos dois dias e só agora pude baixar e testar as mudanças feitas e unificação das propriedades QuebraLinhaEm... para uma genérica, ficou melhor sim, mas fiz outras modificações: 1) No Fortes, modelo Paisagem, não havia sido aplicada a refatoração para o detalhamento dos medicamentos. 2) No caso específico de Medicamentos, quando estiver configurado para não efetuar a quebra de linha, abreviei as strings fixas, pois como o objetivo é fazer com que o detalhamento ocupe o menor número de linhas possível, as strings originais acabavam ocupando vários caracteres quebrando automaticamente em várias linhas as informações. Com isso, um danfe em formato paisagem (por ex) com apenas dois ou três produtos acaba gerando duas páginas, mesmo com a quebra linha configurada para "false". Pessoalmente, abreviado achei que ficou mais eficiente, pois em alguns clientes que usam medicamentos, passou a gerar mais uma página desnecessariamente quando as strings estão completas. Se for possível subir no SVN assim eu ficaria grato! Espero ter contribuído com o projeto! Segue anexo arquivos alterados. []s Luis ACBrNFeDANFeRLRetrato.pas ACBrNFeDANFeRLPaisagem.pas

Alterações realizadas: 1- Não contemplava "Tipo de Carteira" Uso no Banco Santander CNAB 240 - segmento P posição 059-059 No ACBr: ACBrBoleto.Cedente.TipoCarteira Implementada nova chave tipo inteiro no arquivo INI [Cedente] TipoCarteira=n (0=SIMPLES(DEFAULT)/1=REGISTRADA) 2- Não contemplava "Tipo de documento" Uso no Banco Santander CNAB 240 - segmento P posição 060-060 No ACBr: ACBrBoleto.Cedente.TipoDocumento Implementada nova chave tipo inteiro no arquivo INI [Cedente] TipoDocumento=n (1=TRADICIONAL(DEFAULT)/2=ESCRITURAL) DoBoletoUnit.pas