Operasyon ekiplerinin uyuşmazlıkları tespit etmesini, kanıtları incelemesini, kontrollü düzeltmeler uygulamasını ve temiz bir denetim izi tutmasını sağlayan mutabakat ekranı UI desenleri.
Bir mutabakat ekranı pratik bir soruya cevap vermek için vardır: iki kaynak uyuşmadığında, hangi gerçeği raporlayacağız ve üzerinde işleyeceğiz?
Genellikle bir "kaynak"ı (banka beslemesi, ödeme sağlayıcı, POS, alt-defter, depo sistemi) "kayıt defterinize" (çoğunlukla genel muhasebe) karşı karşılaştırırsınız. Ekran yalnızca bir karşılaştırma görünümü değildir. Kararların verildiği ve kaydedildiği yerdir.
Uyumsuzluklar sıkıcı nedenlerle olur ve bu iyi haber: UI bunları öngörebilir. Gecikmeli kayıtlar, eksik kalemler, çoğaltmalar, eşleme problemleri (yanlış hesap, müşteri, para birimi) ve bir taraftaki bir kaydın diğer tarafta birkaç kayda denk geldiği kısmi eşleşmeler göreceksiniz.
İyi tasarlanmış bir mutabakat ekranında kullanıcının işi, her istisnayı "belirsiz" halinden "çözüldü"ye tahmin etmeden taşımaktır. Bu iş genellikle birkaç tekrarlanabilir adıma ayrılır:
En büyük risk yanlış eşleşme değildir. Sessiz değişikliktir. Ekran değerleri kim değiştirdi, ne değişti ve hangi kayıtlar etkilendiğini göstermeden düzenleme yapmaya izin veriyorsa güveni kaybedersiniz ve denetimler sırasında zaman kaybedersiniz.
Ekranı her çözümün izlenebilir bir sonuç üretmesini sağlayacak şekilde tasarlayın: öncesi/sonrası değerler, bağlı kaynak kayıtlar, zaman damgası, kullanıcı ve neden kodu. Onay gerekiyorsa, UI "onay gerekiyor" durumunu belirgin yapmalı ki işler gri bir alana kaymasın.
Bunu sonradan AppMaster gibi bir araçla inşa ediyorsanız, denetim izini yan not olarak değil birinci sınıf veri modeli olarak ele alın. Gelecek ay sonu kapanışınız size teşekkür edecektir.
Mutabakat ekranı, veriler karışık olsa bile sakin bir kontrol listesi gibi hissettirdiğinde en iyi çalışır. Buna ulaşmanın en kolay yolu net üç parçalı bir düzen: üstte Özet, solda (veya ortada) İş kuyruğu ve sağda Detaylar.
Özet, "yakınız mı?" sorusunun cevabıdır. Her taraf için toplamları gösterin (adet ve tutar), ardından farkı her iki birimde gösterin. İnsanlar bir bakışta 3 kalem mi eksik, 124,18 $ mı yoksa her ikisi mi anlayabilmeli. Mümkünse küçük bir eğilim gösterin: "fark son kayda göre iyileşti" gibi, böylece inceleyenler yaptıkları işin etki yarattığını görür.
İş kuyruğu ölçeğin olduğu yerdir. Arama ve filtreleri her zaman görünür tutun ki kullanıcılar temel işler için ekstra paneller açmak zorunda kalmasın. Durum etiketi (Yeni, İncelemede, Düzeltildi, Onay gerekiyor) olan basit bir satır listesi çoğu zaman yeterlidir.
Birçok mutabakat ekranında kullanılan temiz yapı şöyle olabilir:
Varsayılanı en küçük işe yarar zaman aralığı yapın. Örneğin, kuyruk kısa ve hızlı olsun diye başlangıçta son 7 gün ile başlayın, sonra kullanıcılar tek tıkla tam aya genişletebilsin. Bu gürültüyü azaltır ve yeni inceleyicilerin güven kazanmasına yardımcı olur.
Bunu AppMaster gibi bir araçla inşa ediyorsanız, web ve mobilde düzeni tutarlı tutun: küçük ekranlarda aynı üç bölge üst üste gelsin ki eğitim ve kas hafızası devam etsin.
İyi bir uyumsuzluk görünümü saniyeler içinde üç soruyu cevaplar: ne yanlış, ne kadar kötü ve sonraki adım ne olmalı. Ekran insanları bir farkı anlamak için üç modal açmaya zorluyorsa tereddüt ederler, tahminde bulunurlar veya daha sonra not bırakırlar.
Ürün genelinde küçük, tutarlı bir uyumsuzluk türleri seti kullanarak başlayın. Bu tutarlılık mükemmel ifadelerden daha önemlidir; çünkü inceleyenler kas hafızası geliştirir. Çoğu ekip dört etiketle vakaların %90'ını karşılayabilir: eksik kalem, fazla kalem, tutar farklı, tarih farklı. Türü satırın başına koyun ki insanlar aramasın.
Ciddiyet belirgin ama sakin olmalı. "Yüksek", "Orta", "Düşük" (veya "Kapanışı engelliyor", "İnceleme gerekiyor", "Bilgi için") gibi düz etiketleri tutarlı renkle tercih edin. Rengi bir ipucu olarak kullanın, mesajın yerine değil. Gerçekten kapanışı durduracak vakalar için güçlü kırmızıyı ayırın, diğer her şeyi nötr tutun.
İnceleyenler ayrıca "neden"i bilmek ister, ama iç jargon yerine insan dilinde. Sistem tarafından bulunanı referans veren kısa bir neden satırı gösterin, örneğin "Referans ile eşleşti, tutar farklı" veya "Banka işlemi için defter girişi bulunamadı". Kurallar devreye giriyorsa, yalnızca yardımcı oluyorsa kural adını gösterin ve ana alan farklarını insan ifadeleriyle ekleyin.
Ham ve normalize edilmiş değerleri birlikte görünür tutun. Normalizasyon (yuvarlama, döviz dönüşümü, boşlukların kırpılması, zaman dilimi değişiklikleri) yaygındır ve bunu gizlemek güvensizlik yaratır. Pratik bir düzen, her uyumsuzluk satırının içinde iki sütunlu bir karşılaştırma olabilir:
Bunu AppMaster ile inşa ediyorsanız, uyumsuzluk türünü ve önem düzeyini veri katmanında enum olarak modelleyin, böylece her liste, filtre ve detay paneli uyumsuzluk inceleme iş akışı boyunca tutarlı kalır.
Hacim yüksek olduğunda, mutabakat kuyruğu rapordan çok bir gelen kutusu gibi davranmalı. İnsanlar her satırı bir saniyede anlamalı, sonraki adımı karar verip bağlamı kaybetmeden ilerlemeli.
Önce "nedir"i cevaplayan sütunlarla başlayın, "ne anlama geliyor"dan önce. Mümkünse ilk ekranda esasları tutun ve detayları yan panelde toplayın.
Sıralama inceleyenlerin düşündüğü şekilde olmalı. İyi bir varsayılan "en büyük delta önce"dir çünkü en büyük riski hızlıca ortaya çıkarır. En yeni, en eski bekleyen ve "son dokunulan" için hızlı geçişler ekleyin ki devre teslimleri kolay olsun.
Kaydedilmiş görünümler kuyruğun roller arasında ölçeklenmesini sağlar. Bir analist "açık + otomatik eşleşme başarısız" isteyebilir, bir onaylayıcı "sadece onay bekleyen" isteyebilir ve bir denetçi "dönemde el ile düzenlenen" görmek isteyebilir. Görünümleri belirgin ve sade dilde adlandırın ki insanlar kendi tablolarını oluşturmaya çalışmasın.
Toplu seçim büyük zaman kazandırabilir, ama yalnızca koruyucularla. Limitleri net gösterin (örneğin maksimum 50 öğe), hangi alanların değişeceğini gösterin ve geri dönüşü olmayan işlemler için uyarı verin. Basit bir önizleme adımı büyük hataları önler.
İlerleme göstergeleri takımı hizalar. Durumlara göre sayıları üstte gösterin ve bunları tıklanabilir filtreler yapın. Daha da iyisi, sahipliği gösterin (atanmamış vs bana atanmış) ki işler çift yapılmasın.
Bu mutabakat ekranı desenleri bir görsel araçla (AppMaster gibi) inşa etmek için basittir: bir kuyruk tablosu, role dayalı kaydedilmiş filtreler ve durum etiketleri finans ekiplerine hız sağlar, kontrolü kaybettirmez.
İyi bir mutabakat akışı gösterişli görsellerden çok insanların ekranda dolaşmasını engellemekle ilgilidir. Mutabakat ekranı desenlerinin hedefi basittir: inceleyiciyi "Ne değişti?"den "Bununla ne yaptık?"a bağlamı kaybetmeden yönlendirmek.
Adım 1'i kaçınılmaz kılmakla başlayın: bir mutabakat dönemi ve kesin veri kaynaklarını seçin. Bunları sayfanın üstüne koyun ve seçimden sonra görünür tutun (dönem, kaynak A, kaynak B, son yenileme zamanı). En çok yeniden iş, birisi yanlış veri çekimine göre uyumsuzlukları incelediğinde olur.
Adım 2, 30 saniyelik taramadır. Toplam farkı, eşleşmemiş öğe sayısını ve en büyük uyumsuzluk kategorilerini gösterin (eksik işlem, tutar farkı, tarih kayması, çoğaltma). Her kategori iş listesi için tıklanabilir olmalı.
Adım 3 hızın önemli olduğu kısımdır: bir öğeyi açın ve alanları yan yana karşılaştırın. Ana alanları hizalı tutun (tutar, tarih, referans, karşı taraf, para birimi, hesap) ve gerekli kanıtı hemen gösterin: ham içe aktarım satırı, defter girişi ve ekli belgeler. Kanıtı ekstra sekmelerin ardına saklamaktan kaçının.
Adım 4 karar noktasıdır. UI net sonuçları olan küçük bir işlem seti sunmalı:
Adım 5 hesap verebilirliktir. Temiz bir eşleşme dışındaki her şey için kısa bir not zorunlu kılın ve yalnızca kurallar gerektirdiğinde onay tetikleyin (örneğin eşikleri aşan terkinler veya kapatılmış alt-deftere yapılan herhangi bir düzeltme). İnceleyici göndermeden önce kimin onaylayacağını görsün ki tahminde bulunmasın.
Adım 6 döngüyü kapatır. Gönderimden sonra ne değiştiğini onaylayın ("Ledger #48321 ile eşleşti", "Düzeltme taslağı oluşturuldu") ve hemen denetim girdisini gösterin: zaman damgası, kullanıcı, eylem, öncesi/sonrası alanlar ve onay durumu. Bir inceleyici tıkladığının "uygulandığını" merak etmemeli.
Düzeltmeler hataların ve dolandırıcılık riskinin ortaya çıktığı yerdir, bu yüzden UI en güvenli işlemleri en kolay hale getirmeli. İyi bir kural: önce parayı değiştirmeyen işlemlere izin verin, sonra değiştirmeye daha fazla niyet gerektirin.
Balans değiştirmeyen "güvenli" işlemlerle başlayın. Bunlar geri dönüşü azaltır ve kararları görünür kılar:
Kullanıcının bir düzeltme oluşturması gerektiğinde, serbest metin kutusu yerine rehberli bir form kullanın. Form temel bilgileri unutmayı zorlaştırmalı ve sonradan gözden geçirmeyi kolaylaştırmalı. Bu, "hızlı düzeltmelerin" ay sonu sorunlarına yol açmasını da önler.
Yıkıcı işlemleri izinler ve net onay ile saklayın. Örneğin "Düzeltmeyi sil" nadir, role dayalı ve bir neden gerektirmeli. Geçmişi düzenlemek yerine yeni bir kayıt oluşturmayı tercih edin.
Kaydetmeden önce doğrulama yapılmalı ve mesaj nasıl düzeltilir açıklamalı. Basit bir kontrol listesi iyi çalışır:
Geri alma davranışını açık yapın. Kullanıcılar öğeyi yeniden açıp açamayacağını, düzeltmeyi tersine çevirebileceğini veya karşı kayıt oluşturup oluşturamayacağını bilmelidir. Örnek: bir inceleyici yanlış banka satırını eşleştirir, sonra eşleşmenin farklı bir ödemeye ait olduğunu fark eder. Orijinal işlemi düzenlemek yerine net bir "Bağlantıyı kaldır" (not ile) seçeneği, düzenleme yerine daha güvenlidir ve ne olduğunun temiz bir hikayesini korur.
Denetim izi yalnızca şu soruları hızlı cevaplıyorsa yardımcı olur: bu öğeye kim dokundu, ne değişti ve neden. Püf nokta gerektiğinde görünür kılmak ama normal inceleme akışını engellememektir.
Öğe detay paneline kompakt bir zaman çizelgesi ekleyin. Her giriş aktörü, zaman damgasını, işlemi ve değişikliğin kısa özetini göstermeli. Okunabilir ve tutarlı tutun ki inceleyenler son anlamlı olayı (örneğin "tutar düzeltildi" veya "onaylandı") bir bakışta görsün.
Bir alan düzeltildiğinde hem öncesi hem sonrası değerleri saklayın ve gösterin. Bunları zaman çizelgesi girdisinde satır içi gösterin (örneğin: "Banka tutarı: 1.250,00 -> 1.205,00") ve ayrıca biri "Değişiklik ayrıntıları"nı açarsa alan geçmişinde gösterin. Bu, yalnızca son değeri saklama hatasını önler.
Daha yüksek riskli işlemler (terkin, manuel geçersiz kılma, zorla eşleştirme) için bir neden isteyin. Kısa bir açılır liste ve isteğe bağlı not kullanın, böylece inceleyici hızla ilerleyebilir ama yine de net bir açıklama bırakır.
Maker-checker durum tabanlı olduğunda en iyi çalışır, mesaj tabanlı değil. Basit durumları kullanın: Taslak, Gönderildi, Bilgi gerekli, Onaylandı, Reddedildi, Yükseltildi ve mevcut durumu öğe başlığı yakınında gösterin. Onay UI'sini sıkı tutun:
Son olarak, kanıtları mutabakat öğesinin kendisine ekleyin: dosya yüklemeleri, e-posta veya sohbet referansları, dış ID'ler ve notlar. Bir inceleyici kararı haklı çıkarmak için sistemler arasında arama yapmak zorunda kalmamalı. AppMaster gibi araçlarda bu, "Reconciliation Item" kaydına bağlı "Evidence" ve "Approval Events" ile temiz şekilde eşlenir; böylece UI basit kalırken veri eksiksiz olur.
Çoğu mutabakat ekranı gerçek veri gelene kadar iyi çalışır. Kırılma noktaları öngörülebilir olduğundan, erken tasarımda onlar için hazırlıklı olmak yardımcı olur.
Kısmi eşleşmeler ilk tuzaktır. Bir-çok eşleşme tablosu, bir banka transferinin üç faturayı ödediği veya beş kart uzlaştırmasının bir defter hesabına toplandığı durumda çözülmez. Bunları birinci sınıf kabul edin: inceleyicilerin görünür toplamı, "ayrılmamış tutar" göstergesi ve açık grup etiketi (örneğin "3 öğe -> 1 kayıt") olan bir gruplanmış eşleşme oluşturmasına izin verin. Grup genişletilebilir olmalı ki insanlar parçaları onaylayabilsin ama özet kaybolmasın.
Çoğaltmalar ikinci tuzak. İnsanlar genellikle yanlış öğeleri eşleştirerek çoğaltmaları "düzeltir". Tutar, tarih penceresi ve karşı taraf temelinde "muhtemel çoğaltma" gibi yumuşak ipuçları ekleyin, ama güvenli tutun: inceleyiciler karşılaştırma görünümünü açabilmeli, doğru kaydı seçebilmeli ve diğerini bir nedenle çoğaltma olarak işaretleyebilmelidir. Birleştirme sunuyorsanız, geri alınabilir olsun ve her zaman orijinal ID'leri saklayın.
Para birimi ve yuvarlama farkları yaygındır ve hata gibi görünmemeli. Kesin hesaplamayı (kur, ücret, yuvarlama) gösterin ve yapılandırılabilir eşiklere izin verin (para birimine, hesaba veya işlem türüne göre). UI "tolerans içinde" mu yoksa "işlem gerekiyor" mu demeli, sadece "eşleşti/uyuşmuyor" dememeli.
Geç kayıtlar dönem kapanışını karıştırabilir. Bir öğe dönem kapandıktan sonra çözüldüğünde, geçmişi yeniden yazmayın. Bunu "kapanış sonrası çözüldü" olarak gösterin, çözüm tarihini gösterin ve kapalı bir dönem sayısını değiştiriyorsa bir not veya onay isteyin.
Son olarak, kesintiler ve eksik beslemeler olur. Yeniden ziyaret etmeyi kolaylaştıran durumlar ekleyin:
Bunları AppMaster ile inşa ediyorsanız, bu durumları Data Designer'da modelleyin ve İş Süreci Editörü'nde izin verilen geçişleri uygulayın ki uç durum işleme tutarlı ve denetlenebilir kalsın.
Ay sonu. Banka ekstresi Nisan için 248.930,12 $ hareket gösteriyor, ancak dahili defteriniz 249.105,12 $ topluyor. Mutabakat ekranı Özet ile açılıyor ve üç soruyu hızlı cevaplıyor: kaç öğe eşleşti, kaç uyumsuzluk var ve ne kadar para çözümsüz kaldı?
Özet panelinde kullanıcı şunu görüyor: 1.284 eşleşmiş öğe, 3 uyumsuzluk ve çözümsüz fark 175,00 $. Küçük bir çağrı "2 öğe işlem gerektiriyor" diyor çünkü bir uyumsuzluk yalnızca bilgilendirme amaçlı.
Uyumsuzluk tablosu sorunları türüne göre gruplayıp sonraki adımı açık hale getirir:
Kullanıcı bir satıra tıkladığında, Öğe Detayları sağda açılır. 25,00 $ için Öğe Detayları banka satırını (tarih, açıklama, tutar) defter tarafı yanında (eşleşen giriş bulunamadı) ve kısa bir önerilen düzeltme gösterir: "Gider kaydı oluştur: Banka ücretleri." Kullanıcı bir düzeltme nedeni seçer, not ekler ve banka ekstresi satırını kanıt olarak ekler.
150,00 $ çoğaltma için Öğe Detayları bir banka ödemesine iki defter girişi eşlendiğini gösterir. Kullanıcı bir defter girişini çoğaltma olarak işaretler, "Yevmiyeyi tersine çevir" seçer ve ekran önerilen ters kayıt oluşturur. Bu muhasebeyi değiştirdiği için onaya gider: durum "Onay bekleniyor" olur ve uyumsuzluk artık "İncelenmedi" sayılmaz.
Zamanlama gecikmesi farklı görünür. Banka 30 Nisan'da başlatılan bir ödemeyi gösterir, ancak 1 Mayıs'ta netleşir. Kullanıcı çözüm durumunu "Zamanlama farkı" olarak ayarlar, beklenen netleşme tarihini seçer ve öğe bir sonraki dönem için "Açık devretme" olarak taşınır.
Daha sonra bir denetçi şu şeyleri tahmin etmeden doğrulayabilmelidir:
Bir dönemi kapatmak küçük UI boşluklarının daha sonra büyük baş ağrılarına dönüştiği yerdir. İyi bir kapanış kontrol listesi ekranda görünür, doğrulaması kolay ve kazara atlanması zor olmalıdır.
Toplamlarla başlayın. Dönem için her kaynakta hem adet hem tutarı gösterin ve hangi rakamın uyumsuzluğa yol açtığını belirgin yapın (örneğin her iki tarafta "3 öğe, 1.240,00 $"). Toplamlar eşleşiyorsa ama adetler değilse bunu açıkça belirtin ki inceleyenler işin bittiğini varsaymasın.
Kapatmadan önce her istisnanın final bir durumu ve ileride bir başkasının anlayacağı bir nedeni olmalı. "Çözüldü" tek başına yeterli değildir; örneğin "çoğaltma tersine çevrildi" veya "zamanlama farkı, bir sonraki dönemde netleşecek" gibi notlar olmalı. Bu, tekrar işi önleyen mutabakat ekranı desenlerinden biridir.
Kısa bir ön-kapanış kontrol listesi kullanın ve bunlardan herhangi biri başarısızsa kapanışı engelleyin:
Seçmeli kontrol basit ama güçlüdür. Rastgele beş çözülen öğeyi açın ve üç şeyi doğrulayın: kanıt (ekstre satırı, makbuz, sistem kaydı), düzeltme eylemi (ne değişti) ve not (neden geçerliydi). Herhangi biri eksikse UI insanlara yanlış alışkanlık kazandırıyor demektir.
Son olarak, dönemi yeniden üretilebilir kılın. Ana toplamları, istisna durumlarını, notları ve onayları donduran bir "anlık görüntü" sunun. AppMaster'da bu, İş Süreci tarafından oluşturulan özel bir "Period Close" kaydı olabilir, böylece ilerideki denetim görünümü kapanışta görülenle eşleşir.
Düzen yerine veriden başlayın. Bir mutabakat ekranı, sistem bir kaydın ne olduğunu ve diğerleriyle nasıl ilişkili olduğunu net şekilde açıklayamadığında karışır. Sonradan büyütebileceğiniz küçük bir model tanımlayın: kaynak dosyalar/beslemeler, bireysel işlemler, kaynaklar arasında öğeleri bağlayan eşleşme grupları ve farkları düzeltmek için oluşturduğunuz ayarlamalar. İnceleme için gerekli alanları ekleyin (tutar, para birimi, tarihler, referans metni) ve sıkıcı ama kritik olanları da (durum, sahip, zaman damgaları).
Sonra roller üzerinde erken karar verin. Çoğu ekip en az üç role ihtiyaç duyar: eşleşmeleri ve düzeltmeleri önerebilen bir analist, düzeltmeleri onaylayabilen bir onaylayıcı ve her şeyi görebilen ama hiçbir şeyi değiştiremeyen bir denetçi. İzinleri beklerseniz, ilk kontrol incelemesi geldiğinde temel eylemleri (düzenle, geri al, yeniden aç) yeniden inşa etmek zorunda kalırsınız.
Ardından gerçek iş üreten üç yüzeyi prototipleyin:
Durum geçişlerini alışkanlık değil kurallar olarak tanımlayın. Örneğin, bir grup kalan fark sıfır (veya belirlenen tolerans içinde) değilse "Mutabık" durumuna geçmemeli; gerekli alanlar tamamlanmalı ve onaylar yapılmalı. İstisnalara yine izin verin ama neden kodu ve yorum zorunlu kılın ki denetim izi temiz kalsın.
Hızlı bir ilk sürüm için AppMaster gibi bir no-code platform kullanın: veritabanını PostgreSQL destekli Data Designer'da modelleyin, kuyruk ve panelleri web UI oluşturucuda bir araya getirin ve iş kurallarını görsel Business Process editöründe uygulayın. İlk versiyonu dar tutun (tek kaynak çifti, birkaç durum), gerçek ay sonu vakalarıyla test edin ve ekibinizin gerçekte gördüğü uyumsuzluklara göre yineleyin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
