Satır-Ögesi Formları için Ebeveyn-Çocuk Veri Modelleri

Neden tek bir kayıt yeterli değildir

Bir teklif, sipariş, geri ödeme talebi veya kontrol listesi nadiren tek bir şeyi tanımlar. Bu formların çoğunda üstte bir ana kayıt, altında ise birçok küçük girdi bulunur. Her şeyi tek bir kayda zorlamaya çalışırsanız, form okunması zor, düzenlemesi zor ve kolayca bozulur hale gelir.

Uzun bir metin alanı ilk bakışta daha basit görünebilir, ama hemen sorun çıkarır. İnsanlar tek bir öğe ekleyemez, bir satırı diğerlerine dokunmadan düzeltemez veya eski bilgiyi güvenle kaldıramaz. Doğrulama da zayıflar çünkü sistem açık, ayrı öğeler yerine tek bir metin bloğu görür.

Bir satış teklifini düşünün. Bir müşteri talebi beş ürün içerebilir ve her birinin kendi miktarı, birim fiyatı, indirimi ve notu gerekir. Bir geri ödeme talebi de aynı şekilde çalışır. Bir gönderim bir çalışana aittir, ama her harcamanın kendine ait tarihi, kategorisi, tutarı ve fiş durumu olur.

İşte ebeveyn-çocuk modeli burada yardımcı olur. Ana kayıt formun ortak detaylarını saklar: talep eden, tarih, bölüm veya onay durumu gibi. Çocuk kayıtlar satır öğelerini saklar. Her satır kendi başına eklenip, düzenlenip veya silinebilir; ana kayda zarar verilmez.

Bu ayrım formu insanların kullanmasını kolaylaştırır ve ekiplerin güvenmesini sağlar. Bir satır yanlış tutara veya eksik alana sahipse, yalnızca o satırı düzeltebilirsiniz. Kayıtların geri kalanı olduğu gibi kalır.

Aynı desen düzenlenebilir kontrol listeleri için de geçerlidir. Kontrol listesinin bir sahibi ve son tarihi olabilir; her görev ise kendi etiketi, atanan kişi, notu ve tamamlandı durumu gibi alanlara sahip olur. Ortak detaylar bir yerde, öğe detayları ait oldukları yerde kalır.

Ebeveyn ve çocuk kayıtlar nasıl çalışır

Satır-ögesi formunu yönetmek en kolay iki parçaya ayırdığınızda olur: bir ana kayıt ve ona bağlı birçok öğe kaydı.

Ana kayıt yalnızca bir kez görünmesi gereken bilgileri tutar. Bir teklifte bu müşteri, teklif tarihi, satış sorumlusu ve mevcut durum olabilir. Bir geri ödeme talebinde çalışan adı, bölüm, gönderim tarihi ve onay aşaması gibi alanlar olabilir.

Her çocuk kayıt ebeveynle bağlantılı, düzenlenebilir bir öğe saklar. Bir teklifte bir çocuk bir ürün veya hizmet satırını temsil edebilir. Bir kontrol listesinde bir çocuk bir görev olabilir. Bir geri ödeme formunda her çocuk genellikle kategori, tutar, masraf tarihi ve fiş notu gibi alanlara sahip bir harcamadır.

Bunu en basit haliyle şöyle düşünün:

• Ebeveyn: tüm form için paylaşılan detaylar
• Çocuk: bir satır, bir öğe, bir eylem
• Bağlantı: çocuğun ebeveyne işaret eden alanı

Bu yapı önemlidir çünkü toplamlar ve özetler çocuk satırlardan gelmelidir; ana kayda elle yazılan değerden değil. Birisi bir öğe eklediğinde, kaldırdığında veya düzenlediğinde toplam gerçek veriden güncellenmelidir. Bu hata oranını düşürür ve onaylara güveni artırır.

Ayrıca doğrulamayı daha hassas hale getirir. Bir satırda miktar isteyebilir, negatif bir tutarı reddedebilir veya eksik tarihi işaretleyebilirsiniz; tüm formu dondurmak zorunda kalmazsınız.

Günlük işte yaygın kullanım alanları

Bu deseni, bir kaydın altında birçok düzenlenebilir satır gerektiği her yerde görürsünüz.

Teklifler bunun açık bir örneğidir. Bir satış temsilcisi bir teklif oluşturur, sonra her ürün veya hizmet için bir satır ekler. Her satır kendi öğe adı, miktar, birim fiyat, indirim, vergi veya not gerektirebilir; ebeveyn ise müşteri, tarih ve onay durumunu tutar.

Siparişler aynı fikri kullanır, ama satırlar genellikle daha fazla operasyonel detay taşır. Bir sipariş birkaç ürünü içerebilir ve her satır stok durumu, depo notları, kargo detayları veya yerine getirme tarihleri gibi alanlara ihtiyaç duyabilir. Satır öğeleri, sipariş verildikten sonra yapılacak işi yönlendirir.

Geri ödeme iş akışları bir diğer yaygın durumdur. Bir talep bir çalışana ve bir raporlama dönemine ait olabilir, ama birden çok harcama içerebilir. Her harcama satırı genellikle tarih, tutar, kategori, satıcı ve fiş referansı gerektirir. Yöneticiler genellikle bu satırları tek tek incelerler; tüm talebi tek bir evet/hayır kararı olarak görmek yerine.

Kontrol listeleri daha basit görünseler bile aynı modele uyar. Ebeveyn bir işe başlatma planı, saha denetimi veya haftalık inceleme olabilir. Her çocuk satır bir görev olur; kendi tamamlandı durumu, notu, sahibi veya son tarihi vardır.

Basit bir test şudur: formun bir başlığı ve insanların eklemesi, düzenlemesi veya kaldırması gereken birçok satırı var mı? Cevap evet ise, ebeveyn-çocuk yapısı genellikle daha temiz bir seçimdir.

İnşa etmeden önce yapıyı planlayın

İyi formlar genellikle bir soruyla başlar: hangisi tüm kayıtla ilgilidir ve hangisi her satırda tekrarlanır?

Bunu önce cevaplayın, sonraki birçok sorun kendiliğinden kaybolur. Yinelenen alanlardan, karışık toplamdan ve yönetilmesi zor satırlardan kaçınırsınız.

Ana kayıt için yalnızca tüm belgeyi tanımlayan alanları tutun. Bir teklifte bu müşteri adı, teklif tarihi, para birimi, satış temsilcisi ve genel onay durumu olabilir. Bir geri ödeme talebinde çalışan adı, bölüm, gönderim tarihi ve nihai karar gibi alanlar olabilir.

Çocuk kayıtlar için her satıra ait alanları tutun. Bu, öğe adı, miktar, birim fiyat, masraf tarihi, kategori, fiş türü, görev etiketi veya satır notları olabilir. Eğer bir değer her satırda farklı olabiliyorsa, genellikle çocukta olmalıdır.

Yararlı bir test: bir satırı silerseniz o değer de onunla birlikte gitmeli mi? Cevap evet ise, o alan muhtemelen çocuk kayda ait olmalıdır.

Her satırın ayrıca kendi benzersiz kimliği olmalıdır. Sadece satır pozisyonuna (birinci, ikinci, üçüncü) güvenmeyin. Bir satır kimliği belirli bir gideri düzenlemeyi, silinmiş bir öğeyi geri getirmeyi veya neyin değiştiğini takip etmeyi çok daha kolay yapar.

İnşa etmeden önce insanların satırlarla nasıl çalışacağını da kararlaştırın. Yeni satır ekleyebilecekler mi, bir satırı çoğaltabilecekler mi, silebilecekler mi, yeniden sıralayabilecekler mi veya uzun bir listeyi filtreleyebilecekler mi? Ayrıca toplamlar ve durumların ne zaman güncelleneceğine karar verin. Bazı ekipler bir satır değişir değişmez toplamların yenilenmesini ister. Diğerleri yalnızca kayıt kaydedildiğinde veya gönderildiğinde güncelleme ister. Her iki yaklaşım da çalışabilir, ama kural tutarlı kalmalıdır.

Durum kuralları da önemlidir. Bir harcama reddedilirse tüm istek taslağa mı dönmeli, beklemede mi kalmalı yoksa kısmen onaylı mı olmalı? Bu sorulara kullanıcılar forma güvenip kullanmaya başlamadan önce cevap bulmak, sonradan yaşanacak kafa karışıklıklarını önler.

Formu kullanan kişi için düzenlemeyi kolaylaştırın

Satır-ögesi formu, insanlar ana detayları ve satırları birlikte görebildiğinde en iyi şekilde çalışır. Ana kaydı üstte koyun, düzenlenebilir tabloyu hemen altında gösterin. Bir teklif oluşturulurken, ürün eklemeye başlamadan önce müşteri, tarih ve durumu onaylayabilmelidirler.

Bu basit düzen hata oranını azaltır çünkü kullanıcılar neyi düzenlediklerini kontrol etmek için ekranlar arasında geçiş yapmazlar.

Tüm işi tek ekranda tutun

Yeni bir satır eklemek hızlı hissettirmeli. Tabloyun üstünde veya altında net bir "Öğe ekle" düğmesi genellikle yeterlidir. Birisi buna tıkladığında boş bir satır veya küçük bir satır-içi form açın; ayrı bir sayfaya göndermeyin.

Bu, özellikle uzun formlarda önemlidir. On tane gider girecek birinin her ekstra tıkı yavaşlatması hataları artırır.

En kullanışlı satır eylemleri genellikle en basit olanlardır: ekle, çoğalt, sil ve bazen taşı. Çoğaltma, birkaç satırın benzer olduğu durumlarda özellikle yardımcıdır; örneğin tekrarlayan otel geceleri veya küçük değişikliklerle benzer kontrol listesi maddeleri.

Hataları olduğu yerde gösterin

Uzun formlar kısmi çalışmayı otomatik kaydetmeli veya en azından taslak kaydetmeye izin vermelidir. Bir sekme kapanırken yirmi dakikalık satır düzenlemesini kaybetmek, bir formun güvenilirliğini hızla yok eden durumlardandır.

Doğrulama da aynı şekilde açık olmalı. Bir satırda eksik tutar veya geçersiz miktar varsa hatayı o satır ve alanda gösterin. İnsanları belirsiz bir uyarı için tüm formu aramaya zorlamayın.

Yedi gider satırı doğruyken bir tanesinde fiş numarası eksikse, yalnızca o satırı işaretleyin. İsteğin geri kalanını olduğu gibi tutun ve kişinin sorunu yerinde düzeltmesine izin verin.

Örnek: birçok harcaması olan bir geri ödeme talebi

Bir geri ödeme talebi bu modelin neden bu kadar iyi çalıştığını açıkça gösterir. Bir talep ana kayıt olarak davranır ve her harcama bir çocuk satırına dönüşür.

Ana kayıt tüm talebe uygulanan detayları tutar: çalışan adı, talep dönemi, yönetici ve genel durum. Bu durum Taslak'tan Gönderildi'ye, sonra Kısmen Onaylı veya Onaylı'ya geçebilir.

Her harcama satırı yalnızca o öğeye ait detayları saklar. Bir satır taksi yolculuğu için satıcı, satın alma tarihi, tutar, kategori ve fiş bilgilerini tutabilir. Başka bir satır aynı alanları otel faturası için tutar.

Basit bir talep şu üç satırı içerebilir:

• City Taxi, 3 Mayıs, $28, Seyahat, fiş eklendi
• Grand Hotel, 4 Mayıs, $180, Konaklama, fiş eklendi
• Corner Cafe, 4 Mayıs, $14, Yemekler, fiş yok

Bu yapı önemlidir çünkü yöneticiler genellikle geri ödeme satırlarını tek tek inceler. Taksi ve otel onaylanabilir; yemek reddedilip kısa bir nedenle birlikte bırakılabilir: "Fiş eksik" veya "Günlük limit aşıldı." gibi.

Bir satırın reddedilmesi tüm talebi bozmaz. Çalışan onaylanan öğeler için yine ödeme almalı; reddedilen satır görünür kalmalı ve reddedilme nedeni eklenmelidir. Bu süreç hem anlaşılmasını hem de sonradan denetlenmesini kolaylaştırır.

Toplamlar çocuk satırlardan gelmelidir; ana kayda elle yazılan bir sayıdan değil. Birçok ekip iki total tutar: dahil edilen tüm satırlara göre gönderilen toplam ve yalnızca kabul edilen satırlara göre onaylanan toplam. Bu, ödemenin neden orijinal talepten düşük olduğunu açıklamaya yardımcı olur.

Toplamlar, onaylar ve durum değişiklikleri

Satır-ögesi formu sayılar ve durumlar doğru zamanda güncellendiğinde güvenilir hisseder.

Bir kullanıcı bir miktarı, fiyatı veya harcama tutarını değiştirirse, toplamlar bu değişikliğe göre yeniden hesaplanmalıdır. Sadece son gönderimde beklemek, özellikle indirimler, vergiler veya onay limitleri söz konusu olduğunda kafa karışıklığı yaratır. Çoğu durumda ana toplam hesaplanmalı, düzenlenebilir olmamalıdır.

Onay kuralları da aynı açıklıkta olmalı. Bir kayıt tamamen onaylandığında, satırlar kilitlenecek mi? Onaylanmış satırlar düzenlenebilir kalırsa, yönetici gerçekten imzaladığı verilerden uzaklaşma riski olur.

Bazen onay satır satır olur; tümünde değil. Geri ödemeler buna iyi bir örnektir. Seyahat onaylanabilir, yemek kısmen reddedilebilir ve başka bir harcama açıklama için geri gönderilebilir. Bu durumda her çocuk satırın kendi durumu olmalı; ana kayıt genel durumu saklamalıdır.

Kısa bir genel durum seti genellikle yeterlidir:

• Taslak
• İnceleme bekliyor
• Kısmen onaylı
• Onaylı
• Reddedildi

Bu ayrım formu dürüst tutar. Ana kayıt isteğin genel durumunu söyler, çocuk satırlar ise her öğe için ne olduğunu açıklar.

Ayrıca miktar, durum, onaylayan veya toplam gibi önemli alanlar için basit bir değişiklik geçmişi tutmak faydalıdır. Başlangıçta tam bir denetim sistemi gerekli olmayabilir, ama ana değişiklikleri açıklamaya yetecek kadar geçmişe ihtiyaç vardır.

Silinen satırların da bir kuralı olmalıdır. İnceleme başlamadan önce kalıcı silme uygun olabilir. İnceleme başladıktan sonra arşivleme genellikle tam kaldırmadan daha güvenlidir; böylece geçmiş toplamlar ve onay kararları mantıklı kalır.

Güveni zayıflatan hatalar

Bir form ekranda temiz görünür ama altta karışık veri saklıyorsa güven hızla düşer.

En yaygın hatalardan biri ana alanlarla öğe alanlarını tek bir düz tabloda karıştırmaktır. Bir teklif, sipariş veya geri ödeme talebi tüm belgeye ait detaylara (talep eden, tarih, onay durumu vb.) ve satırlara ait detaylara (öğe adı, tutar, miktar, fiş tarihi vb.) sahiptir. Bunlar karıştıysa düzenlemeler kafa karıştırıcı olur, raporlar kullanımı zorlaşır ve yinelenen veri hızla yayılır.

Başka bir sorun, insanların sistemin hesaplaması gereken toplamları elle girmesine izin vermektir. Birisi üç gider satırı girip sonra ayrıca bir büyük toplam yazarsa sayılar uyuşmayabilir. Birkaç kez böyle bir durum olunca inceleyenlerin forma güveni azalır.

Büyük bir serbest metin kutusu da benzer sorunlara yol açar. Kullanıcıların tüm öğeleri tek bir alana yapıştırmasını istemek hızlı görünebilir, ama yapılandırılmamış metin doğrulama, sıralama, filtreleme veya onaylama açısından zorlayıcıdır. Yapılandırılmış satırlar daha fazla planlama gerektirir ama sonradan yönetimi çok daha kolaydır.

Satır düzeyinde kontrollerin atlanması da sık rastlanan bir problemdir. Boş satırlar, geçersiz tarihler, yinelenen girdiler, negatif tutarlar ve yarım kalmış öğeler form ilerlemeden önce yakalanmalıdır. Gerçek hataların çoğu çocuk satırlarda olur, başlıkta değil.

Silme bir diğer zayıf nokta. Kullanıcılar satırları tek tıkla ve onay olmadan kaldırabiliyorsa, önemli veriler kazara kaybolabilir. Kim değişiklik yaptı kayıt altına alınmamışsa bu daha da kötüdür.

Daha güvenli bir yaklaşım basittir: satır silmeyi onaylatın, hesaplanan alanları kilitleyin ve insanların yaptığı önemli değişiklikleri kaydedin.

Yayına almadan önce kontrol edin

Tekrarlayan satırlara sahip bir formu yayınlamadan önce gerçek kullanıcıların yapacağı şekilde test edin.

Temelden başlayın. Bir kullanıcının satır ekleyip, düzenleyip, çoğaltıp ve silerken diğer verileri kaybetmediğinden emin olun. Formun on satırla, sonra elli veya yüz satırla da iyi davrandığını kontrol edin. Hatalar sadece sayfanın üstünde değil, ilgili satırda görünmelidir.

Sonra değişikliklerden sonra ne olduğuna bakın. Bir miktarı güncelleyin, bir satırı silin, bir öğeyi çoğaltın ve bir durumu değiştirin. Her işlemden sonra ana kaydın doğru toplamları, sayıları ve özet durumunu gösterdiğini doğrulayın.

Ayrıca genellikle zayıf noktaları ortaya çıkaran uç durumları test edin: tüm satırların kaldırılması, birçok doğru satır arasında bir tane geçersiz satır, yinelenen girdiler, sıfır tutarlar, uzun notlar ve gönderim sonrası yapılan düzenlemeler.

Bir form normal kullanımda açık kaldığında ve dağınık günlük koşullarda bile öngörülebilir davrandığında hazır sayılır.

Bunu bir no-code uygulamada inşa edin

Bunu bir no-code uygulamada inşa ediyorsanız, kullanıcılara zaten tanıdık gelen bir iş akışıyla başlayın; örneğin geri ödemeler veya teklifler. Önce veri yapısını kurun, sonra ana kayıt ile alt satırlar arasındaki bağları sağlayan kuralları ekleyin, en son düzeni cilalayın.

Gerçek örnek veriler kullanmak, kusursuz test verilerinden çok daha faydalıdır. Yinelenenleri, eksik notları, düzeltilmiş tutarları ve tamamlanmamış satırları girin. Bu durumlar formun nerede kafa karıştırdığını ve güvenin nerede düşmeye başladığını gösterir.

AppMaster bu tür bir kurulum için uygundur çünkü ebeveyn-çocuk yapısı ayrı veri modellerine, ilişkili formlara ve iş mantığına doğal bir şekilde uyar. Süreç büyürse, AppMaster aynı çekirdek modeli backend, web ve native mobil uygulamaya dönüştürmeyi destekler; iş akışını baştan inşa etmeye gerek kalmaz.

Temel amaç hangi aracı kullanırsanız kullanın aynıdır: ana kaydı temiz tutmak, her satırı kendi başına düzenlenebilir bırakmak ve toplamların ile durumların gerçek veriden gelmesini sağlamak. Bu kısmı doğru yaptığınızda satır-ögesi formları hem kullanımı kolay hem de güvenilir olur.