Dica: Campo incremental para vários relatórios

[Donaldson]

Pessoal,

Um cliente necessitava que tivesse um número incremental (numero da remessa) e que vários relatórios verificassem esse número. Por exemplo, ele tem 3 relatórios diferentes que geram líquidos para o Bradesco, sendo 1 relatório para líquidos de salário, outro para férias e outro para rescisões.

De acordo com o layout do banco, cada remessa gerada, independente do tipo de pagamento, tem que sair com um número de remessa incrementando 1, ou seja, se o numero de remessa do liquido salarial é 300, o proximo a gerar será 301 depois 302, independente do tipo de pagamento se é ferias, liquidos salariais ou rescisões.

A solução foi a seguinte:

Criei uma tabela "Z" com um campo inteiro:

CREATE TABLE ZNUMSEQ (SEQ INT)

Coloquei o valor da primeira remessa que será gerada:

INSERT INTO ZNUMSEQ (SEQ)

VALUES (1)

Criei a procedure abaixo, fazendo o incremento do campo:

CREATE PROCEDURE ZNUMSEQUENCIAL

AS

UPDATE ZNUMSEQ SET SEQ = SEQ+1

Depois basta associar a procedure para cada relatório que deverá verificar o numero da remessa. Não esquecendo de colocar no relatório a sentença buscando o campo incremental (SELECT SEQ FROM ZNUMSEQ).

Abraços.

[Jorge]

Donaldson,

Boa dica !!!

[Jair - Fórmula]

Legal, boa idéia...

Eu já fiz um esquema parecido pra um cliente, mas fiz diferente. Eu usei um trigger na tabela FREMPAG, onde no campo do contador de remessa, eu coloquei, pra quando atualizar, ele atualizar nos outros relatórios além do que está sendo atualizado pelo sistema... ou seja, quando roda em um, ele atualiza os demais com o mesmo número, assim, todos sempre serão uma sequencia única.

[Jairo]

Legal Donaldson ...

Vale a idéia ... e pra muitos pode servir também ...

Se todas as vezes que alguém tivesse algum problema assim colocasse pra todos nós, teríamos muitas dicas aqui desse tipo ...

Obrigado Donaldson !!!

[Sebastião Souza Junior]

Concordo!!!!

[judilon]

Muito oportuno a dica!!!

Já estava estudando a forma que ia fazer isso, mas agora já tenho duas opções.

T +

[Jorge]

Jair,

Sua dica também é boa, porém resalvo apenas que a dica dada pelo Donaldson pode ser utilizada para mais de um relatório utilizando a mesma sequência.

Para esta funcionalidade, basta utilizar a mesma PROCEDURE em todos relatórios que devem seguir tal sequencial.

[Jair - Fórmula]

Jair,

Sua dica também é boa, porém resalvo apenas que a dica dada pelo Donaldson pode ser utilizada para mais de um relatório utilizando a mesma sequência.

Para esta funcionalidade, basta utilizar a mesma PROCEDURE em todos relatórios que devem seguir tal sequencial.

Ah sim... claro.

No meu caso, na verdade era o seguinte: O cliente tem várias coligadas, e quando envia a remessa de pagamento, independente da coligada, segue uma mesma sequencia, então, para aquele banco, em qualquer das coligadas que era rodado, o trigger sempre atualiza o contador no registro de todas as demais coligadas. Achei que dessa forma seria a melhor maneira, mas claro, a opção do Donaldson é ótima também.

[Mauricio J. T.]

Ja fiz isso, mas usando a tabela de valores fixos, onde se precisar, o proprio usuario podera alterar o valor.

[Jair - Fórmula]

Pra folha de pagamento é válido tambem... porém para outros aplicativos que não tem tabelas de valores fixos, permitindo uma fácil atualização manual, caso necessário, são duas outras opções mais acessíveis para uso.

[Donaldson]

Mauricio,

A vantagem de colocar dessa forma é que depois de criar essa rotina fica transparente para o usuário esse controle, não necessitando de ir em valor fixo e ficar alterando, que foi a solicitação do cliente.

Abs.

[Ivan Martinez]

Donaldson,

Uma pergunta : Este numero sequencial que o banco exige pode ter "pulos" , ou seja, ela pode mandar um arquivo com o número 300 e depois mandar o 302, sem mandar o 301 ?

Pergunto isso pelo seguinte : Você concorda que a cada geração o número da tabela Z é incrementado, independente se esta geração é ou não oficial, ou seja, ela pode ter gerado o relatório e errado o filtro, por exemplo, exigindo uma nova geração.

Caso o sistema do banco aceite que determinados números sejam "pulados" , isso não é problema, pois você sempre vai garantir que nunca dois números iguais de remessa sejam enviados.Mas se os "pulos" não são admissíveis pelo banco, aí como resolver ?

Abraço

[Donaldson]

Ivan,

Foi um dos questionamentos que fiz com o cliente antes de implementar o que não é era um problema. O que teria que garantir é que não fossem duas remessas com mesmo número.

Abraço.

[Mauricio J. T.]

Quando falei para usar a tabela de valores fixos, e pra fazer uma SP atualizando ela.

Caso ocorra os pulos que o Ivan citou, e so ir na tabela de valores fixos e voltar o numero......

[Jair - Fórmula]

A própria RM também não trata isso nas geraçòes de arquivos de remessa, pois, ela só sabe que foi gerado, entào incrementa nos seus controles, mas se foi enviado, apagado o arquivo, ocorreu erro, etc... não sabe, então sempre incrementa, embora permita ao usuário corrigir o número na tela de configuração de remessas bancárias.

[Jean Marcel Orlandini]

Boa dica...

Vou testar com algum cliente.

Valeu.

[Sebastião Souza Junior]

MOVIDO PARA A ÁREA: Fórum RM x Fórmula > RM Sistemas > [RM] Dicas Gerais

Sua mensagem foi movida para a área correta, pois foi postada em local errado.

Agradecemos o seu post, mas por favor, verifique melhor em qual lugar postar para que as coisas fiquem em ordem por aqui, ok ?

Qualquer problema ou dúvida contate-nos enviando uma PM ( MP - Mensagem Privada ) ou email (se estiver disponível).

Se preferir, faça um post com a sua dúvida ou problema.

Contamos com a sua compreensão e colaboração.

Muito obrigado.

Equipe Fórum RM