---
title: "Mikro ERP Belge Numarasıyla Cari Hareket Bulma: Doğru Alan Hangisi?"
description: "Mikro'da e-Fatura numarası veya belge ile arama yapmanın incelikleri. Neden e-arşiv numaraları bulunamaz? LIKE tuzağı ve 30 saniyelik DB scan'leri..."
date: 2026-04-14
category: mikro-erp
tags: ["mikro-erp", "sql-server", "cari-hesap", "belge-no", "e-fatura", "optimizasyon", "astaflow"]
url: https://mikroerp.dev/blog/mikro-erp-belge-no-cari-hareket-bulma-sql/
---

## İş Problemi: "Şu Fatura Nerede Kayboldu?"

Muhasebe birimlerinin gününün yarısı evrak aramakla geçer. "E-Fatura numaram GIB2024000142... ama sistemde bulamıyorum!"
Mikro'da fiş ve belge numaralarıyla arama yapmak, SQL tarafında en çok hata yapılan, sistemi en çok donduran işlemlerin başında gelir. Bunun **üç büyük sebebi vardır:**

1. **Mimari Parçalanmışlık:** Kağıt matbaa numarası (`cha_belge_no`), e-fatura numarası (`cha_ebelgeno`), Mikro'nun kendi iç sırası (`cha_evrakno`) farklı farklı sütunlarda tutulur. Yanlış sütunda ararsınız bulamazsınız.
2. **e-Belge Dağınıklığı:** e-Fatura ile e-Arşiv faturası aynı formatta gibi görünse de (ABC2024...), birbirlerinden ayrı kolonlara yazılma ihtimalleri vardır.
3. **Performans Çöküntüsü (The LIKE Trap):** Başı sönük `LIKE '%ABC...'` tipi aramalar, SQL Server'ı felç eder (Tam tablo taraması - Index Scan).

## 4 Farklı Numara Alanının Anatomisi

SSMS'i açmadan önce aradığınız evrakın karakteristiğini bilmelisiniz:

| Alan Sütunu | Gerçek Hayattaki Karşılığı | Örnek Yapı |
|------|----------|-------|
| `cha_belge_no` | Geleneksel fiş, elle yazılan irsaliye/matbaa numarası | `14562` veya `FTR-421` |
| `cha_evrakno_seri` | Mikro'da seriye bağlanan evrakların Prefix'i | `A`, `FTR` (Kullanıcı seçer) |
| `cha_evrakno_sira` | Evrak serisinin sadece sayısal iç sayacı | `4521` (Int'tir) |
| `cha_ebelgeno_seri` + `sira` | GIB e-Dönüşüm faturalarının resmi eşleşmesi! | `GIB` + `2024000451` |

## Somut Hata: Arama Kilitlenmesi

> **Kötü SQL Örneği (Sistemi dondurur):**
> `SELECT * FROM CARI_HESAP_HAREKETLERI WHERE cha_belge_no LIKE '%451%'`
> Etki: Bu sorgu, 5 milyon satırlı bir cari tablosunda CPU'yu %100'e çıkarır, diğer kullanıcıların fatura kaydetmesini kilitler.

## Çözüm: Tüm Olasılıkları Taramak ve Optimizasyon

İşte muhasebe personelinin girdiği *herhangi bir* metin parçasını, sistemi kilitlemeden, doğru yerlerde arayan profesyonel AstaFlow SQL'i:

```sql
DECLARE @ArananNo NVARCHAR(50) = '1452'; -- Arama parametreniz

SELECT 
    C.cha_kod                                      AS [Cari Kodu],
    CH.cari_unvan1                                 AS [Müşteri / Tedarikçi],
    CONVERT(VARCHAR(10), C.cha_tarihi, 104)        AS [Tarih],
    
    -- Tüm olası evrak nolarını tekilleştirilmiş mantıkla sun
    ISNULL(NULLIF(C.cha_belge_no, ''), 'A-Yok')    AS [Fiziksel Belge No],
    C.cha_evrakno_seri + '-' + CAST(C.cha_evrakno_sira AS VARCHAR) AS [Mikro Evrak No],
    ISNULL(C.cha_ebelgeno_seri, '') + CAST(ISNULL(C.cha_ebelgeno_sira, '') AS VARCHAR) AS [e-Fatura No],
    
    -- İnsansı Format
    CASE C.cha_evrak_tip
        WHEN 0  THEN 'Alış Faturası'
        WHEN 63 THEN 'Satış Faturası'
        WHEN 1  THEN 'Tahsilat Makbuzu'
        WHEN 64 THEN 'Tediye Makbuzu'
        WHEN 34 THEN 'Banka Havalesi (Gelen)'
        ELSE 'Tip Kodu: ' + CAST(C.cha_evrak_tip AS VARCHAR)
    END                                            AS [Evrak Tipi],
    
    -- Tutar
    CASE WHEN C.cha_tip = 0 THEN C.cha_meblag ELSE -C.cha_meblag END AS [Tutar (Net)],
    C.cha_aciklama                                 AS [Sistem Açıklaması]
    
FROM CARI_HESAP_HAREKETLERI C WITH (NOLOCK)
LEFT JOIN CARI_HESAPLAR CH WITH (NOLOCK) ON C.cha_kod = CH.cari_kod

WHERE C.cha_iptal = 0
  AND (
       -- Doğru LIKE yapısı: Sadece belge numarası sonlarında serbestlik bırak!
       -- Başında wildcard '%' olursa SQL Server INDEX kullanamaz!
       C.cha_belge_no LIKE @ArananNo + '%' 
       
       OR CAST(C.cha_evrakno_sira AS VARCHAR) = @ArananNo 
       
       -- E-fatura numarası taraması
       OR CAST(C.cha_ebelgeno_sira AS VARCHAR) = @ArananNo
  )
  -- Performans koruması için sadece son 2 yıla bak:
  AND C.cha_tarihi >= DATEADD(YEAR, -2, GETDATE())
ORDER BY C.cha_tarihi DESC;
```

## Performans / Ölçekleme Testi 

Bu sorguda yapılan **iki büyük mühendislik dokunuşu**, AstaFlow modüllerinde "Belge Arama" işlevini 30 saniyeden **0.1 saniyeye** indirmiştir:
1. `LIKE '%451%'` yerine `LIKE '451%'` kullanıldı. Baştaki joker karakter kalktığında, `cha_belge_no` üzerinde tanımlı yapı B-Tree index yapısından faydalanabilir (*Index Seek*).
2. Tarih filtresi (`DATEADD(YEAR, -2)`) zorunlu kılındı. Bu, devasa bir veri tabanında taranacak veri satırlarını %80 azaltır. Muhasebenin %99 oranında 3 yıl önceki evrak numarası krizine düştüğü görülmemiştir.

## Edge Cases (İstisnai Durumlar)

1. **Açıklama Alanına Gizlenen Numaralar:** Sütun yapısını bilmeyen bazı eski sekreter veya ön muhasebe personelleri, EFT makbuzu dekont numaralarını inatla `cha_aciklama` (Açıklama) alanına yazarlar. Eğer numaranız ısrarla çıkmıyorsa sorgunun `OR` bölümüne mecburen `C.cha_aciklama LIKE '%' + @ArananNo + '%'` eklemelisiniz. Bu işlemi yaparken veritabanınızın yorulacağını belirtin.
2. **Aynı Belge No'nun Birden Fazla Satırda Çıkması:** Bir toptan satış faturası kestiğinizde, irsaliye bedelleri, iskontolar veya farklı KDV matrahları nedeniyle Mikro aynı fişi veritabanına 3 ayrı `cha_satir_no` ile bölebilir. Sonucun 3 satır çıkması hatalı değildir. Ekrana verirken tutarları Aggregate (`SUM`) yapmayı düşünebilirsiniz.

## Bu Bilgiyi Nereden Biliyoruz? (Kaynaklar)

*   **AstaFlow Case Study:** [Müşteri 360 Ekranı ve Belge Bulma Altyapısı](/case-study/)
*   **Mikro ERP DB API:** [CARI_HESAP_HAREKETLERI (Tüm Tip Kodları referansı)](https://apidocs.mikro.com.tr/tablo-alan-adlari/cari_hesap_hareketleri)
*   **İlgili Çözüm:** [Kapanmamış Cari Hareketleri İzole Etme](/blog/mikro-erp-kapanmamis-cari-hareket-sql/)