ACBRPAGFOR : PROPRIEDADES PARA INFORMAÇÃO DE NRO.LOTE E NRO.SEQUENCIAL DO REGISTRO

[Carmo]

Companheiros

Boa Tarde!

Estou ,no ERP da empresa que trabalho, iniciando desenvolvimento do recurso de geração de Arquivo de Pagamentos a Fornecedor utilizando o componente AcbrPagFor.

Antes de iniciar o desenvolvimento eu li o layout padrão CNAB-240 e constatei que será necessário gerar o Arquivo-Texto de remessa com o Segmento J. 

Constatei existência no Layout de 2 campos chaves, que são :
- Número do Lote de Serviço
- Número Sequencial do Registro No Lote

Assim, criei estrutura no Banco de Dados para conter estes 2 números de controle que são incrementados à medida que os Lotes são Cadastrados!

Minha dúvida é como posso passar estes 2 números para o componente AcbrPagFor.

Em quais propriedades poderei inserir esta informação ?

Não encontrei no componente propriedades para informar estes valores que estão registrados no banco de dados.

Muito obrigado pela ajuda.
 

[Italo Giurizzato Junior]

Bom dia @Carmo,

Você não passa essas duas informações para o componente, é ele que controla internamente.

[Carmo]

Sr. Ítalo

Bom Dia!

O problema é que inicialmente eu tive que criar no Banco de Dados tabelas para :
- Cabeçalho do Lote de Pagamentos ( tendo como chave o Número do Lote )
- Itens do Lote de Pagamentos     ( tendo como chave o Número do Lote e Número Sequencial do Registro )

Portanto o ideal seria passar estas chaves para o componente!

Principalmente porque no Arquivo-Retorno a única informação que o Banco retorna, e que possa se utilizada 
para reconhecer de qual duplicata se refere, é justamente : Nro. do Lote e Nro. Sequencial do Registro no Lote.

Vou ter que decidir como proceder neste caso então para que eu consiga utilizar o AcbrPagFor.
 

[Carmo]

Veja o Layout do Arquivo-Retorno :

[Italo Giurizzato Junior]

Bom dia @Carmo,

Veja a imagem a baixo:

Essa é a regra para o campo "Lote".

Essa regra deixa claro que devemos informar "0000" ao campo Lote do registro Header e "9999" ao campo Lote do registro Trailer.

Um arquivo pode conter um ou mais Lotes e a regra também deixa claro que o campo Lote do primeiro Lote incluído no arquivo tem que receber o valor "0001", caso o arquivo tenha um segundo lote este deve ser de numero "0002" conforme consta na regra.

Essa é a minha interpretação da regra acima.

[Carmo]

Senhor Italo

Boa Tarde!

Me permita explicar melhor a minha dúvida para o Senhor !

Pelo que foi possível entender pelo Layout de Pagamentos ao Fornecedor o Número do Lote é incremental.
Começa por '0001' e terá que ser incrementado para cada Lote seguinte. 

E naturalmente temos que considerar que estes Lotes gerados pertencem à uma Conta Bancária.
Portanto o primeiro Lote da Conta Bancária '100' deverá começar de 1.
E o primeiro Lote da Conta Bancária '200' deverá começar de 1.

Minha dúvida é como posso controlar este Número do Lote se quem gera ele automaticamente é o Componente AcbrPagFor ?

Como os companheiros que já implementaram controles utilizando o Componente AcbrPagFor controlaram esta situação ?

Constatei que o Acbr gerou de forma correta o primeiro teste , veja :
 

Grato por sua ajuda!

[Italo Giurizzato Junior]

Boa tarde @Carmo,

Eu sei o que você esta pensando.

Vou enviar hoje um arquivo contendo apenas 1 lote no arquivo, este vai ser de numero 0001.

Amanhã vou enviar um outro arquivo também com apenas 1 lote, este vai ser de numero 0002.

E assim por diante.

Mas na minha interpretação da regra não é isso.

O numero do primeiro lote de todos os arquivos que você enviar sempre vai ser 0001.

Veja como é a estrutura de um arquivo que é enviado ou retornado.

Note que todos os arquivos são compostos por um registro Header como numero do lote obrigatoriamente tem que ser 0000 e por um registro Trailer cujo numero do lote obrigatoriamente tem que ser 9999.

No componente esses dois registros são o Registro0 e Registro9:

Note que ao gerar o Registro0 é definido o valor zero para a variável FQtdeLotes.

Entre esses 2 registros temos os registros que compõe o lote, note que podemos ter 1 ou mais lotes.

Cada lote vai conter o seu registro de Header (Registro1) e seu registro de Trailer (Registro5) e entre esses 2 registros temos os registros chamados de Segmento.

No componente temos:

Note que ao gerar o Registro1 que é o Header do lote o FQtdeLotes é incrementado e esse incremento só ocorre ao gerar o Registro1.

E esse numero de lote é utilizado por todos os registros que compõe o Lote e também no Registro5 que é o Trailer do lote.

Isso diz ao banco que todas essas "linhas" pertence a um único Lote.

Se o arquivo possuir um segundo Lote, um novo Registro1 vai ser gerado e consequentemente o seu numero de lote vai ser 2 e todos os seus Segmentos e o Registro5 vão ter como numero do lote igual a 2.

Experimente forçar o Registro1 começar com um numero diferente de 1 para o numero do Lote.

Use o programa exemplo para esse teste.

Na procedure que gera o Registro1 coloque mais um Inc(FQtdeLotes) e faça o teste.

Esses fragmentos de códigos acima estão na unit CNAB240.GravarTxtRemessa.

 

[Carmo]

Sr. Ítalo

Boa Tarde!

Finalmente eu entendi os conceitos que envolvem a geração do Arquivo-Remessa de Pagamentos!

Meu pensamento estava muito vinculado ao conceito de Cobrança Bancária CNAB.
E para complicar o Suporte do Banco tinha me induzido acreditar que no arquivo-retorno seria retornado somente o Segmento Z.

Porém, questionando novamente o Suporte do Banco eles me afirmaram que no arquivo-retorno também vai vir o Segmento J,

com todas informações que nós enviamos, acrescidas de informação do Retorno ( Código de Ocorrências ).

Assim, com as informações que identificam a Duplicata ( Código Barras e Seu Número ) contidas no Segmento J eu vou poder 
realizar a baixa correta da Duplicata caso esta tenha sido corretamente liquidada.

Neste cenário o Número do Lote de Serviço que existe no Arquivo-Retorno não tem mais relevância.

Muito grato por sua ajuda.

Por favor pode encerrar o Tópico. 
 

[Italo Giurizzato Junior]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.