Düzenleyici Raporlama — Aynı Raporu İki Kez Bastık, Neden Farklı Çıktı?

Eylül’de sınıfın fotoğrafını çektin. Ekimde biri “eylül fotoğrafını” istedi. Bugünkü sınıfın yeni bir fotoğrafını çekip vermek, istenen fotoğraf değildir.

Rapor bir fotoğraftır

Düzenleyici raporlar belli bir tarihin durumunu anlatır: “30 Eylül itibarıyla müşteri pozisyonları”. Rapor gönderildikten sonra o tarihe ait bir kayıt olur ve aylar sonra yeniden istenebilir.

Rapor şablonu, örneğin bir JasperReports şablonu, aynı kalabilir. Ama şablon bugünkü tabloyu okuyorsa, 30 Eylül’den sonraki her işlem de rapora girer.

İki tarih: geçerli olduğu ve bilindiği

Bir kaydın iki tarihi vardır. Biri, bilginin geçerli olduğu tarihtir: “30 Eylül’deki pozisyon”. Öteki, bu bilginin sisteme kaydedildiği tarihtir: “1 Ekim’de böyle biliyorduk”.

Her iki tarihi de tutan veriye çift zamanlı?Terimin tanımını aççift zamanlı veriHer kaydın iki tarihini tutan veri: bilginin geçerli olduğu tarih ve sisteme kaydedildiği tarih. Geçmişin hem doğrusunu hem o an bilineni gösterebilir.Sözlükte gör → veri denir.

İki tarihi de sabitleyen rapor yeniden üretilebilir?Terimin tanımını açyeniden üretilebilir raporKaç kez üretilirse üretilsin aynı çıkan rapor. Verinin geçerli olduğu ve bilindiği tarihi, şablon sürümünü sabitler.Sözlükte gör →: kaç kez basılırsa basılsın aynı çıkar. Bugün bilinen doğruyu görmek istersen, geçerli tarihi sabit tutup bilinme tarihini bugüne çekersin.

Düzeltme bir ektir

Gönderilmiş bir raporda hata bulunursa, eski kayıt silinmez ve üzerine yazılmaz. Düzeltme kendi tarihiyle yeni bir kayıt olarak eklenir; eski ve yeni değer yan yana durur.

Düzenleyiciye de düzeltilmiş rapor ayrıca bildirilir. Böylece “ne gönderdik, ne zaman neyi öğrendik, ne düzelttik” sorularının her birinin bir cevabı olur.

Kendin gör

1. Varsayılanla oynat. Yeniden basım bugünkü tabloyu okudu: 1.500 hisse, 5 Ekim’deki alım da içinde.
2. “1 Ekim’de bilindiği hâliyle”yi seç. 1.000 hisse: gönderilenle birebir aynı.
3. “Bugün bilindiği hâliyle”yi seç. 1.200 hisse: fark, 3 Ekim’deki düzeltmeyle açıklanıyor.

Tuzaklar

Yalnızca PDF saklamak. Gönderilen PDF’yi saklamak iyidir, ama yetmez. Sorulduğunda o sayıların hangi kayıtlardan geldiğini gösterebilmek için verinin o anki hâli de saklanmalıdır.

Üzerine yazan güncelleme. Pozisyon tablosu UPDATE ile güncelleniyorsa, eski değer kaybolur ve geçmiş yeniden üretilemez. Değişiklikleri yeni satırlar olarak ekle.

Şablon sürümü. Rapor şablonu da zamanla değişir. Hangi raporun hangi şablon sürümüyle üretildiği de kaydedilmeli.

Aşağıda çift zamanlı bir pozisyon tablosu ve onu belli bir tarihte, belli bir bilgiyle okuyan rapor sorgusu var.

1
-- One row per change. A correction adds a row; nothing is updated in place.
2
CREATE TABLE position_history (
3
    account_id   VARCHAR(20)   NOT NULL,
4
    isin         CHAR(12)      NOT NULL,
5
    valid_date   DATE          NOT NULL,   -- the day this quantity was true
6
    recorded_at  DATETIME2     NOT NULL,   -- when we learned it
7
    quantity     BIGINT        NOT NULL,
8
    reason       VARCHAR(200)  NULL,       -- e.g. 'missed trade found'
9
    CONSTRAINT pk_position_history PRIMARY KEY (account_id, isin, valid_date, recorded_at)
10
);

1
-- Positions valid on :validDate, as they were known at :knownAt.
2
SELECT account_id, isin, quantity
3
FROM (
4
    SELECT h.*,
5
           ROW_NUMBER() OVER (PARTITION BY account_id, isin
6
                              ORDER BY recorded_at DESC) AS rn
7
    FROM   position_history h
8
    WHERE  h.valid_date  = :validDate
9
      AND  h.recorded_at <= :knownAt
10
) latest
11
WHERE rn = 1;

1
package com.bank.reporting;
2

3
import java.time.Instant;
4
import java.time.LocalDate;
5

6
/** Stored with every generated report, so it can be produced again exactly. */
7
public record ReportRun(
8
        String reportCode,
9
        LocalDate validDate,
10
        Instant knownAt,
11
        String templateVersion,
12
        String fileSha256) {}

Kendini sına