Logo Tiger’da Gelişmiş Kontrol Mekanizması: Cari Kart Ödeme Şekli Değişikliğinde Mail Onayı ve Geri Alma Trigger Yapısı

Cari Kartta Yapılan Kritik Değişiklikleri Kontrol Altına Alın

Kurumsal yapılarda bazı alanlar vardır ki, kullanıcı tarafından değiştirilmesi teknik olarak mümkün olsa da, iş etkisi açısından mutlaka kontrol altında tutulmalıdır.
Cari kart üzerindeki ödeme şekli alanı da bunların başında gelir.

Çünkü ödeme planı üzerinde yapılan tek bir değişiklik bile:

  • tahsilat akışını,
  • vade yapısını,
  • risk değerlendirmesini,
  • cari mutabakat süreçlerini,
  • finansal raporlamayı,
  • hatta müşteriyle olan ticari ilişkiyi

doğrudan etkileyebilir.

Bu nedenle burada anlattığım yapı, yalnızca bir SQL trigger değil; aynı zamanda kurum içinde hakimiyet, izlenebilirlik, denetim ve onay kültürü oluşturan gelişmiş bir kontrol mekanizmasıdır.

Bu Yapı Ne Yapar?

Logo Tiger cari kartında ödeme şekli değiştirildiğinde sistem şu süreci işletir:

1. Değişikliği algılar

Kullanıcı cari kart üzerinde ödeme planını değiştirdiği anda trigger devreye girer.

2. Eski ve yeni değeri yakalar

Sistem, eski ödeme planı ile yeni ödeme planını birlikte kayıt altına alır. Ayrıca değişikliği yapan kullanıcı bilgisi de loglanır.

3. Log kaydı oluşturur

Değişiklik bilgisi özel log tablosuna yazılır. Böylece “kim, neyi, ne zaman değiştirdi?” sorusunun net cevabı her zaman elinizde olur.

4. Yöneticiye otomatik e-posta gönderir

İlgili yöneticilere, onay bekleyen değişiklik talebi için otomatik bir HTML e-posta gönderilir. Mail içinde değişen cari kart, kullanıcı adı, eski ödeme şekli ve yeni ödeme şekli açıkça gösterilir. Ayrıca doğrudan onay ekranına giden bağlantı da yer alır.

5. Değişikliği anında geri alır

En kritik nokta budur: Kullanıcının yaptığı değişiklik, sistemde kalıcı hale gelmez. Trigger, onay süreci tamamlanana kadar gerçek cari kart üzerindeki ödeme planını eski haline döndürür. Yani kullanıcı değişikliği yapmış gibi görünse de, yönetici onay vermeden sistemde fiilen bir değişiklik oluşmaz.

Bu Neden Çok Güçlü Bir Yapı?

Bu yaklaşım, klasik “değişsin sonra kontrol ederiz” mantığından tamamen farklıdır.

Buradaki anlayış şudur:

Kritik veri önce kontrol edilir, sonra sisteme işlenir.

Bu da şirket içinde şu avantajları sağlar:

  • Yetkisiz veya hatalı değişikliklerin canlı veriye yansımasını engeller
  • Finansal süreçlerde disiplin oluşturur
  • Kullanıcı hareketlerini görünür hale getirir
  • Onay kültürünü sistematik hale getirir
  • Denetim ve iç kontrol süreçlerini güçlendirir
  • Veri bütünlüğünü korur

Bu nedenle bu yapı yalnızca teknik bir çözüm değil, aynı zamanda kurumsal yönetim refleksi olan bir yaklaşımdır.

Gelişmiş Hakimiyet ve Kontrol Ne Demektir?

Bir şirkette veri üzerinde gerçek kontrol, yalnızca yetki vermekle sağlanmaz.
Asıl kontrol şunlarla sağlanır:

  • Kritik değişiklikleri anında fark etmek
  • Kimin değiştirdiğini görmek
  • Eski ve yeni değerleri karşılaştırmak
  • Yöneticiye otomatik bildirmek
  • Onay gelmeden veriyi değiştirmemek
  • İstenirse tüm süreci raporlayabilmek

İşte bu trigger yapısı tam olarak bunu yapar.

Bu nedenle burada kurulan sistem, basit bir log mekanizması değil;
kurumun veriye hakim olmasını sağlayan yüksek seviye bir kontrol altyapısıdır.

Sadece Cari Kart İçin mi Kullanılır?

Hayır. Tam tersine, bu mantık çok daha geniş bir yapının başlangıcıdır.

Bu kontrol modeli yalnızca cari karttaki ödeme şekli değişikliği için değil, aşağıdaki birçok kritik alana da uygulanabilir:

  • Cari kart silme veya güncelleme işlemleri
  • Stok kartı kritik alan değişiklikleri
  • Fiyat listesi güncellemeleri
  • Muhasebe bağlantı kodu değişiklikleri
  • Banka kartı bilgilerinin güncellenmesi
  • Hizmet kartlarında hesap bağlantılarının değiştirilmesi
  • Onaylı belge alanlarının değiştirilmesi
  • Kullanıcıların yaptığı silme işlemleri
  • Finansal parametre değişiklikleri
  • Risk veya limit alanlarının değiştirilmesi

Yani burada anlatılan mimari, tek bir örnekten ibaret değildir.
Bu yapı, istenirse şirket genelinde birçok modüle yayılarak merkezi bir onay ve kontrol sistemi haline getirilebilir.

Neden Özellikle Cari Kartta Ödeme Şekli Kritik?

Cari kart üzerindeki ödeme şekli alanı çoğu firmada yalnızca operasyonel bir detay gibi görünür.
Oysa pratikte bu alan:

  • müşterinin tahsilat modelini,
  • vade beklentisini,
  • finansal riskini,
  • ödeme takibini,
  • raporlamayı

doğrudan etkiler.

Yanlışlıkla ya da onaysız yapılan bir değişiklik:

  • tahsilat ekibini yanıltabilir
  • cari yaşlandırma raporlarını bozabilir
  • planlanan ödeme akışını değiştirebilir
  • mutabakat süreçlerinde hata yaratabilir

Bu nedenle ödeme planı değişikliği gibi alanların kontrolsüz bırakılması, ileride çok daha büyük operasyonel sorunlara dönüşebilir.

Mail Bildirimi Neden Önemli?

Trigger’ın güçlü taraflarından biri de yöneticiyi pasif bekleyici konumda bırakmamasıdır.
Sistem değişikliği algıladığı anda yöneticiyi otomatik bilgilendirir. Mail içinde:

  • değişiklik zamanı,
  • ilgili cari kart,
  • eski ödeme şekli,
  • yeni ödeme şekli,
  • işlemi yapan kullanıcı,
  • onay ekranı bağlantısı

yer aldığı için süreç çok hızlı şekilde yönetilebilir.

Böylece kontrol süreci manuel takibe bağlı kalmaz. Sistem kendi kendine alarm üretir.

Onay Süreci Nasıl Tamamlanır?

Bu trigger tarafı, değişikliğin kontrol edilmesini, kayıt altına alınmasını ve geçici olarak geri alınmasını sağlar.
Yönetici onay ekranı ve onay sonrası gerçek karta yeni değerin işlenmesi ise ikinci aşamadır.

Bu ikinci aşama daha sonra VB.NET tarafında ele alınabilir.
Yani mimari iki parçalı ilerler:

Aşama 1 – SQL tarafı

  • Değişikliği algıla
  • Logla
  • Mail gönder
  • Kartı eski haline döndür

Aşama 2 – Uygulama tarafı (VB.NET)

  • Yönetici onay ekranı
  • Talep listesini gösterme
  • Onay / red işlemi
  • Onay sonrası kartı güncelleme
  • Süreç raporlama ve geçmiş izleme

Bu ayrım son derece doğrudur. Çünkü SQL tarafı güvenliği ve veri kontrolünü sağlar; uygulama tarafı ise kullanıcı deneyimini ve yönetsel akışı yönetir.

Denetim Açısından Sağladığı Güç

Bu tarz yapılar özellikle iç denetim, bağımsız denetim ve kurumsal yönetim bakış açısından çok değerlidir.
Çünkü sistem şunu ispatlayabilir:

  • Kritik değişiklikler kontrolsüz yapılmamıştır
  • Tüm değişiklikler kayıt altına alınmıştır
  • Onaysız değişiklikler fiilen sisteme işlenmemiştir
  • Süreç e-posta ve log ile izlenebilir durumdadır
  • Kim hangi değişikliği yaptı açıkça bellidir

Bu da şirketin veri yönetim kalitesini ciddi biçimde yukarı taşır.

Bu Yapının Kurumsal Mesajı Nedir?

Bu sistemin verdiği mesaj çok nettir:

“Bizde kritik veriler serbestçe değiştirilmez. İzlenir, kontrol edilir, onaylanır ve ancak ondan sonra uygulanır.”

İşte bu yaklaşım, sıradan bir ERP kullanımı değil;
gelişmiş süreç hakimiyeti, kontrol disiplini ve profesyonel veri yönetimi demektir.

Teknik Olarak Bu Trigger’da Neler Var?

Gönderdiğin yapıda teknik olarak şu yetenekler bulunuyor:

  • PAYMENTREF alanındaki değişikliği tespit etme
  • inserted ve deleted üzerinden eski / yeni değeri karşılaştırma
  • Eski ve yeni ödeme planı kodlarını çözme
  • Değişikliği yapan kullanıcıyı bulma
  • Log tablosuna detaylı kayıt yazma
  • HTML içerikli otomatik e-posta gönderme
  • Onay ekranına yönlendiren link üretme
  • Trigger içinde geri yazma sırasında sonsuz döngüyü önlemek için SESSION_CONTEXT kullanma
  • Onay gelene kadar kartı eski değerine döndürme

Bu da çözümün yalnızca işlevsel değil, aynı zamanda teknik olarak da olgun bir yapıda olduğunu gösterir.

Kimler İçin Uygundur?

Bu yaklaşım özellikle şu yapılarda çok değerlidir:

  • Finansal disiplini yüksek firmalar
  • Yetki ve onay yapısı güçlü olan kurumlar
  • ERP üzerinde kritik veri değişikliklerini kontrol etmek isteyen şirketler
  • Denetim hassasiyeti olan organizasyonlar
  • Çok kullanıcılı ve çok modüllü Logo Tiger yapıları

 

USE [melihdb]
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER TRIGGER [dbo].[TRG_LG_002_CLCARD_PAYMENTREF_CHANGE]
ON [dbo].[LG_002_CLCARD]
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;

— Trigger içi sistemsel geri yazma ise çık
IF TRY_CAST(SESSION_CONTEXT(N’ODP_SKIP_TRIGGER’) AS INT) = 1
RETURN;

IF NOT UPDATE(PAYMENTREF)
RETURN;

DECLARE @Degisenler TABLE
(
CLCARD_LOGICALREF INT,
CODE VARCHAR(50),
DEFINITION_ VARCHAR(200),
MODIFIEDBY_NR INT,
MODIFIEDBY_NAME VARCHAR(100),
ESKI_PAYMENTREF INT,
YENI_PAYMENTREF INT,
ESKI_ODEME VARCHAR(100),
YENI_ODEME VARCHAR(100)
);

INSERT INTO @Degisenler
(
CLCARD_LOGICALREF,
CODE,
DEFINITION_,
MODIFIEDBY_NR,
MODIFIEDBY_NAME,
ESKI_PAYMENTREF,
YENI_PAYMENTREF,
ESKI_ODEME,
YENI_ODEME
)
SELECT
i.LOGICALREF,
i.CODE,
i.DEFINITION_,
i.CAPIBLOCK_MODIFIEDBY,
U.NAME AS MODIFIEDBY_NAME,
d.PAYMENTREF AS ESKI_PAYMENTREF,
i.PAYMENTREF AS YENI_PAYMENTREF,
pOld.CODE AS ESKI_ODEME,
pNew.CODE AS YENI_ODEME
FROM inserted i
INNER JOIN deleted d
ON i.LOGICALREF = d.LOGICALREF
LEFT JOIN dbo.LG_002_PAYPLANS pOld
ON pOld.LOGICALREF = d.PAYMENTREF
LEFT JOIN dbo.LG_002_PAYPLANS pNew
ON pNew.LOGICALREF = i.PAYMENTREF
LEFT JOIN dbo.L_CAPIUSER U
ON U.NR = i.CAPIBLOCK_MODIFIEDBY
WHERE ISNULL(i.PAYMENTREF, -1) <> ISNULL(d.PAYMENTREF, -1)
AND ISNULL(i.CODE, ”) LIKE ‘120.03%’;

IF NOT EXISTS (SELECT 1 FROM @Degisenler)
RETURN;

INSERT INTO dbo.CLCARD_PAYMENTREF_LOG
(
LOG_DATE,
SQL_USER,
CLCARD_LOGICALREF,
CODE,
DEFINITION_,
MODIFIEDBY_NR,
MODIFIEDBY_NAME,
ESKI_PAYMENTREF,
YENI_PAYMENTREF,
ESKI_ODEME,
YENI_ODEME
)
SELECT
GETDATE(),
SUSER_SNAME(),
CLCARD_LOGICALREF,
CODE,
DEFINITION_,
MODIFIEDBY_NR,
MODIFIEDBY_NAME,
ESKI_PAYMENTREF,
YENI_PAYMENTREF,
ESKI_ODEME,
YENI_ODEME
FROM @Degisenler;

DECLARE @subject NVARCHAR(300);
DECLARE @body NVARCHAR(MAX);
DECLARE @link NVARCHAR(500);

SET @subject = N’Onayını bekleyen ödeme talepleri var’;
SET @link = N’https://melihsamur.com.tr/Default.aspx?tab=odemeplan’;

SET @body =
N'<html>
<body style=”font-family:Arial,Helvetica,sans-serif; font-size:13px; color:#222;”>
<h3>Onayını bekleyen ödeme talepleri var, lütfen onaylayın.</h3>
<p><b>Tarih:</b> ‘ + CONVERT(NVARCHAR(19), GETDATE(), 120) + N'</p>

<p style=”margin:14px 0;”>
<a href=”‘ + @link + N'”
style=”display:inline-block; padding:10px 16px; background:#0d6efd; color:#ffffff; text-decoration:none; border-radius:6px; font-weight:bold;”>
Onay ekranına git
</a>
</p>

<p>
Alternatif link:
<br/>
<a href=”‘ + @link + N'”>’ + @link + N'</a>
</p>

<table border=”1″ cellpadding=”6″ cellspacing=”0″ style=”border-collapse:collapse; margin-top:14px;”>
<tr style=”background-color:#f2f2f2;”>
<th>LOGICALREF</th>
<th>CODE</th>
<th>DEFINITION_</th>
<th>KULLANICI</th>
<th>ESKI_ODEME</th>
<th>YENI_ODEME</th>
</tr>’ +

CAST((
SELECT
td = ISNULL(CAST(CLCARD_LOGICALREF AS VARCHAR(20)), ”), ”,
td = ISNULL(CODE, ”), ”,
td = ISNULL(DEFINITION_, ”), ”,
td = ISNULL(MODIFIEDBY_NAME, ”), ”,
td = ISNULL(ESKI_ODEME, ”), ”,
td = ISNULL(YENI_ODEME, ”)
FROM @Degisenler
FOR XML PATH(‘tr’), TYPE
) AS NVARCHAR(MAX))

+ N'</table>
</body>
</html>’;

EXEC msdb.dbo.sp_send_dbmail
@profile_name = ‘Rapor’,
@recipients = ‘melih@melihsamur.com.tr’,
@subject = @subject,
@body = @body,
@body_format = ‘HTML’;

—————————————————————-
— KULLANICI TALEBİ ONAYLANANA KADAR GERÇEK KARTI ESKİ HALİNE AL
—————————————————————-
EXEC sys.sp_set_session_context @key = N’ODP_SKIP_TRIGGER’, @value = 1;

UPDATE C
SET C.PAYMENTREF = D.ESKI_PAYMENTREF
FROM dbo.LG_002_CLCARD C
INNER JOIN @Degisenler D
ON D.CLCARD_LOGICALREF = C.LOGICALREF;

EXEC sys.sp_set_session_context @key = N’ODP_SKIP_TRIGGER’, @value = 0;
END

 

Özel Geliştirme Olarak Neler Yapılabilir?

Bu mimariyi daha da ileri taşıyabiliriz:

  • Yönetici onay ekranı geliştirme
  • Çok seviyeli onay mekanizması
  • Red nedeninin kaydı
  • Yetki bazlı onay akışı
  • Mobil onay bağlantısı
  • Diğer kart ve fiş türlerine yaygınlaştırma
  • Silme işlemleri için ek güvenlik
  • Dashboard üzerinde bekleyen talepler listesi
  • Onay geçmişi raporları
  • Mail yerine Teams / SMS / WhatsApp bildirim entegrasyonları

Sonuç

Cari kartta ödeme şekli değişikliğini izleyen ve yönetici onayı gelmeden gerçek veriyi değiştirmeyen bu yapı, yalnızca bir trigger örneği değildir.

Bu yapı:

  • gelişmiş kontrol,
  • güçlü denetim izi,
  • kurumsal veri hakimiyeti,
  • onaylı süreç yönetimi,
  • yüksek güvenilirlik

anlamına gelir.

Ve en önemlisi, bu mantık yalnızca cari kartta değil, şirket içinde kritik görülen tüm alanlara uygulanabilecek kadar güçlü bir mimari temel sunar.

İletişim

Logo Tiger üzerinde bu tür:

  • trigger tabanlı kontrol mekanizmaları,
  • onay süreçleri,
  • log sistemleri,
  • yönetici bildirimleri,
  • SQL + VB.NET entegre akışlar

kurmak istersen benimle iletişime geçebilirsin.

İletişim Sayfası
https://melihsamur.com.tr/iletisim/

WhatsApp
https://wa.me/905415582843

E-posta
melih@melihsamur.com.tr