Agnaldo Prates

Regys, você está certo em quase todas as questões, claro que arquivos assinados digitalmente tem sim validade jurídica, DANFE, realmente é para conferencia etc. O que eu quis dizer é que, no caso específico do judiciário, não adianta informar arquivo digital ou coisa assim em uma petição inicial, isso por que para a propositura de uma ação, seja de qual natureza for, você precisará comprovar no momento da distribuição, os documentos que comprovam os fatos alegados, e, ai tem que estar impresso. Este foi o motivo pelo qual eu afirmo que, é o próprio estado que não está pensando em diminuir a emissão de documentos, pois, estes são de suma importância para aqueles que desejam comprovar alguma coisa. Então é isso, imagino que houve um entendimento controvertido em relação à economia "por parte do estado". Abraço.

Desculpe Regys, errado mesmo é próprio estado. No judiciário, especialmente em se tratando de autos, não é aceito mensagem virtual, tem que ser em papel, e, quanto mais informações houver melhor. O governo estadual exige NF-e para todos, eu disse todos os órgãos públicos, não aceitam cupom fiscal por mais válido que seja. O que o estado diz ao editar suas normas é que, o comercio e os simples mortais reduzam o consumo, mas, por outro lado, ele estado não pratica ou aceita o que recomenda. Este foi o sentido do comentário que fiz. Acredito que muitos já ouviu falar em autos com inúmeros volumes, vários milhares de páginas, isto é, a economia não está no primeiro plano do estado, o que é lamentável.

Parabéns pelo comentário Amarildo. Por outro lado, o Estado não está nem um pouco preocupado com "economia", especialmente de papel, tendo em vista que, as normas vigentes são tão arcaicas que, tem que ser em "papel", e, quanto mais informação nela, melhor para que "dele" precise. É o mínimo incoerência de setores do governo, que, uns vêm o meio ambiente outros só vêm o á lei determina, e, neste caso, vai prevalecer a lei. Triste realidade.

Bem, me parece que o colega postou em tópico diverso do NFS-e. Creio que os moderadores devam mudar.

Bom dia Valdir. Como não se sabe ao certo se vai acabar ou não com o boleto sem registro, devemos interpretar o texto de forma literal, senão vejamos: Referimo-nos ao Comunicado FB-014/2015, de 12/02/2015, através do qual encaminhamos o cronograma, abaixo, de implantação das fases do Projeto Nova Plataforma de Cobrança, para recomendar firmemente que o produto cobrança sem registro deixe ser ofertado. Aqui, estão dizendo que não deve ser mais ofertado, ou seja, vai acabar a oferta da cobrança sem registro. A partir de 01.06.2015, para os novos contratos de cobrança celebrados com clientes bancários emissores de cobrança. Estão reforçando que, a partir de janeiro de 2016, os novos contratos não poderão ser aceitos caso seja para cobrança sem registro. Cumpre ratificar que, conforme informado nos Workshops realizados em 15 e 22.01.2015 nesta Federação, a partir de janeiro/2017 os boletos de cobrança oriundos de cobrança sem registro somente poderão ser recebidos pelo Banco Beneficiário (emissor). Neste parágrafo, há uma lacuna enorme, ou seja, nas reuniões realizadas pela federação, ficou decidido que, a partir de janeiro de 2017 os boletos de cobrança sem registro somente serão recebidos pelo banco beneficiário. Ora, o acessório acompanha o principal, ou seja, como não informaram que são “TODOS”, há de se entender que, somente aqueles contratos que foram pactuados a partir de janeiro de 2016. Se a regra alcançasse todos os contratos, deveria estar expresso de forma diferente, salientando que, todos os contratos, inclusive aqueles acordados antes do início da vigência da norma. Lembrando que a lei não retroage, exceto em benefício do reu. Espero ter ajudado.

Bom dia a todos. Tenho visto aqui vários comentários sobre o “fim dos boletos sem registro”, e não teria como me furtar em comentar sobre o fato. Primeiro, a FEBRABAN comunica a todos os bancos que, a partir de 01 de junho de 2018, os bancos deixem de oferecer novos contratos de cobrança sem registros etc. Bem, o que o texto quer dizer é que, os novos contratos devam ser apenas com cobrança registrada, pois, para quem já está emitindo boletos sem registros, vão continuar como está, assim estabelece a Constituição Federal Brasileira em seu Art. 5º Art. 5, inc. XXXVI in verbis: “a lei não prejudicará o direito adquirido, o ato jurídico perfeito e a coisa julgada”, ou seja, não adianta portaria, comunicado ou qualquer outra norma que irá mudar o direito adquirido. Por outro lado, o mesmo comunicado, em nenhum momento diz que todos os contratos de cobrança serão migrados para a cobrança registrada, ou seja, estão enfatizando que se trata dos novos contratos. “Referimo-nos ao Comunicado FB-014/2015, de 12/02/2015, através do qual encaminhamos o cronograma, abaixo, de implantação das fases do Projeto Nova Plataforma de Cobrança, para recomendar firmemente que o produto cobrança sem registro deixe ser ofertado, a partir de 01.06.2015, para os novos contratos de cobrança celebrados com clientes bancários emissores de cobrança. ” Grifo nosso. Portanto, caso seja necessário, aconselho à aqueles que tiverem prejuízos por consequência do referido comunicado, que, procure um profissional jurídico para melhores esclarecimentos, e, caso seja imprescindível acione judicialmente o banco, e ele por sua vez que se vire para chamar ao processo a Febraban. Atenciosamente, Agnaldo Prates.

Bom dia Wellington. Ao que parece, pelo menos no xml postado, não constam: quantidade, e preço. Já experimentou informar estes valores? Att.

Boa tarde Guilerme. Bem, como eu disse, estes bancos não dispõem de uma norma legal que deva ser seguida, como é o caso da nfe, sped fiscal entre outros aplicativos. No entanto, eu tentei de toda forma gerar os arquivos para o banco Sicoob seguindo o manual e conforme as classes do AcbrBoleto, todavia ao enviar tais arquivos para homologação o banco retornava com inconsistências. Diante disso, instalei o módulo cedente no meu computador e gerei o arquivo através dele, tanto registrado ou sem registro, CNAB240 ou 400, dai fiz a comparação do o arquivo gerado pelo AcbrBoleto, realmente havia algumas diferenças, que vale ressaltar não estão no manual. Alterei a classe e gerei o arquivo novamente, desta vez não houve nenhuma anormalidade, o Sicoob recebeu o arquivo sem problemas. Caso você tenha alguma dificuldade em adaptar o arquivo texto, te aconselho instalar o módulo Cedente e gerar um arquivo através dele, depois gere um arquivo através do teu sistema. Baixe o WinMerge e veja onde estão as divergências, assim você mata o problema. Att. Agnaldo Prates. ACBrBancoob.pas

Boa tarde. Dê uma olhada neste demo. Att.

Eu tenho clientes emitindo boletos para este banco, homologuei e, inclusive não atualizo mais esta classe, tendo em vista que ela não bate com o sistema "Cedente" do Sicoob, muito embora esteja em conformidade com o manual. Att.

Boa tarde pessoal. Tomei a liberdade de modificar o demo do AcbrBoleto pois sempre que haveria necessidade de mudar alguns dados, estes deveriam serem alterados no componente, agora, estes dados são gravados no arquivo AcbrBoleto.ini e assim que é carregado o demo lê as configurações e atualiza os edits. Fiz tambem algumas alterações no componente, adicionei a propriedade "Ambiente" o qual é exigido pela caixa para homologação. Sei que ainda há muita coisa para ser mudada mas, já está funcionando. Acredito que com a ajuda de todos podemos melhorar os demos do Acbr cada vez mais. Destarte, um ótimo ano novo a todos e, torço para que 2015 seja muito melhor do que fora bom em 2014. ps. O demo está compactado pois não tenho permissão para postar arquivos .dfm AcbrBoletoDemo.rar ACBrBoleto.pas

Boa tarde. Lembrando que o valor "3" trata-se de isenção, os códigos são: 1 - Mora diária 2 - Taxa mensal 3 - Isento Página 33 do manual. CNAB_240_SIGCB - 67.118 v006.pdf Link http://downloads.caixa.gov.br/_arquivos/cobranca_caixa/manuaissicob/LEIAUTE_CNAB_240_SIGCB_COBRANCA_CAIXA.pdf Obs. Estou homologando para o sistema SIGCB, fiz algumas alterações no ACBrBoleto mas não sei se vai dar certo, estou aguardando o retorno do gerente da caixa. Att.

Item 3.9 do "manual" Layout.xls "3.9. Número do documento: Informe o número do documento/título estabelecido pela empresa quando da emissão da fatura/duplicata, contrato de prestação de serviço, entre outros". Formato: nnnn-x n= Numero x= DV Att.

Revise seu sistema, principalmente alguns pacotes próprios que podem estar chamando esta bpl. att.

Boa tarde. Em primeiro lugar, há diferentes entendimentos quanto à guarda eletrônica dos arquivos XML que, poderá ser no cliente emitente ou mesmo em empresas especializadas para tal. Quanto a responsabilidade ventilada no primeiro post, não é de responsabilidade da software house a guarda destes arquivos, exceto se há algum tipo de prestação de serviços neste sentido. Quanto à contingência, atente para o que dispõe a legislação pertinente ao caso, neste, a página 9 do manual de especificações técnicas é claro em sua página 9 parágrafo segundo: “Para poder fazer uso desta opção ”figura 8”, de guarda eletrônica do arquivo XML emitido em contingência, deverá, previamente, lavrar termo no livro Registro de Utilização de Documentos Fiscais e Termos de Ocorrência - modelo 6, ou formalizar declaração de opção segundo disciplina que vier a ser estabelecida por sua Unidade Federada, assumindo total responsabilidade pela guarda do arquivo e declarando ter ciência que não poderá, posteriormente, alegar problemas técnicos para justificar a eventual perda desta informação eletrônica que está sob sua posse, assumindo as consequências legais por ventura cabíveis”. Grifo nosso. Portanto, se há algo que é bem planejado pelo fisco é justamente minimizar a possibilidade do cliente agir de “má fé” no sentido de omitir dados fiscais, se existe algo que o estado faz bem é justamente a cobrança de tributos.

Acredito que não seja o ACBrBoleto tendo em vista que, é necessário o Boleto para gerar o arquivo de remessa. No seu caso que, é somente transferência, imagino que o teu software deverá gerar outro tipo de arquivo como borderô etc. A dica é entrar em contato com o setor de processamento de dados do banco para saber mais informações. Att.

Por aqui está tudo normal, posso aumentar e diminuir que não ocorre o problema descrito. Segue img. Att.

Veja o que o manual diz. Página 45. G015 Código Remessa / Retorno (...) ‘1’ = Remessa (Cliente à Banco) ‘2’ = Retorno (Banco à Cliente) ‘3’ = Remessa Processada (Banco à Cliente - Pré-crítica) ‘4’ = Remessa Processada Parcial (Banco à Cliente - Pré-crítica) ‘5’ = Remessa Rejeitada (Banco à Cliente - Pré-crítica) O arquivo enviado foi rejeitado. Sefia interessante a gente pensar numa possibilidade de criar uma classe para retornar estes erros: 240 : begin if Copy(SlRetorno.Strings[0],1,3) = '104' then begin if Copy(SlRetorno.Strings[0],143,1) = '5' then Raise Exception.Create( ACBrStr( NomeArq + sLineBreak + 'Arquivo de remessa rejeitado.') ); end; LayoutRemessa := c240 ; end; Att.

Bom dia Rodrigo. Bom, ao que parece, todos eles retornam 1 posição a mais no final da linha, ou seja, o que deveria ser 240 é na verdade 241 e esta regra aplica também ao CNAB 400 retorno. Mas, creio que o nome do arquivo de retorno da caixa deva exigir a extensão .ret, experimente renomeá-los! Ex: ret000449.ret Att.

Os arquivos informados possuem um caractere a mais, CNAB240, são 240 posições, e, pelo exemplo está retornando de forma indevida. Att.

Boa tarde. Fique a vontade para contribuir, creio que toda contribuição é bem vinda. Antes de tudo é importante analisar os modelos que já existem, tendo em vista que muitos dos usuários já utilizam os mesmos. Sobre a versão, salvo melhor juízo, creio que a partir da versão 4 que abrange várias versões do Delphi. Quanto ao Fortes, lhe digo que no meu caso eu o utilizo a muito tempo e está atendendo de forma satisfatória sim. Att.

Bom dia. Ao que parece é exatamente isso que está ocorrendo, linha 783 unit ACBrCaixaEconomica.pas. if CodMotivo <> 0 then begin Creio que deva ficar como descrito abaixo. CodigoLiquidacao := IntToStrZero(CodMotivo,2); CodigoLiquidacaoDescricao := CodigoLiquidacao_Descricao(CodMotivo); MotivoRejeicaoComando.Add(IfThen(Copy(Linha, MotivoLinha, 2) = '00', '00', Copy(Linha, MotivoLinha, 2))); Ao que parece neste local deveria estar o código da Liquidação, e não motivo da rejeição. CodigoLiquidacao := IntToStrZero(CodMotivo,2); DescricaoMotivoRejeicaoComando.Add(CodMotivoRejeicaoToDescricao(OcorrenciaOriginal.Tipo, CodMotivo)); Consequentemente a descrição deverá ser a descrição da liquidação. end; Possivelmente a Juliana vai dar uma olhada e se estiver correta a nossa linha de pensamento com certeza ela irá disponibilizar a devida correção. Att.

Faz sentido e acredito ser pertinente tal alteração, todavia é importante frisar que, caso a cobrança seja sem registro há necessidade de um tratamento especial pois, o campo em questão traz o seguinte texto, "SEMREG". Vide página 22 do manual disponível em:https://www.banrisul.com.br/bob/data/CobrancaEletronicaBanrisul_layout_pdr_Febraban400_vrs09022009.pdf Att.

Penso que vai ser necessário criar um pacote para instalar o mesmo, visto que, o componente vai chamar o original. Se fosse arquivo do fast, com certeza era só setar o FastFile.

Muito importante esta colocação sua Regys, afinal, a NFC-e tem algumas restrições que a priori não é recomendável seu uso on-line. Se cair a net o cliente vai ficar na fila até quando? Se for standalone ainda assim, pode ser que caia nas restrições relativas ao prazo para envio. Bem observado Regys.