SQL: Création de vieillissement des seaux sur base de la dernière date de paiement pour l'information financière

J'ai besoin de créer un vieillissement rapport de soldes de crédit sur la clientèle de niveau.

Notes:

  1. Vieillissement est basé sur la dernière date de paiement.

  2. Un client peut avoir plusieurs comptes, et il y a parfois des erreurs dans lequel un paiement est imputé sur le compte de mal. Par exemple, un client avec un 15 $de solde sur un compte rend un 15 $de paiement. Que 15 $de paiement peuvent être appliquées au mauvais compte, laissant le client avec un $-15 équilibre sur un seul compte et un 15 $de l'équilibre sur l'autre. Ce client a besoin d'être exclus du rapport.

SQL pour obtenir les clients avec les soldes de crédit:

SELECT 
  ACCOUNT.CUST_ID
, sum(ACCOUNT.BALANCE)

FROM ACCOUNT

GROUP BY ACCOUNT.CUST_ID

HAVING sum(ACCOUNT.BALANCE) < 0

SQL pour obtenir la dernière date de paiement:

SELECT

  TRANSACTIONS.CUST_ID
, MAX(TRANSACTIONS.POST_DATE)

FROM TRANSACTIONS

WHERE TRANSACTIONS.TX_TYPE = 'PAYMENT'

GROUP BY TRANSACTIONS.CUST_ID

J'ai besoin de créer des colonnes pour le vieillissement des seaux tels que:

'0 - 30' SOLDE DE CRÉDIT DE LA SOMME

'0 - 30' SOLDE DE CRÉDIT À LA CLIENTÈLE COMPTER

'31 - 60'...

J'allais CAS d'utilisation des déclarations à l'aide de la fonction DATEDIFF entre le max(TRANSACTIONS.POST_DATE) et "hier" - DATEADD(dd,-1,getdate()) pour créer les seaux.

Cependant, ne serait-il pas plus efficace de faire cela à l'aide de variables ou d'une procédure stockée à obtenir de séparer les clients sur la base de la dernière date de paiement avant d'effectuer le seau somme et le nombre des calculs?

Des idées sur la façon de le faire avec précision et de manière efficace? Jusqu'à présent, j'ai été ramasser les clients avec des soldes de crédit avec leur dernière date de paiement d'une simple requête, puis la création du vieillissement des seaux moi-même à l'aide d'Excel.

InformationsquelleAutor texas_mike81 | 2012-07-12
  1. 2

    Votre approche est la bonne approche. Je ne suis pas sûr de savoir pourquoi vous pensez faire quelque chose dans une procédure stockée qui serait plus efficace que de le faire dans une requête.

    Je pense que vous voulez une requête à quelque chose comme:

    select (case when t.DaysAgo between 0 and 30 then '0-30'
             when t.DaysAgo between 31 and 60 then '31-60'
             else 'OLD'
        end),
       <whatever you want here>
from (SELECT ACCOUNT.CUST_ID, sum(ACCOUNT.BALANCE) as balance
      FROM ACCOUNT
      GROUP BY ACCOUNT.CUST_ID
     ) a left outer join
     (SELECT TRANSACTIONS.CUST_ID, MAX(TRANSACTIONS.POST_DATE) as LastPaymentDate,
             datediff(d, X(TRANSACTIONS.POST_DATE), getdate()) as DaysAgo, 
      FROM TRANSACTIONS
      WHERE TRANSACTIONS.TX_TYPE = 'PAYMENT'
      GROUP BY TRANSACTIONS.CUST_ID
     ) t
     on a.cust_id = t.cust_id 
group by  (case when t.DaysAgo between 0 and 30 then '0-30'
                when t.DaysAgo between 31 and 60 then '31-60'
                else 'OLD'
           end)

    En général, vous devez laisser le moteur SQL optimiser la requête. Il est généralement (mais pas toujours!) va faire un bon travail, vous permettant de penser ce que vous voulez accomplir.

    Vous avez de la logique supplémentaire pour exclure certains clients et apporter dans d'autres domaines.

    • Je vous remercie, monsieur. Qui a très bien fonctionné.
    • Je publie cette question stackoverflow.com/questions/11592880/sql-aging-report qui est similaire de cette réponse, mais mon problème est que je veux le faire mais avec 1 seule table. J'espère que vous pourrez m'aider. Merci
    InformationsquelleAutor Gordon Linoff
  2. 1

    J'ai besoin de précisions sur une chose.
    Si un client peut avoir plus d'un compte, et si un paiement peut être posté sur le mauvais compte, comment gérez-vous cela?

    Sens, si un client possède plus d'un compte, comment déterminez-vous un paiement est posté dans le mauvais compte. Signifie-t-il, même si un client possède plus d'un compte, le client a toujours la même CustID pour différents comptes?

    Parce que si le CustID est différent pour chaque compte, je crois sincèrement qu'il n'y a pas moyen de gérer correctement plutôt que d'utiliser l'ancienne façon dans Excel que vous utilisez actuellement.

    Grâce

    • Le client a le même ID de client pour plusieurs comptes. Lorsque les paiements sont appliquées au mauvais compte, ils sont presque toujours appliqué à l'un des clients d'autres comptes. Donc, en prenant la somme de tous les comptes clients s'assure que seuls les clients avec de vraies soldes négatifs sont sélectionnés.
    InformationsquelleAutor Ragno Croft
  3. 0

    Intéressant!.. J'ai écrit un prêteur sur gages application, où nous prenons de l'âge des pions sur base de la dernière date de paiement d'intérêts, ou en l'absence d'un intérêt pymt, pawn_date. Parfois, des clients, une baisse de 2 mois de retard sur les paiements d'intérêts, mais seulement payer 1 mois d'intérêt pour éviter de perdre le pion si elles vont de 90 jours ou plus sans intérêt pymt ou à l'échange du pion. Par conséquent, nous ne (aujourd'hui - last_pymt_date) pour afficher le nombre de jours écoulés depuis la dernière int pymt ou pion date.

    Chaque client peut avoir plusieurs pions, donc une fiche client se joint à de nombreux pion enregistrements de détail. Ce est la bonne façon pour l'affichage des paiements de vos clients, vous trouver un pion des dossiers, mise à jour avec pymt, puis vous pouvez interroger chaque clients des pions pour obtenir un montant total dû pour chaque client.

    InformationsquelleAutor Frank R.