sismais

Bom dia pessoal! Gostaria de sugerir um ajuste que fiz na unit ACBrNFeNotasFiscais.pas, método ValidarRegrasdeNegocios. Nas mensagens de validações dos itens, eu adicionei o complemento: [nItem: '+IntToStr(Prod.nItem)+']', tanto no GravaLog quanto no AdicionaErro. Este complemento permite identificar de forma fácil em qual item está o problema, principalmente de notas com muitos itens. Eu vi que em algumas validações já tinham algo parecido, mas usando o índice "i" ao invés do nItem. Eu também alterei estes colocando o nItem, acredite que fique mais preciso e compatível com a o nItem no banco de dados/aplicação (caso estejam em ordem diferente ao índice do ACBr). Segue o arquivo em anexo. Desde já agradeço. ACBrNFeNotasFiscais.pas

Olá @gralak valeu pela dica, no meu caso acabei fazendo por INI mesmo.

A quem interessar, o Daniel, sugeriu uma sugestão neste link:

Pessoal, sei que já faz tempo. Mas precisei Homologar o Boleto do BNB aqui e me peguei nesta questão. Notei que não foi adicionado aos arquivos FastReport no SVN do projeto. Como ficou esta questão? Obs: Vi que se eu colocar apenas "21" na alimentação do ACBrBoleto ao invés do "4' como o colega exemplificou acima, dá certo (por que internamente o ACBr faz alguns tratamentos ), mas não seria o método correto (poderia ter problemas se novas implementações fossem efetuadas, sendo que "21" não é o Código da Carteira, e sim o "4", e deveria então ser feita a adaptação, tal como a sugerida para o FastReport (não sei se fui bem claro). Gostaria de saber como os colegas tem conseguido resolver esta questão, e a opinião da Juliana.

Olá pessoal. Estou com uma situação/problema em relação ao uso do estadoSimuladoECF. Não é nada errado no ACBr apenas dúvida de como implementar. Estudei o demo do ACBrNFC-e + TEF e consigo realizar o procedimento normalmente, já me situei quanto à necessidade do "estadoSimuladoECF". Mas estou com a seguinte situação agora: Cenário: - Transação com 2 cartões + NFC-e. - Seq. 44 (Sequência 44) do roteiro de pré-homologação. Nela é solicitado que eu passe o 1° cartão normalmente, e assim que solicitar para inserir o 2°, eu devo desligar o PC e impressora. No retorno a transação TEF deveria ser Cancelada. Situação/Problema: Ao religar o computador e inicializar o meu PDV (e o ACbrTEFD), é acionado o método VerificarTransacoesPendentes da classe ACBrTEFDClass e executado este código: // Cupom Ficou aberto?? ...Se SIM, Cancele tudo... // if (wEstadoECF in ['V', 'P', 'N', 'O']) then CancelarTransacoesPendentesClass else // NAO, Cupom Fechado, Pode confirmar e Mandar aviso para re-imprimir // ConfirmarESolicitarImpressaoTransacoesPendentes; O problema é que, diferente de uma impressora ECF, aqui eu não sou forçado a comunicar novamente com a impressora (para recuperar o cupom ECF) e nem tenho como recuperar o ultimo valor atribuido à variável "estadoSimuladoECF". Sendo assim, ao invés de Cancelar a transação, ela é aprovada. Obs: Meu ACbrTEFD com NFC-e sempre inicia com o estado "tpsLivre". Tenho uma solução em mente: A cada alteração, armazenar o valor da variável "estadoSimuladoECF" em um arquivo INI (ou BD local do PDV), e quando houver alguma queda bruta de energia, eu recupero esta informação e se o valor for "tpsPagamento" (EstadoECF='P') então faria o cancelamento normalmente tal como está no Roteiro. Eu não queria implementar sem postar aqui para ver se alguém tem uma sugestão melhor e também para ficar registra a solução, a fim de ajudar outros membros. Obs: Não se se fui bem claro. De qualquer forma segue abaixo a desrição do roteiro: Desde já agradeço.

Perfeito. Obrigado José.

Up! @Italo Jurisato Junior Poderia verificar a possibiidade de incluir esta alteração no projeto? Desde já agradeço.

Caros moderadores, fiz um pequeno ajuste no ACBrBancoCaixa.pas e envio em anexo para que possam analisar e remeter ao repositório. De acordo com a o Manual do Layout CNAB400 (MO 67126 009) da caixa, o campo 43.1, posição 392 a 393 é usado tanto para Dias para Protesto quanto para Dias para Baixa/Devolução do Boleto. Na linha 1023 o trecho abaixo não contempla o prazo para Baixa/Devolução: IfThen((DataProtesto > 0) and (DataProtesto > Vencimento), PadLeft(IntToStr(DaysBetween(DataProtesto, Vencimento)), 2, '0'), '99') + //392 até 393 - Quantidade de dias para início da ação de protesto ou devolução do Título Alterei para que considere também a DataBaixa: IfThen((DataProtesto > 0) and (DataProtesto > Vencimento), PadLeft(IntToStr(DaysBetween(DataProtesto,Vencimento)), 2, '0'), IfThen( (DataBaixa > 0) and (DataBaixa > Vencimento), PadLeft(IntToStr(DaysBetween(DataBaixa,Vencimento)), 2, '0'), '99') ) + //392 até 393 - Quantidade de dias para início da ação de protesto ou devolução do Título Segue arquivo anexo. ACBrBancoCaixa.pas

Olá pessoal, na geração de remessa da Caixa (240 e 400), o Titulo.DataBaixa é usado para determinar a data para Baixar (Efetuar a Devolução) do Boleto lá no banco. Os campos Titulo.DataBaixa e Titulo.DataLimitePagto tem funções similares de fato, e podem confundir um pouco. A dica que dou (e que fiz aqui) é ter apenas um campo no banco de dados (e para o usuário) e setar os dois sempre iguais. Vejam no exemplo abaixo (Inclusive coloquei um ToDo com uma questão filosófica, rs.): if FdmBoleto.qrCedenteDIAS_BAIXA.Asinteger > 0 then begin DataBaixa := Vencimento + FdmBoleto.qrCedenteDIAS_BAIXA.Asinteger; {ToDo: Eu estou usando o mesmo parametro para a DataBaixa e DataLimitePagto, mas, e se algum cliente/empresa desejar usar a DataBaixa (para baixar o boleto no banco) mas não quiser que saia a mensagem no boleto, como deveria proceder? Podemos até querer responder que se é para baixar após a data X, então este também é o limite de pagamento. A afirmação está correta, porém, sabendo como cliente(pagador) se comporta, ao ver a mensagem "Não receber após xx dias" ele pode usar de má fé e deixar passar os dias para tentar uma negociação e não pagar juros. O que podemos fazer em relação à isto? Opção 1: Criar um parametro que determina se a mensagem deve ser exibida? Opção 2: Não usar o DataLimitePagto, apenas o DataBaixa, mas, e a questão de DataLimitePagto em alguns bancos no ACBrBoleto ser usado como DataBaixa (como citado em um post do fórum) ? } DataLimitePagto := DataBaixa; //OBS: No meu caso não uso as mensagens do ACBr, uso personalziadas. sMensagem := sMensagem+'Não Receber após ' + IntToStr(DaysBetween(Vencimento, DataLimitePagto))+ ' dias' end;

@SolivanAraujo então a estrutura de arquivos é a mesma? Se for seria bem tranquilo para adaptar o ACBrBoleto para tal.

Banco Bradesco e CEF também estão permitindo uso de WebService. Acredito que deve ser uma adesão comun dos bancos, a demora creio que seja somente acertar na segurança dos dados e processos.

Usando o exemplo do ALA. Então daria certo enviar para um arquivo TXT também não? Neste caso colocando o caminho do arquivo na configuração de Porta do ACBrPosPrinter.

Uma dúvida (Me perdoem se não tiver muito a ver). É possível usar o gpCliSitef sem a DLL (apenas troca de arquivos)? Pelo que vi está fixando via DLL? Pois pretendo usar somente troca de arquivo , e usando o gpTefDial não tem o campo ParametrosAdicionais.

@Juliomar Marchetti acho que não entendi direito. O campo "ParametrosAdicinais" só existe dentro da classe ACBrTEFDCliSiTef. Porém não uso ela e não vi nos fontes como este campo é usado na ACBrTEFDDial (gpTefDial). Não seria o caso de criarmos o este campo também para o TEFDial ? OBS: Perdão, eu não uso o Framework, uso Componente Delphi, creio que possa ser isto.

Ok @Juliomar Marchetti vou verificar com eles, quando o fizer posto a resposta aqui. Obrigado.

Estou na mesma situação: Sitef + gpTefDial. Vi que no gpCliSitef que tem uma opção "ParametrosAdicinais" seriam neste campo? Ainda que seja, como poderíamos fazer no gpTefDial ? Desde já agradeço. A quem interessar, este tópico está duplicado:

Bom dia pessoal. @Juliomar Marchetti também tinah esta dúvida. Neste caso existe a Homologação sem ECF e sem NFC-e também? Ou precisa ter NFC-e quando não houver ECF? Eu tenho esta mesma necessidade que o @André Anselmo .

Obrigado José, baixado e testado.

Entendi Bruno. Não tinha visto sua resposta antes. Bom é aquele caso, o sistema já tem uma forma de fazer mas querem de outra. rs Neste caso não vejo outra alternativa a não ser a solução do BigWings

Obrigado, e desculpa. É o cliente que está no meu pé aqui. Mas vou fazer um paleativo até a solução definitiva.

Entendi Juliomar, neste caso eu não trabalho com Fortes, mas ele também não teria este recurso? Gerar o PDF sem precisar abrir o relatório?

Gente, algum retorno sobre isso?

Olá pessoal, me desculpem se eu estiver errado, mas acredito que tenha um pequeno erro na geração de remessa CNAB400 da caixa. No arquivo ACBrBancoCaixa.pas linha 1020 temos: IntToStrZero(round((ValorDocumento*PercentualMulta)/100), 10) + //358 até 367 - Valor nominal da multa Exemplo de Aplicação: ValorDocumento := 313,00; // R$ 313,00 PercentualMulta := 3 ; // 3% Resultado gerado:= "0000000009" Resultado esperado: "0000000939" | (313 * 3 / 100) = R$ 9,39 Pelo que observei o round remove os decimais, e no IntToStrZero resta apenas o "9" no final da string. Para gerar o valor correto, o "PercentualMulta" deveria ser multiplicado por 100 (assim como é feito com o Juros e Desconto), ficando assim: IntToStrZero(round((ValorDocumento* (PercentualMulta*100) )/100), 10) + //358 até 367 - Valor nominal da multa No manual "LEIAUTE DE ARQUIVO ELETRÔNICO PADRÃO CNAB 400 COBRANÇA BANCÁRIA CAIXA - SIGCB" Versão: 67.126 v006 micro, não tem uma especificação clara de como deve ser o formato, mas presumo que seja como está sendo feito no juro atualmente, onde os ultimos 2 caracteres da string são dos decimais. OBS: Detectei este probleam após implementar em um cliente (até achei que era alguma falha minha, pois muita gente deve usar boleto caixa, mas parece que não.) Por favor, os moderadores do fonte poderiam dar uma olhada?

Pessoal, tive um problema na caixa, e gostaria de ver o que os amigos fizeram a respeito. Segundo o manual do layout CNAB 400 da Caixa (NE024), existe uma nota falando sobre a instrução de protesto ao registrar um boleto via arquivo de remessa: "Caso o CEP do Pagador não esteja vinculado a uma agência cobradora de protesto (CEP sem praça de cobrança), o título será registrado com instrução de devolução, sendo o Prazo de Devolução igual ao Prazo de Protesto, com prazo mínimo de 5 dias." Fonte: LEIAUTE DE ARQUIVO ELETRÔNICO PADRÃO CNAB 400 COBRANÇA BANCÁRIA CAIXA - SIGCB - Versão: 67.126 v006 micro No arquivo de retorno do dia seguinte virá a seguinte mensagem referente em títulos com esta situação: “49 – CEP sem praça de cobrança (não localizado)." Ou seja, se o prazo para protesto era para 10 dias após o vencimento, mas o título não tem como ser protestado (e isso não temos como saber antecipadamente, a não ser um trabalho minucioso identificando os CEps que não tem como protestar), o sistema da caixa automaticamente registra o título com a instrução de devolução, e usa o mesmo prazo de 10 dias. Isso é ruim, pois além do boleto não ser protestado, ele ainda será baixado do sistema de cobrança em um prazo muito menor do que o comumente utilizado (de pelo menos 90 dias). Até encontrei uma sugestão bacana para o probelma aqui: http://blog.sisalu.com.br/index.php/2017/11/14/financeiro-ceps-sem-praca-de-cobranca/ Que é fácil de implementar no sistema, porém para a empresa fica complicado de alimentar esta informação, pois ele tem que ficar consultando a Caixa (até onde sei) para saber se o CEPs do cliente deles possui agente de protesto ou não, e tem ainda o fato da empresa estar sempre cadastrando novos clientes, e quando trata-se de atacadista ou indústria, são muitos clientes em várias cidades e CEPs diferentes. Alguém do grupo já encontrou alguma solução para isso? Se sim, poderia compartilhar conosco? Desde já agradeço.

Brunno, caso ainda não tenha feito, minha sugestão é você não precisar colocar o botão na tela do FastReport (vai ficar complicado de manter atualizações do componente), você pode gerar o PDF em um local temporário, e usar o ACBrMail ou a paleta Indy para enviar o e-mail, controlando sempre pela sua aplicação com um poder maior de personalização e facilidade na manutenção. (Um exemplo mais ou menos com este ocorre na NF-e)