Lombard proqramı planlaşdırılarkən maliyyə qaydaları ilə onların texniki uçotunu ayırmaq vacibdir. Bu məqalə faiz, qiymətləndirmə, kredit və ya hüquqi şərtlər tövsiyə etmir. Mövzu razılaşdırılmış iş prosesinin proqramda necə təsvir edilməsi, məlumatların əlaqəsi və dəyişikliklərin izlənməsidir.
Hazırlığa modul adlarının uzun siyahısı ilə başlamaq əvəzinə bir əməliyyat nümunəsi seçin. Hansı məlumat yaradılır, hansı sənədə bağlanır, kim təsdiqləyir və sonradan necə tapılır? Bu suallar texniki tapşırığın əsasını təşkil edir.
Müştəri, əşya və əməliyyat ayrı qeydlərdir
Eyni müştərinin bir neçə əşyası və əməliyyatı ola bilər. Əşyanın identifikatoru, təsviri və əlaqəli materialları müştərinin adı ilə bir sahədə qarışdırılmamalıdır. Hər obyektin ayrıca olması tarixçəni və sonrakı əlaqələri daha aydın edir.
İzahlı nümunə: bir müştəri fərqli vaxtlarda iki əşya ilə bağlı əməliyyat aparır. Bu şərti ssenaridə bir əşyanın vəziyyətindəki dəyişiklik digərinin kartını dəyişməməlidir. Müştərinin əlaqəsi yenilənəndə isə həmin əlaqənin hansı səviyyədə istifadə olunduğu məlum olmalıdır.
Əşya kartının tərkibi
Hansı məlumatın yazılacağı biznesin təsdiqlədiyi qaydalardan asılıdır. Texniki baxımdan identifikator, növ, təsvir, filial, saxlanma vəziyyəti və əlaqəli sənədlər kimi sahələr müzakirə oluna bilər. Foto və faylların keyfiyyəti ilə yanaşı əməliyyatla əlaqəsi də saxlanmalıdır.
- Əşyanın unikal daxili kodu.
- Razılaşdırılmış təsvir və kateqoriya.
- Yerləşdiyi filial və cavabdeh rol.
- Əlaqəli sənəd və qeydlərə keçid.
- Vəziyyət dəyişikliklərinin tarixçəsi.
Sənəd və statusun məntiqi
Sənəd faylı, sənədin təsdiqi və əməliyyatın vəziyyəti ayrı anlayışlardır. Bir faylın yüklənməsi bütün prosesin tamamlanması demək deyil. Statusun hansı faktı ifadə etdiyi və onu kimin dəyişə biləcəyi əvvəl yazılmalıdır.
Geri düzəliş lazım olduqda əvvəlki vəziyyətin silinməsi əvəzinə izahlı tarixçə tələb oluna bilər. Hansı düzəlişin mümkün olması və hansı təsdiq tələb etməsi mütəxəssislə razılaşdırılan biznes qaydasıdır. Proqramçı bu qaydanı ad və interfeysə baxaraq özü müəyyən etməməlidir.
Filial və səlahiyyət sərhədləri
Bir filialın istifadəçisi bütün filialların məlumatına ehtiyac duymaya bilər. Mərkəzi baxış, yerli əməliyyat və yoxlama funksiyası fərqli rollardır. Məxfi müştəri sənədləri, kütləvi ixrac və dəyişiklik təsdiqi ayrıca icazələr tələb edə bilər.
Rol matrisi yalnız menyuya deyil, konkret qeyd və fayla da tətbiq olunmalıdır. İstifadəçi birbaşa başqa qeydin ünvanını açanda sistem onun səlahiyyətini yenidən qiymətləndirməlidir. Bu davranış qəbul sınağının da hissəsi olmalıdır.
Hesablamalar proqramda necə razılaşdırılır?
Hesab qaydaları varsa, onları səlahiyyətli biznes və maliyyə tərəfi təqdim və təsdiq etməlidir. Proqram üçün başlanğıc məlumat, yuvarlaqlaşdırma qaydası, tarix sərhədi və nəticənin izahı lazımdır. Bu məqalə həmin qaydaların özünü müəyyən etmir.
Qəbulda yalnız yekun rəqəmin görünməsinə baxmaq kifayət deyil. Təsdiqlənmiş nümunə məlumatla gözlənilən nəticə müqayisə edilməlidir. Qayda dəyişəndə köhnə əməliyyatların necə saxlanacağı da ayrıca sualdır: cari qaydanı tarixçəyə avtomatik tətbiq etmək yanlış ola bilər.
İxrac, ehtiyat nüsxə və bərpa
Əməliyyat proqramı üçün məlumatın çıxarıla bilməsi və bərpa prosesi praktik tələblərdir. Ehtiyat nüsxənin mövcudluğu onun düzgün açıldığını göstərmir. Bərpa sınağı, girişlərin qorunması və məsul şəxsin təyinatı yazılmalıdır. Saxlanma müddəti isə tətbiq olunan qaydalar əsasında ayrıca müəyyənləşdirilir.
Qəbulda sınaqdan keçiriləcək hallar
- Eyni müştəriyə aid iki müstəqil əşya.
- Əşyanın filialla düzgün əlaqəsi.
- Yanlış sənəd və yeni sənəd versiyası.
- Rolun icazə vermədiyi əməliyyat.
- Təsdiqlənmiş nümunə üzrə hesab nəticəsi.
- Nüsxədən bərpa olunmuş tarixçənin yoxlanması.
Nümunə: etiketlə kartın uyğunluğu
İki fiziki əşyanın təsviri oxşar olduqda proqramdakı ad onların eyni olduğunu göstərmir. Bu şərti nümunədə etiket və daxili identifikator konkret əşyanı ayırmalıdır. Sənəd, foto və hərəkət məhz həmin karta bağlanır.
Yanlış etiket seçiləndə düzəlişin necə aparılacağı əvvəl yazılır. Təsdiqlənmiş əməliyyatın tarixçəsini silib yeni kart yaratmaq əlaqələri itirə bilər. Qaytarma, başqa yerə ötürmə və ya sənəd yenilənməsi kimi hadisələrin hansı obyektə aid olduğu görünməlidir.
- Eyni təsvirli iki fərqli əşya ilə sınaq aparın.
- Etiketin doğru kartı açdığını yoxlayın.
- Yanlış seçim düzəldiləndə əvvəlki əlaqələri müqayisə edin.
- Rolun icazə vermədiyi dəyişiklikləri ayrıca sınayın.
Bu nümunə qiymətləndirmə və maliyyə qaydası təyin etmir. Məqsəd fiziki obyektin proqramdakı qeydlə düzgün əlaqələndirilməsidir. Dəqiq identifikasiya olmadan sonrakı hesabatın görünüşü yaxşı olsa belə, məlumatın mənası səhv qala bilər.
Tez verilən suallar
Hazır proqram, yoxsa fərdi həll?
Bu qərar hazır və fərdi sistem müqayisəsi ilə iş axınına əsaslanmalıdır. Məhsul adı uyğunluğa təkbaşına sübut deyil.
Bütün maliyyə funksiyaları avtomatik daxildirmi?
Xeyr. Hər funksiya və qayda konkret əhatədə təsdiqlənməlidir.
Lombardex CV-də SaaS biznes platforması kimi qeyd olunur. Onun nümunəsi ilə tanış olub biznes proqramının hazırlanması üçün öz təsdiqlənmiş qaydalarınızı hazırlaya bilərsiniz. Büdcə sualları üçün əhatə və qiymət amillərinə baxın.
