Fiş fotoğraflı gider geri ödeme uygulaması ile daha hızlı onaylar

Evrak işlerinin sorunu, basitçe açıklanmış\n\nFiş peşinde koşma genellikle küçük başlar. Birisi taksiye biner, fiş makbuzunu cebine tıkar ve sonra gönderecektir. Bir hafta geçer, fiş solmuş ya da kaybolmuş olur ve talep uzun bir mesaj dizisine dönüşür.\n\nÇoğu dağınıklığa yol açan üç şey var: fişler kayboluyor (veya hiç toplanmıyor), kurallar belirsiz hissediliyor (hangi harcamaya fiş lazım, hangi not gerekli, limitler neler) ve onaylar yavaş ilerliyor (yönetici meşgul, finance sorular soruyor ve talep yarım kalıyor).\n\nHerkes bunu hisseder, ama farklı şekillerde. Çalışanlar zaten harcadıkları parayı bekler. Yöneticiler hızlı onaylamak yerine eksik detay ister. Finance toplamları tekrar girer, kart ekstreleri ile eşleştirir ve ay sonunda insanları kovalar.\n\nFiş fotoğraflı basit bir gider uygulaması bunu, doğru davranışı en kolay davranış yaparak çözer. Gönderim bir dakika altında olmalı. Yöneticiler kazma gerektirmeden karar verebilecek kadar bağlam görmeli. Finance elle temizleme gerektirmeyen temiz sayılarla sonuçlanmalı.\n\nİşte inşa ettiğiniz iş akışı:\n\n- Çalışan fiş fotoğrafı ve birkaç ana alanla gider gönderir.\n- Uygulama temel kuralları kontrol eder (eksik fiş, limit aşımı, yanlış kategori).\n- Yönetici onaylar veya net bir soru ile geri gönderir.\n- Finance istisnaları inceler, sonra temiz aylık toplamları dışa aktarır.\n- Çalışan geri ödemeyi alır ve durumunu her zaman görebilir.\n\nBu yapıyı AppMaster gibi bir no-code platformunda kurarsanız hedef aynı kalır: “o fiş nerede?” anlarını azaltmak ve aylık panik yerine öngörülebilir, izlenebilir bir süreç sağlamak.\n\n## Gerekli roller ve izinler\n\nBir gider aracını adil hissettirecek en hızlı yol, kimin ne yapabileceğini netleştirmektir. Basit bir rol yapısı iki yaygın problemi önler: onay sonrası taleplerin düzenlenmesi ve finance’ın haftalarca eksik detay kovalaması.\n\nDört rol ile başlayın. İlk etapta izinleri sıkı tutun, sonra gerçekten ihtiyaç gördüğünüzde istisnalar ekleyin.\n\n- Employee (talep sahibi): bir talep oluşturur, fiş fotoğrafları ekler, taslakken düzenleyebilir ve durum güncellemelerini görür. Gönderim sonrası sorulara cevap verip ek dosya ekleyebilmeli, fakat talep taslağa döndürülmediği sürece tutarları değiştirememelidir.\n- Manager (onaylayan): inceler, onaylar veya reddeder ve kısa bir notla değişiklik isteyebilir. Birçok ekip tatiller için güvenli bir “vekil” seçeneğine ihtiyaç duyar ki onaylar beklemesin.\n- Finance (denetçi): her şeyi görebilir, fişleri örnek denetleyebilir ve kodlamayı (maliyet merkezi veya kategori gibi) değiştirebilir, ama orijinal fiş görselini değiştirmemelidir. Finance, kapalı bir ayı kilitleyebilmeli ki raporlama sonrası toplamlar kaymasın.\n- Admin (ayarların sahibi): kullanıcıları, ekipleri, maliyet merkezlerini, geri ödeme yöntemlerini ve politika kurallarını yönetir. Admin varsayılan olarak kendi giderlerini onaylamamalıdır.\n\nKüçük ama önemli bir kural: “görebilme” ile “değiştirebilme”yi ayırın. Yöneticiler genellikle ekiplerinin taleplerini görmeli, ama bir çalışanın açıklamasını düzenlememeli veya fişi değiştirmemelidir.\n\nErken birkaç kenar durum izni tanımlayın:\n\n- Başkası adına kim gönderim yapabilir (asistanlar)?\n- Hangi roller hassas satıcıları (medikal, hukuk vb.) görebilir?\n- Reddedilmiş bir talebi kim yeniden açabilir?\n\nAppMaster burada yardımcı olabilir çünkü rolleri ekranlara ve eylemlere eşleyip aynı kuralları web ve mobil arasında yeniden kullanabilirsiniz.\n\n## Çalışanların ne göndermesi gerektiği (ve neyin isteğe bağlı olduğu)\n\nİnsanları bir gider aracından nefret ettirmenin en hızlı yolu her seferinde tam bir “gider raporu” istemektir. Daha iyi bir desen: çalışanlar tek tek giderleri ekler (bir fiş = bir satır) ve uygulama bunları hafta, seyahat veya ay için otomatik olarak raporlar. Yöneticiler raporu onaylar, ama bir şey şüpheli görünürse herhangi bir satırı açıp inceleyebilir.\n\nHer gider satırı için zorunlu alanları sıkı tutun ki gönderimler bir dakika altında olsun:\n\n- Satın alma tarihi\n- Satıcı\n- Tutar\n- Para birimi\n- Kategori (yemek, konaklama, taksi, malzeme vb.)\n\nDiğer her şey ilk etapta isteğe bağlı olmalı, ancak ekipler ihtiyaç duyduğunda erişilebilir olsun. Satış ekipleri müşteri adı isteyebilir. Operasyonlar maliyet merkezine ihtiyaç duyabilir. Bu alanları herkes için zorunlu kılarsanız, finance’ın kullanamayacağı “N/A” veya “diğer” gibi sahte verilerle karşılaşırsınız.\n\nDaha sonra işe yarayan isteğe bağlı alanlar: proje veya iş kodu, müşteri, maliyet merkezi ve ödeme yöntemi (kişisel kart vs kurumsal kart). AppMaster kullanıyorsanız temel ile başlayıp akışı bozmadan alan ekleyebilirsiniz çünkü uygulama gereksinimler değişince yeniden üretilebilir.\n\nFiş fotoğrafları çekirdek ama kural tek beden herkes için olacak diye bir şey yok. Çoğu şirketi kapsayan iki basit politika:\n\n- Belirli kategoriler için her zaman zorunlu (konaklama, uçak biletleri gibi)\n- Belirli bir tutarın üzerindeyse zorunlu (örneğin $25 üzeri her gider)\n\nAyrıca “fiş eksik” seçeneğine kısa bir nedenle izin verin ama sınırlı tutun. Bu, sürecin ilerlemesini sağlar ve finance’a kontrol imkanı verir.\n\n## Gönderimden geri ödemeye kadar net bir iş akışı\n\nİyi bir gider akışı, en iyi anlamda sıkıcı hissettirir. Çalışanlar ne yapacaklarını bilir, yöneticiler çabucak karar verir ve finance ayı kapatırken insan peşinde koşmaz.\n\nBir “gider”in nerede yaşadığına karar verin. Çoğu ekip giderlerin bir rapor içinde (seyahat, ay, proje) olmasının işe yaradığını fark eder; böylece insanlar tek tek değil, toplu göndermeye teşvik edilir.\n\nÇalışan akışı: bir rapor oluştur, tek tek gider ekle, fişi çek veya yükle ve her şey hazır olduğunda gönder. Formu kısa tutun ki fiş fotoğrafı açıklamanın büyük kısmını üstlensin.\n\nGönderildikten sonra yöneticilerin üç net eylemi olmalı: onayla, reddet veya açıklama iste. “Açıklama iste” yeniden gönderimleri azaltmanın anahtarıdır. Basit bir soru olarak çalışana geri dönmeli ve raporu bozmadan sadece eksik olanı düzeltebilmelerini sağlamalıdır.\n\nFinance ikinci bir gözden geçirme yapmalı, ama her şeyde değil. Yüksek tutarlar, belirli kategoriler veya eksik alanlar için örnek denetimler kullanın. Finance politikayı uygulayıp geri ödeme işaretlenmeden önce son onayı vermelidir.\n\nDurumları herkesin görebileceği şekilde yapın, kayıt altındaki bir günlüğün arkasına saklamayın. Dört aşama genellikle yeterlidir:\n\n- Draft (sadece çalışan görür)\n- Submitted (yöneticiyi bekliyor)\n- Approved (yönetici ve finance tamamlandı)\n- Paid (geri ödeme yapıldı)\n\nAppMaster ile inşa ediyorsanız iş akışı mantığını tek bir yerde (tek bir business process) tutun ki durum değişiklikleri, bildirimler ve izinler web ve mobil ekranlarda tutarlı kalsın.\n\n## Önce tasarlanacak ekranlar (minimal tutun)\n\nÇoğu gider uygulaması ilk birkaç ekranda kazanır veya kaybeder. Ekranları küçük, hızlı ve tek işe odaklı tutun. Sonradan görsellik ekleyebilirsiniz ama temel yavaşsa insanlar kullanmayı bırakır.\n\n### Çalışan (mobil): bir dakikadan kısa sürede gönderim\n\nYeni gider akışı, birinin takside veya havaalanı kuyruğunda olduğu durumda çalışmalı. Fotoğraf çekmelerine, tutarı girmelerine, kategori seçmelerine ve eksikse taslak kaydetmelerine izin verin.\n\nBaşlangıç için bu temel öğeler yeterli:\n\n- Yeni gider formu (satıcı, tarih, tutar, kategori)\n- “Tekrar çek” seçeneğiyle kamera yükleme\n- Taslaklar listesi (yolda kaybolmasın)\n- Durum görünümü (kafalarında soru kalmasın)\n- Not alanı (isteğe bağlı)\n\n### Yönetici: her fişi açmadan onayla\n\nYöneticilerin “bugün neye dikkat etmeliyim?” sorusuna cevap veren bir kuyruk gerek. Basit filtreler ekleyin (takım, tarih aralığı, politika aşımları) ve onay veya reddetme işlemini tek dokunuşla yapın. Yorumlar hızlı olmalı ve önerilen kısa cevaplar sunulmalı, örn. “Lütfen proje kodu ekle” veya “Fatura detaylı değil.”\n\nBildirimleri seçici tutun: gider gönderildiğinde (veya haftalık parti geldiğinde) bir bildirim, onaylandığında veya değişiklik gerektiğinde ayrı bir bildirim yeterli. Taslaktaki her küçük düzenleme için rahatsız etmeyin.\n\n### Finance: ayı kapat, insan kovalamak değil\n\nFinance için çalışan, maliyet merkezi ve kategoriye göre toplamları gösteren aylık bir görünüm, ayrıca eksikler için bir istisna listesi gerek. AppMaster kullanıyorsanız dışa aktarma ekranını ekibinizin ayı kapatma şeklinde tasarlayın: bir dönem seçici, bir inceleme tablosu ve istisnalar temizlendikten sonra tek bir dışa aktarım eylemi.\n\n## Büyüdükçe düzenli kalan veri modeli\n\nİyi bir veri modeli, uygulamanın aylar sonra daha fazla çalışan, daha fazla politika ve daha fazla kenar durum olduğunda bile basit hissetmesini sağlar. Temel varlıkları küçük ve öngörülebilir tutun, sonra yalnızca gerçekten gerektiğinde isteğe bağlı alanlar ekleyin.\n\nİşe insanların nasıl çalıştığına karşılık gelen birkaç tablo ile başlayın:\n\n- Users: roller ve maliyet merkezi veya takım bilgisi.\n- Reports: bir seyahat veya ay için tek rapor, bir kullanıcıya ait, durum alanı (Draft, Submitted, Approved, Paid).\n- Expenses: rapor içindeki satırlar (tarih, satıcı, tutar, para birimi, kategori, notlar).\n- ReceiptFiles: giderle ilişkili dosya kayıtları (dosya adı, boyut, MIME tipi, depolama anahtarı).\n- Approvals: her onay adımı için bir satır (kim, hangi karar, ne zaman).\n\nİlişkileri sıkı tutun: bir raporun birçok gideri olabilir, bir giderin birçok fiş dosyası olabilir (iki sayfa veya düzeltilmiş fotoğraf yükleyenler için faydalı). Fiş verisini doğrudan gider satırına koymaktan kaçının. Fotoğrafı dosya olarak saklayın ve veritabanında yalnızca metadata ve gösterge tutun.\n\nFiş fotoğraflarını varsayılan olarak özel tutun. Erişim kurallarını giderle birlikte saklayın: yalnızca çalışan, atanan onaycı(lar) ve finance görüntüleyebilsin/indirebilsin.\n\n“Kimin ne yaptığı ve ne zaman” sorusunu cevaplayan bir denetim izi ekleyin. AppMaster ile bunu PostgreSQL’de Data Designer kullanarak modelleyebilir ve submitted_by, approved_by, created_at, updated_at, decision_at ve kısa bir yorum gibi alanlar ekleyebilirsiniz.\n\n## Geri-dönüşleri azaltan onaylar ve politika kontrolleri\n\nÇoğu gecikme, bir kişi gider gönderip inceleyenin üç takip sorusu sormasıyla olur. Çözüm basit: kuralları net yapın ve çalışan gönder tuşuna bastığında hızlı kontroller çalıştırın.\n\nHerkesin anlayacağı birkaç politika kuralı ile başlayın. Bunları görünür tutun ki çalışanlar sonradan şaşırmasın. En çok yeniden iş gerektiren sorunları önleyen kurallar:\n\n- Kategori limitleri (ör. taksi için bir seferlik üst limit)\n- Günlük yemek capsleri (kahvaltı, öğle, akşam)\n- Belirli tutarın üzeri için fiş zorunluluğu\n- Geçersiz tarihler (gelecek tarih yok, genellikle X günden eski talepler kabul edilmez)\n- Kopya tespiti (aynı satıcı, tarih ve tutar)\n\nBu kontrolleri gönderim anında çalıştırın. Bir şey eksikse tam olarak neyi düzeltmeleri gerektiğini söyleyin. “$25 üzeri tutarlar için fiş gerekli” demek, “Validation failed” demekten daha iyi. Negatif tutar veya para birimi eksikliği gibi bariz hataları da engelleyin.\n\nHer sorun sert bir engel olmamalı. İstisnalara izin verip bunları açıkça işaretleyin. Örneğin bir yolcu otel fişini ertesi sabaha kadar alamayabilir. Fiş olmadan gönderim yapmasına izin verin, bunu “Fiş bekleniyor” olarak işaretleyin ve yönetici onayından sonra finance’a yönlendirin.\n\nOnay yönlendirmesi şirketinizde paranın nasıl sahiplenildiğine uygun olmalı. Bazı ekipler sadece doğrudan yönetici gerekir. Diğerleri büyük harcamalar için maliyet merkezi sahibini, sonra finance’ı gerektirir. AppMaster’da yönlendirmeyi Business Process Editor içinde bir karar akışı olarak modelleyebilirsiniz ki uygulama doğru yolu izlesin.\n\nYardımcı bir detay: “Notla geri gönder” seçeneği ekleyin ve yorum zorunlu kılın. Bu, konuşmanın e-posta ve sohbet yerine talep içinde kalmasını sağlar.\n\n## Finance dışa aktarımları ay sonunu nasıl kolaylaştırır\n\nFinance genellikle “uygulama raporu” değil, güvendikleri ay sonu kapanış rutinine uyan bir dosya ister; temiz sütunlar ve doğrulanabilecek toplamlar.\n\nHer ay finance’ın ihtiyaç duyduğu toplamlarda anlaşın: çalışan, kategori, maliyet merkezi ve proje bazında. Hem detaylı satırları hem de özetleri dışa aktarın ki finance bir artışı ekran görüntüsü istemeden denetleyebilsin.\n\nDışa aktarma formatını kasıtlı olarak sıkıcı tutun. Tutarlı sütun adlarına sahip CSV, kopyala-yapıştır düzeltmelerini önler. İşe yarayan sütunlar:\n\n- Ay (YYYY-MM)\n- Çalışan ID veya e-posta\n- Kategori\n- Maliyet merkezi ve proje kodu\n- Tutar (orijinal), para birimi ve tutar (ev para birimi)\n\nÇoklu para birimi dışa aktarmalarda sıkıntı çıkar. Orijinal tutarı ve para birimini gönderimle aynı şekilde saklayın, ayrıca raporlama için çevrilmiş bir tutar, kullanılan döviz kuru ve tarihini saklayın ki finance farkları açıklayabilsin (ör. “fiş tarihindeki kur” vs “geri ödeme tarihindeki kur”).\n\nAy sonunu bir kapama gibi ele alın. Finance Mart’ı dışa aktardıktan sonra Mart değişmemeli. Onaylanmış giderlere düzenleme yapmayı engelleyen ay kilidi ekleyin (veya düzeltme kayıtlarını bir sonraki ayda zorunlu kılın). Kısa bir kapanış kontrol listesi yardımcı olur:\n\n- Tüm bekleyen onaylar çözülmüş\n- Dışa aktarım üretilmiş ve saklanmış\n- Ay kilitlenmiş\n- Geç gelen fişler sonraki aya düzeltme olarak girilmiş\n\nAppMaster’da bu, bir durum alanı, döneme bir kapanış bayrağı ve ay kilitlendiğinde düzenlemeleri engelleyen bir business process ile güzelce eşlenir.\n\n## Gider uygulamalarını sinir bozucu yapan yaygın hatalar\n\nÇoğu araç basit nedenlerle başarısız olur: insanlar kanıt sunmakta hızlı olamaz, yöneticiler ne yapacaklarını bilmez ve finance ay sonunda dağınık veriyle uğraşır.\n\nFiş fotoğrafları ilk tetikleyicidir. Karanlık bir restoranda çekilmiş fiş, kırpılmış toplam veya bağlamı olmayan yabancı para birimi 30 saniyelik işi bir haftalık mesajlaşmaya çevirebilir. Çalışanlara yöneticinin ne göreceğini hızlıca gösteren bir önizleme adımı ekleyin ve toplam veya tarih okunmuyorsa yeniden çekmeyi isteyin.\n\nKopyalar ikinci tetikleyicidir. Yaygın model: biri telefondan gönderir, sonra çalıştığından emin olmadığı için dizüstünden tekrar gönderir. Çoğunu yakalamak için karmaşık kurallara gerek yok. Satıcı + tarih + tutar gibi basit eşleşme yapıp olası kopyaları işaretleyin ve hangi kaydın kalacağını çalışanın onaylamasını isteyin.\n\nOnay tıkanıkları genellikle sahipliğin belirsizliğinden kaynaklanır. Bir gider muamma halinde kalıyorsa, genellikle kim onaylayacağını bilmiyordur veya süreç küçük tutarlar için çok fazla adıma sahiptir.\n\n### Kaçınılması gereken hatalar (ve yerine ne yapılmalı)\n\n- Çok fazla kategori: kısa bir listeyle başlayın (travel, meals, lodging, mileage, other) ve finance daha sonra eşlesin.\n- Çok fazla zorunlu alan: sadece politika gerçekten neyi gerektiriyorsa zorunlu kılın (tutar, tarih, satıcı, fiş).\n- Hatırlatmalar yok: doğru onaycıya 2–3 gün sonra bir hatırlatma gönderin.\n- Tek tip onaylar: düşük tutarları otomatik onaylayın, sadece gerektiğinde yükseltin.\n- Para birimi belirsizliği: fiş başına para birimi saklayın ve dönüştürme yapıyorsanız kur dayanağını gösterin.\n\nAppMaster ile inşa ediyorsanız kuralları iş akışı içinde görünür tutun ki politika değiştiğinde her şeyi yeniden inşa etmek zorunda kalmayın.\n\n## Uygulamayı yayına almadan önce hızlı kontroller\n\nTüm şirkete davet etmeden önce sık kullanıcılı kısa bir pilot yürütün (5–10 kişi: sık seyahat eden biri, sık onaylayan bir yönetici ve finance’dan biri). Amaç temel akışın hızlı, net ve zor bozulur olduğunu doğrulamaktır.\n\nZaman testi çok şey söyler. Bir çalışan normal bir talebi hızlıca bitiremiyorsa fişleri sonra göndermek üzere saklar ve evrak yığını geri gelir. Yöneticiler telefonla toplantılar arasında onaylayamıyorsa onaylar tıkanır.\n\nYayına hazır olma kontrol listesi:\n\n- Bir çalışan bir talep gönderebilir (1 fiş, bahşiş dahil, notlar isteğe bağlı) 60 saniyenin altında.\n- Bir yönetici telefondan açıp inceleyip 30 saniyenin altında onaylayabilir.\n- Her gider bir rapora bağlı ve her raporun net bir onaycısı var (sahipsiz öğe yok).\n- Finance tek adımda bir tam ayı dışa aktarabilir ve toplamlar elle temizlemeye gerek kalmadan eşleşir.\n- Fişler saklanır, aranabilir ve doğru giderle her seferinde ilişkilendirilir.\n\nGerçekçi bir senaryoyu başından sonuna çalıştırın: “Bugün taksi fişi gönderildi, yarın onaylandı, bu ayın dışa aktarımına dahil edildi.” Herhangi bir belirsizlik görürseniz ekran metinlerini ve varsayılanları düzeltin, sonra yeni özellikler ekleyin.\n\nAppMaster ile bunu kuruyorsanız pilotu hız ve netlik üzerinde tutun. Politika kontrollerini sonra artırabilirsiniz, ama yavaş bir ilk deneyimi düzeltmek zordur.\n\n## Örnek: bir seyahat, üç fiş ve sorunsuz ay sonu\n\nMaya iki günlük müşteri ziyareti yapıyor. Uygulamayı telefonunda kullanıyor, böylece hiçbir şey birikmiyor.\n\nBirinci gün taksi için $28’lik fişi yükler ve otel faturası için $412 fotoğrafını çeker. Uygulama satıcıyı ve tutarı fotoğraftan okur, ama Maya tarama kötü ise hızlıca düzeltebilir.\n\nAkşam yemeğinde fiş almayı unutur. Yemeği yine de $34 olarak manuel girer ve “fiş eksik” notu ekler: “Restoran yazıcısı bozuk, kartla ödendi.” Akış ilerlemeye devam eder ama konu görünür olur.\n\nYöneticisi Jordan ertesi sabah raporu inceler. Jordan taksi ve oteli tek dokunuşla onaylar, yemeği ise “Bilgi lazım” diyerek işaretler ve sorar: “Müşteriyle miydiniz? İsimleri ekle.” Maya talep içinde cevap verir, katılımcıları ekler ve Jordan onaylar.\n\nFinance ödemeden önce her şeyi gözden geçirir. Yemeğin şehir politikası için $6 fazla olduğunu fark eder, bunu istisna olarak işaretler ama ay kapanışını engellemez. Rapor geri ödenir ve istisna eğitim için takip edilir.\n\nAy sonunda finance dışa aktarımları kapatma şeklinde alır. Pratik bir dışa aktarım genellikle şunları içerir:\n\n- Çalışan, bölüm ve maliyet merkezi\n- Tarih, satıcı ve kategori\n- Tutar, vergi ve para birimi\n- Fiş durumu (ekli, eksik, okunamayan)\n- Onay ve istisna bayrakları\n\nAy sonu şöyle görünür: “Travel: $440,” “Meals: $34,” ve “Exceptions: 1,” ve denetçi isterse fiş görselleri mevcut. AppMaster ile bunu kurmak, politika değiştikçe iş akışını ve dışa aktarma alanlarını ayarlamayı kolaylaştırır.\n\n## Sonraki adımlar: pilot, ölçüm ve değiştirilebilir şekilde inşa etmek\n\nKasıtlı olarak küçük başlayın. Pilot grubunu gerçek fiş oluşturacak kadar yeterli, ama düzeltmelerin acı verici olmayacağı kadar küçük seçin.\n\nPilota günlük soruları yanıtlayan bir sayfa kısa rehber verin: hangi harcamaya fiş lazım, fiş olmadan ne izinli, hangi kategoriler kullanılır ve yöneticilerin ne kadar hızlı onaylaması beklenir. İnsanlar kuralı 10 saniyede bulamazsa tahmin edecektir.\n\nPilot kurulum kontrol listesi:\n\n- Farklı rollerden ve lokasyonlardan 10–30 çalışan seçin\n- Net bir başlangıç tarihi ve 2–4 haftalık test penceresi belirleyin\n- Kim onaylıyor ve kim ay sonu toplamlarını dışa aktarıyor netleştirin\n- Bir talep reddedilirse ne olacağına karar verin (düzenle ve yeniden gönder veya yeni talep)\n- Sorunları ve politika sorularını raporlamak için ortak bir yer oluşturun\n\nPilot sırasında sürtüşme noktalarını gösteren birkaç metriği ölçün:\n\n- Gönderim süresi ortalaması (uygulamayı açmaktan gönderene kadar)\n- Ortalama onay süresi (gönderimden yönetici kararına kadar)\n- İstisna oranı (eksik fiş, yanlış kategori, limit aşımı)\n- Yeniden iş oranı (düzeltilmek üzere geri gönderilenler)\n\n2–4 hafta sonra veriye göre kategorileri, limitleri ve bildirimleri ayarlayın. Eğer yemekler en çok istisnaya sebep oluyorsa kısa bir ipucu ekleyin veya “Müşteri yemekleri” ve “Ekip yemekleri” şeklinde ayırın.\n\nDeğişikliği kolay kılacak şekilde inşa edin. Gider politikaları evrilir, ekipler büyür ve finance yeni dışa aktarma alanları isteyebilir. Hızlı hareket etmek ve ağır kod yerine no-code tercih etmek isterseniz, AppMaster tam burada işe yarar: tam iş akışını (backend, web, mobil) oluşturup mevcut bulutunuza deploy edebilir veya self-host için kaynak kodunu dışa aktarabilirsiniz. Gereksinimler değiştiğinde mantığı güncelleyip uygulamayı yeniden üretirsiniz, geçici çözümlerle uğraşmazsınız.\n\nEğer yaklaşımı keşfetmek isterseniz, appmaster.io bu no-code ama üretime hazır uygulamalar isteyen takımlar için pratik bir başlangıç noktasıdır.