# Məzuniyyət təsdiqi prosesində HR hansı məlumatları bir yerdə görməlidir?

- Kanonik ünvan: https://qrgate.az/az/bloq/mezuniyyet-tesdiqi-hr-melumatlari
- Markdown: https://qrgate.az/az/bloq/mezuniyyet-tesdiqi-hr-melumatlari.md
- Dil: az
- Tarix: 2026-07-20

Məzuniyyət müraciəti gəlir. HR-in qarşısında bir tarix aralığı və bir ad var. Təsdiq düyməsini basmaq üçün isə bunlar kifayət deyil: həmin həftədə komandada başqa kim yoxdur, bu adamın əvvəlki müraciətləri necə keçib, tarix bayram günlərinə düşürmü? **Məzuniyyət təsdiqi sistemi** mövzusu texniki deyil, informasiya məsələsidir - qərar verən adam nəyi bir ekranda görməlidir. Bu yazıda həmin siyahını praktik şəkildə açırıq; hüquqi hesablama və qanunvericilik şərhi bu mətnin mövzusu deyil.

## Təsdiqdən əvvəl lazım olan kontekst

Təsdiq bir kliklik iş kimi görünür, amma arxasında dörd sual dayanır:

- **Komandada örtük varmı?** Həmin tarixlərdə neçə nəfər artıq məzuniyyətdədir?
- **Qrafik uyğundurmu?** Növbəli komandada bu adamın çıxması hansı növbəni boş qoyur?
- **Tarixlər nəyə düşür?** Bayram, hesabat dövrü, mövsümi yüklənmə?
- **Tarixçə nə deyir?** Bu il neçə gün istifadə olunub?

Bu dörd sualın cavabı ayrı-ayrı yerlərdə olanda təsdiq prosesi uzanır - və çox vaxt sual verilmədən təsdiqlənir. Nəticə isə bir həftə sonra görünür: eyni gündə üç nəfər yoxdur.

## Növ və tarix aralığı

Bütün məzuniyyətlər eyni deyil və bu fərq təsdiq qərarına birbaşa təsir edir.

| Növ | Planlaşdırıla bilir? | Təsdiqdə əsas sual |
| --- | --- | --- |
| İllik məzuniyyət | Bəli | Örtük və növbə |
| Ödənişsiz | Adətən bəli | Müddət və təkrarlanma |
| Xəstəlik | Xeyr | Sənəd və müddət |
| Qısa icazə | Qismən | Həmin günün örtüyü |

Növ görünmürsə, hamısı eyni siyahıya düşür və planlaşdırma mümkün olmur. Ona görə növ seçimi formanın ilk sahəsi olmalıdır - sonradan əlavə edilən şərh yox.

## Pending, approved, rejected: statusun rolu

Ən çox gözdən qaçan detal budur: **təsdiq gözləyən müraciət də məlumatdır**.

Praktikada belə olur: iki nəfər eyni həftə üçün müraciət edir, biri təsdiqlənir, ikincisi «sonra baxarıq» vəziyyətində qalır. Qrafik qurulanda ikinci müraciət nəzərə alınmır, çünki heç bir siyahıda görünmür.

Üç statusun ayrıca saxlanması üç fərqli işə xidmət edir:

1. **Pending** - planlaşdırma üçün: bu tarixlərdə risk var.
2. **Approved** - qrafik və tabel üçün: bu günlər artıq bağlıdır.
3. **Rejected** - tarixçə üçün: kim, nə vaxt və nə səbəbdən imtina etdi.

Sonuncu ən çox laqeyd yanaşılan, amma mübahisə yarananda ən çox lazım olan qatdır.

## Əməkdaş və tarix filtrləri

Məzuniyyət məlumatı iki tərəfdən oxunur və hər ikisi lazımdır.

**Əməkdaş üzrə baxış** fərdi sualı həll edir: bu adam bu il nə qədər istifadə edib, nə vaxt çıxıb, hansı növlər olub. Bu, adətən söhbətdən əvvəl lazım olur.

**Tarix üzrə baxış** isə təşkilati sualı həll edir: iyul ayında kimlər yoxdur, hansı şöbədə boşluq yaranır. Bu, qrafik qurarkən lazım olur.

Excel-də birinci baxış rahatdır, ikincisi isə çətin - çünki hər müraciət ayrı sətirdir və tarix aralıqları üst-üstə düşür. Sistemdə isə hər iki baxış eyni məlumatın iki kəsimi olur. Sistemin ümumi məntiqini [işçi davamiyyət sistemi nədir](https://qrgate.az/az/isci-davamiyyet-sistemi-nedir) səhifəsində izah etmişik.

## Hesabat və export

Məzuniyyət məlumatı üç halda sistemdən kənara çıxır: mühasibatlığa, arxivə və yoxlamaya.

Praktik qayda əvvəlki bölmələrdəki kimidir - **işlənəcəksə Excel, oxunacaqsa PDF**. Vacib olan isə mənbədir: export nüsxə olmalıdır, orijinal yox. Əks halda eyni ayın üç fərqli məzuniyyət siyahısı dolaşmağa başlayır.

Hesabatın hansı bloklardan ibarət olduğunu [davamiyyət hesabatı](https://qrgate.az/az/davamiyyet-hesabati) səhifəsində açmışıq.

## Praktik nümunə

70 nəfərlik marketinq agentliyində məzuniyyət müraciətləri e-poçtla gəlirdi. HR onları bir Excel faylına köçürür, şöbə rəhbəri ilə şifahi razılaşdırır və təsdiqi cavab məktubu ilə göndərirdi.

Sistem işləyirdi - iyul ayına qədər. Həmin ay bir şöbədə beş nəfərdən üçü eyni həftədə məzuniyyətə çıxdı. Səbəb kiminsə səhvi deyildi: müraciətlər müxtəlif vaxtlarda gəlmişdi və heç kim onları yan-yana görməmişdi.

Müraciətlər statuslarla birlikdə bir yerdə toplanandan sonra bu hal təkrarlanmadı. Amma daha faydalı nəticə başqa oldu: HR ilk dəfə növbəti üç ayın məzuniyyət mənzərəsini əvvəlcədən görə bildi və qrafik qurmağa vaxtında başladı. Qrafiklə davamiyyətin birgə idarəsini [iş qrafiki və davamiyyət](https://qrgate.az/az/is-qrafiki-ve-davamiyyet) səhifəsində yazmışıq.

## Qərar meyarı

Prosesinizi yoxlamaq üçün üç sual verin: müraciət hara gəlir; təsdiq gözləyən müraciətlər harada görünür; iyul ayında kimin məzuniyyətdə olacağını bu gün deyə bilərsinizmi?

Üçüncü suala cavab «yoxlamalıyam» olsa, məzuniyyət hələ də arxadan idarə olunan prosesdir - və planlaşdırma əvəzinə reaksiya üzərində qurulub.

## Təsdiq kimin səlahiyyətindədir

Praktikada ən çox yubadan detal texniki deyil: kimin təsdiq edəcəyi aydın olmayanda müraciət gözləyir.

İşləyən model iki pilləlidir. Birinci pillə birbaşa rəhbərdir - o, komandanın örtüyünü bilir və qərar üçün ən yaxın adamdır. İkinci pillə HR-dir və o, balans və qayda uyğunluğunu yoxlayır.

Bir pilləli model kiçik şirkətdə işləyir, amma komanda böyüyəndə HR bütün müraciətlərin darboğazına çevrilir.

Vacib olan pillələrin sayı deyil, hər pillənin *nəyə görə* qərar verdiyinin yazılı olmasıdır.

## Rədd cavabı necə verilməlidir

Bu, ən çox gərginlik yaradan və ən az düşünülən hissədir.

Rədd cavabı iki şey tələb edir: səbəb və alternativ. Səbəbsiz rədd komandada ədalətsizlik hissi yaradır, hətta qərar tamamilə əsaslı olsa belə.

Alternativ isə praktik məsələdir: «bu tarixlərdə mümkün deyil, amma həmin həftənin sonu mümkündür» cavabı prosesi davam etdirir, sadə «yox» isə onu dayandırır.

Praktikada rədd cavablarının yazılı saxlanması da vacibdir - həm tarixçə üçün, həm də eyni sualın təkrar verilməməsi üçün.

## Müraciətin gəlmə yolu da vacibdir

Təsdiq prosesinin keyfiyyəti çox vaxt onun ilk addımından - müraciətin necə daxil olmasından - asılı olur.

E-poçtla gələn müraciətin üç problemi var: siyahıya düşmür, statusu görünmür və axtarış çətindir. Mesajlaşma isə daha da pisdir - bir həftə sonra tapmaq praktiki olaraq mümkün olmur.

Vahid formanın faydası bürokratiya deyil, *tamlıq*dır: növ, tarix aralığı və səbəb əvvəlcədən doldurulur, ona görə təsdiq edən adam əlavə sual verməli olmur.

Praktikada bu, təsdiq müddətini bir neçə gündən bir neçə saata endirir - çünki gedib-gələn dəqiqləşdirmə yazışması aradan qalxır.

## Mövsümi yüklənməyə hazırlıq

Məzuniyyət müraciətləri il boyu bərabər paylanmır: yay ayları və bayram ətrafı həmişə pik olur.

Praktik həll müraciət pəncərəsini əvvəlcədən açmaqdır - məsələn yaz aylarında yay planını toplamaq.

Bu, təsdiqi asanlaşdırır, çünki müraciətlər yan-yana görünür və örtük problemi bir neçə ay əvvəldən həll olunur.

## Növbəti addım

Bu ay gələn məzuniyyət müraciətlərini sayın: neçəsi bir siyahıda görünür, neçəsi poçtda qalıb?

QRGate məzuniyyət və icazə müraciətlərini statusları ilə birlikdə davamiyyət konteksti içində saxlayır. [QRGate imkanlarına bax](https://qrgate.az/az/ustunlukler) və ya [qiyməti hesabla](https://qrgate.az/az).

## Tez-tez verilən suallar

### Təsdiqdən əvvəl hansı dörd sualın cavabı lazımdır?

Həmin tarixlərdə komandada örtük varmı, qrafik uyğundurmu, tarixlər bayrama və ya hesabat dövrünə düşürmü, bu il neçə gün istifadə olunub.

### Rədd edilmiş müraciəti saxlamağın nə faydası var?

Tarixçə üçün. Mübahisə yarananda «kim, nə vaxt və nə səbəbdən imtina etdi» sualının yazılı cavabı olur - bu qat ən çox laqeyd yanaşılan, amma ən çox lazım olanıdır.

### Məzuniyyət məlumatına neçə cür baxmaq lazımdır?

İki cür: əməkdaş üzrə (bu il nə qədər istifadə olunub) və tarix üzrə (iyulda kimlər yoxdur). Birincisi söhbətdən əvvəl, ikincisi qrafik qurarkən lazım olur.

### Təsdiq səlahiyyəti kimdə olmalıdır?

Adətən iki mərhələ işləyir: birbaşa rəhbər iş yükü baxımından, HR isə qalıq və sənədləşmə baxımından baxır. Bir mərhələli model kiçik komandada sürətlidir, böyük strukturda isə tez-tez ziddiyyət yaradır. Əsas şərt mərhələlərin sayı yox, kimin nəyə görə cavabdeh olduğunun yazılı olmasıdır.

## Əlaqəli səhifələr

- İş qrafiki ilə davamiyyət məlumatlarını… - [Markdown](https://qrgate.az/az/is-qrafiki-ve-davamiyyet.md) | [HTML](https://qrgate.az/az/is-qrafiki-ve-davamiyyet)
- Məzuniyyət və icazə sistemi - [Markdown](https://qrgate.az/az/mezuniyyet-icaze-idareetme-sistemi.md) | [HTML](https://qrgate.az/az/mezuniyyet-icaze-idareetme-sistemi)
- Elektron tabel sistemi nədir - [Markdown](https://qrgate.az/az/elektron-tabel-sistemi.md) | [HTML](https://qrgate.az/az/elektron-tabel-sistemi)
- İş qrafiki necə hazırlanır - [Markdown](https://qrgate.az/az/is-qrafiki-nece-hazirlanir.md) | [HTML](https://qrgate.az/az/is-qrafiki-nece-hazirlanir)
- Elektron iş qrafiki sistemi nədir - [Markdown](https://qrgate.az/az/elektron-is-qrafiki-sistemi.md) | [HTML](https://qrgate.az/az/elektron-is-qrafiki-sistemi)
- İşçi davamiyyət sistemi nədir və necə işləyir - [Markdown](https://qrgate.az/az/isci-davamiyyet-sistemi-nedir.md) | [HTML](https://qrgate.az/az/isci-davamiyyet-sistemi-nedir)