Planification des éléments de reporting

Cette planification ne couvre que les aventures 1 et 2. Le reporting pour les stations de chargement sera à ajouter ici.

Voici un diagramme qui sert de référence pour l'architecture des rapports :

Explication des termes de reporting

Le reporting, c'est compliqué. Beaucoup de concepts seront énumérés ici, avant une bonne explication de ce dont on a besoin pour le reporting dans l'application.

• Event : Événement se produisant dans l'application. Dans notre cas, on ne couvre que les paiements de factures et les entrées à la guérite.
• Report : Rapport d'événements sur un temps donnés, avec plusieurs paramètres possibles.
• Period : Période de temps couverte par des données.
• Scope : Regroupement temporel de données pour une Period.
• Metric : Valeur calculée sur une période.
• Dimension : Découpage de périodes selon des critères.
  • Si on a deux dimensions de 2 valeurs possibles chacune, voici le nombre de découpage par période notre rapport comportera :
    • Si on utilise aucune dimension : aucun découpage, périodes sans dimension (2^0 valeur)
    • Si on utilise une dimension : un découpage, donc chaque période a deux sections (2^1 valeurs)
    • Si on utilise deux dimensions : deux découpages, donc chaque période a quatre sections (2^2 valeurs)
  • Si on a deux dimension de 2 et 3 valeurs possibles respectivement s et que notre rapport utilise les deux, chaque période a six sections.
• Data : Données concrètes pour une période, métrique ou dimension. Dans notre application, c'est la différence entre la logique de découpage ou de calcul et le résultat.

Projet de référence

Voici deux modules d'un ancien projet qui peut fortement aider

• reports
• time

Plan général

• Périodes
  • None (story 1.5.1)
  • Year (story 1.7)
  • Month (story 1.5.2 + 1.5.3)
• Scopes
  • Yearly (story 1.7)
  • Daily (story 1.5.2 + 1.5.3)
  • Monthly (story 1.5.1)
• Métrique
  • Profits (story 1.7)
  • Gate entries (story 1.5)
• Dimensions
  • Consumption type (story 1.7)
  • Parking area code (story 1.5)
• Filtres (pas un principe de rapport, mais les ReportEvent doivent avoir ça)
  • Report event type
• Fonctions d'agrégats (story 1.5.2)
  • Max(List<ReportPeriod>, ReportMetric) -> Retourne un ReportPeriodData
  • Min(List<ReportPeriod>, ReportMetric) -> Retourne un ReportPeriodData
  • Avg(List<ReportPeriod>, ReportMetric) -> Retourne un ReportMetricData

Les ReportEvent ont ReportEventType, c’est similaire à BillType, mais on ajoute aussi des types pour les gate entries.

Comment on fait le sommaire (story 1.5.2)?

• C’est 3 rapports qu’on fusionne avec un assembleur
• Les trois fonctions d'agrégats listés plus haut permettent cela