واحد حسابداری

هم اکنون در مرحله طراحی نرم افزار حسابداری قرار داریم . در اینجا در 3 مرحله اجزاء این نرم افزارو ارتباطات داخلی و خارجی آنها را با هم به نمایش در می آوریم .

1)      مرحله اول : طراحی نرم افزار

                                                   i.            طراحی لایه AcountingSoftwareServerComponent (خارجی ترین لایه) ونمایش ارتباطات این لایه با دیگر اجزای سیستم

                                                 ii.            طراحی لایه های زیرین لایه AcountingSoftwareServerComponent  که شامل 2 قسمت مجزا از هم هست .

ü      Client

ü      Server

   iii .  طراحی پکیج BusinessTier و جزء اصلی آن 

ü      AutomatedActivitiesComponent

2)      مرحله دوم : طراحی دیتابیس و جداول

ü      جدول سرفصل ها

ü      جدول سندها

ü      جدول ردیف های سند

ü      جدول دانشگاه

ü      جدول اساتید

ü      جدول کارمندان

ü      جدول دانشجو

ü      جدول درس

3)      مرحله سوم : طراحی Interface  برنامه

مرحله اول : طراحی نرم افزار

این نرم افزار در دسته بندی نرم افزار های سازمانی ( ENTERPRISE ) قرار می گیرد . به همین دلیل یک معماری چند لایه مخصوص این گونه نرم افزارها را برای آن اعمال می کنند .

بخش 1-1) طراحی لایه AcountingSoftwareServerComponent

این لایه خارجی ترین لایه نرم افزار است و به کمک این لایه ارتباطات کلی با بقیه سیستم برقرار می شود .

پکیج موجود در این لایه با 7 Interfase  دیگر در ارتباط است .

• KhabgahInterfase
• AmoozeshInterfase
• OmooreTaghzieInterfase
• EdariInterfase
• Hesab4KhabgahInterfase
• Hesab4AmoozeshInterfase
• Hesab4EdariInterfase

ابن Interfase ها در واقع یک رابطی بین سیستم یا برنامه ما با دیگر اجزای سیستم هستند.4 Interfase  اول مربوط به سیستم های خوابگاه ، آموزش و تغذیه است ( که نرم افزار ما فقط از آنها استفاده می کند ، وظیفه طراحی آن ها بر عهده ما نیست) ولی 3 Interfase  دیگر را واحد حسابداری برای سیستم های خوابگاه ، آموزش و تغذیه طراحی کرده است .در شکل 1-1 میتوانید لایه countingSoftwareServerComponen

را که با UML  طراحی شده است مشاهده بفرمایید.

شکل 1-1 

 UML لایه AcountingSoftwareServerComponen

 بخش 1-2) طراحی لایه های زیرین لایه AcountingSoftwareServerComponent 

 این لایه به 2 بخش کلی تقسیم می شود.

ü      Client

§         GUI Component

§         BusinessTier Component

§         DateTierInterfase

§         BusinessTierInterfase

ü      Server

§         DataTier Component

§         DataBase Component

بخش Client

GUI Component : مسئول نمایش اطلاعات و ارتباط با کاربر است .

BusinessTier Component : مسئول ایجاد Object  های مربوط به فصای مسئله و ارتباط آنها با هم می باشد. طراحی  کامل این بخش  در قسمت بعد به طور مجزا آورده خواهد شد .

DateTierInterfase :  مشخص کننده سرویس هایی که لایه DataTier   به سرویس های بالاتر از خودش ارائه می کند.

BusinessTierInterfase : سرویس هایی را که لایه BusinessTier  به لایه GUI  می دهد را مشخص می کند .

 بخش Server

DataTier Component : کارش ارتباط با دیتابیس ، ذخیره و بازیابی اطلاعات برای لایه بعدی .

DataBase Component : دیتا بیس نرم افزار است . در شکل (1-2) میتوانید UML  این لایه را مشاهده کنید .

 DataTier Component و DataBase Component معمولا تنها در سرور پیاده سازی می شوند و بقیه  Client  ها با داشتن لایه GUI  و BusinessTier  از سرویس های لایه DataTier  موجود در سرور استفاده می کند .

یک معماری چند لایه دارای خواص زیر است

·        باعث می شود تا بتوان لایه های مختلف که سرویس های یکسانی را ارائه می دهند جایگزین یکدیگر کرد . مثلا :لایه DataTier می تواند لایه BusinessTier  را به دیتابیس  SQL  متصل کند ، و یا می توانیم DataTier  ای را که BusinessTier  مارا به دیتابیس Oracel  وصل می کند و دارای همان Functionality  است جایگزین کنیم .

·        در صورت اعمال تغییر در برنامه حداکثر 2 لایه تحت تاثیر تغییرات قرار می گرد و دامنه تغییرات گسترده نمی شود و این باعث کمتر شدن هزینه تغییرات و کمتر شدن هزینه تغییرات و کمتر شدن تعداد مشکلات برنامه  که در اثر تغییرات ایجاد می شوند ، مثلا : اگر فیلدی به دیتابیس برای اعمال همزمانی اضافه شود ، حداکثر لایه DataTier  تغییر می کند و تغییرات به لایه های بالاتر کشیده نمی شود .

·        پیمانه ای شدن برنامه : که باعث می شود بتوان برنامه را بین گروه های برنامه نویس مستقل برای توسعه ، طوری تقسیم کرد که به کمترین میزان ارتباط نیاز باشد و هر گروه تنها مسئول لایه ای است که بر روی آن کار می کند و تنها نیاز دارد از سرویس های لایه پایین تر خود مطلع باشد.

شکل 1-2

UML لایه های زیرین لایه AcountingSoftwareServerComponent

بخش 1-3) طراحی پکیج BusinessTier اجزاء اصلی آن 

 

این بخش دارای 5 Component  اصلی است ، در شکل 1-3 نیز می توانید طراحی پکیج BusinessTier  را به کمک UML مشاهده بفرمایید.

 

• ReportsComponent : وظیفه ارائه انواع گزارشات مالی را بر عهده دارد .
• DocumentsComponent : وظیفه ارائه خدمات مربوط به سند زدن ، ایجاد ، ویرایش ، حذف ، جستجو در بین اسناد را بر عهدا دارد .
• SarfaslsComponent  : وظیفه آن ایجاد سرفصل ، ویرایش ، حذف ، جستجو درسرفصل هاست
• BankDocsDocument : وضیفه آن، ایجاد ، ویرایش ، حذف ، جستجو در بین  اسناد بانکی پرداختی و دریافتی است .
• AutomatedActivitiesComponent  : این بخش ( بخش فعالیت های اتوماتیک ) مهمترین بخش این قسمت است، در ادامه به وظایف این بخش و چگونگی ارتباط این واحد با بقیه سیستم را شرح می دهیم و پروسیژرهای لازم را  پیاده سازی می کنیم .

 

بخش فعالیت های اتوماتیک (AutomatedActivitiesComponent ) :

 

این بخش مسئول انجام عملیات های زیر است :

1.      مسئول ایجاد سند بر اساس اطلاعات فصای مسئله

2.      مسئول محاسبه پرداختی دانشجویان در ترم هر ترم

3.      مسئول صدور چک اساتید

4.      مسئول محاسبه حقوق کارمندان

 

 

 بخش OmooreTaghzieInterfas

                        

از این بخش برای کسب اطلاع از میزان بدهکاری دانشجو در ترم پیش استفاده می کند .

به کمک این پروسیژر با فرستادن شماره دانشجویی و تاریخ مورد نظر می توان میزان بدهی دانشجو را مشخص کرد.

Public int64 ReturnPayment (String studentId , DateTime fromdate

, DateTime todate) ;

 

بخش Hesab4AmoozeshInterfase

 

در بخش Hesab4AmoozeshInterfase یک پروسیپری طرح ریزی شده که با گرفتن شماره دانشجویی و تاریخ مورد نظر لیست دروس انتخابی دانشجو به همراه ریز جزئیات قیمتهای لیست انتخاب واحد ، قیمت شهریه ، قیمت تغذیه ترم پیش و قیمت خوابگاه را به ما بر می گرداند.

 

Public int64 ReturnGheimat (String StudentId , Ilist ListEntekhabVahed , byraf string Details) ;

 

این پروسیژر برای اعلام تائیدیه پرداخت پول توسط دانشجو ، برای واحد آموزش استفاده می شود.

Public bool HasPayed(String StudentId );

 

بخش AmoozeshInterfase

 

این بخش دارای یک پروسیژر است که به کمک آن میزان مبلغ پرداختی به اساتید را در بازه زمانی معین به ما بر می گرداند.

 

Public int64 ReturnPayment( int TeacherId , DateTime Fromdate

,DateTime Todate);

 

بخش KhabgahInterfase

 

این بخش دارای یک پروسیژر است که به کمک آن میزان مبلغ قابل پرداخت توسط دانشجو در بازه زمانی معین برای استفاده از خوابگاه را ما بر می گرداند.

 

Public int64 ReturnPayment( int TeacherId , DateTime Fromdate

,DateTime Todate);

 

بخش Hesab4KhabgahInterfase

 

این بخش دارای یک پروسیژر است که به کمک آن می توان تائیدیه پرداخت پول خوابگاه توسط دانشجو را به واحد خوابگاه  بر  گرداند.

 

Public bool HasPayed(String StudentId );

 

بخش EdariInterfase

 

این بخش دارای یک پروسیژر است که به کمک آن می توان با وارد کردن 2 تاریخ به عنوان بازه زمانی مورد نظر جدول حقوق کارمندان را به عنوان خروجی دریافت کرد.

 

Public DataSet GetPersonalsSalery(DateTime Fromdate

,DateTime Todate);

 

بخش Hesab4EdariInterfase

 

این بخش دارای یک پروسیژر است که به کمک آن می توان امکان انجام تمام عملیات های مورد نیاز برای گزارش گیری را در اختیار واحد اداری قرار داد . این پروسیژر فیلدی برای مشخص کردن نوع گزارش ، دو فیلد برای بازه زمانی و 2 فیلد برای مشخص کردن دامنه شماره سند های مورد جستجو و فیلدی برای وارد کردن شماره سرفصل دارد که بنا بر نوع گزارش درخواستی این فیلدها پر می شوند.

 

Public DataSet GetReport(ReportType rt

, DateTime Fromdate ,DateTime Todate 

, int FromDocCode , int ToDocCode

, String SarfaslCode);

 

بخش های جانبی

در این بخش امکان تعریف کارکنان مختلف با سطح دسترسی های متفاوت وجود دارد.

  

شکل 1-3

طراحی پکیج BusinessTier به کمک UML

مقدمه

ابتدا مقدمه اي كوتاه در باره روال كاري حسابداري و پروسه هاي آن ارايه مي دهيم .

در يك مجموعه يا سيستم ،براي ثبت و نگه داري كليه خريد و فروش ها و معاملات اي كه در آن سيستم روي داده واستفاده از اين اطلاعات براي استخراج سود و زيان و ميزان طلبكاري و بدهكاري سيستم،  نياز به رعايت و پيروي ازيك سري اصول و قواعد خاصي است كه اين نيازباعث به وجود آمدن مبحثي به نام حسابداري مي گردد.

پس  ابتدا در مورد چگونگي ثبت و نگه داري بك معامله در سيستم حسابداري و ابزارها و پروسه هاي موجود توصيحاتي ارائه ميكنيم (بخش 1-1) در ادامه(بخش 1-2) به استخراج اطلاعات از اين داده ها خواهيم پرداخت .

بخش 1-1    تعيين سرفصل ها  

يك معامله بين دو طرف صورت ميگيرد ،طرفين مي توانند اشخاص حقيقي يا حقوقي ، سازمان ها ، نهادها ، يا هر گونه موردي كه بتوان برايش موجوديت در تظر گرفت باشند.براي ثبت يك معامله و  براي دسته بندي بهتر معاملات صورت گرفته ،براي هر يك از  طرفين معامله كد يا شناسه اي در نظر گرفته مي شود كه همان كد سر فصل نام دارد، كه تعيين اين كد و اختصاص دادن آن به هر موجوديت اولين و مهمترين كار براي آغاز يك ثبت معامله به شمار مي رود. در واقع ثبت یک معامله فقط با ذکر شماره سرفصل دو طرف معامله انجام می شود.

سرفصل ها به سه زیر مجموعه کلی تقسیم می شوند : سرفصل هاي كل ، سرفصل هاي معين ،  سرفصل هاي جزء يا تفصيلي . سرفصل های کل اختصاص کدهای  3 رقمی به یک سری از موجودیت های کلی طرف معامله است ، مثلا کلیه بانکها ( کشاورزی، ملی ، ... ) کلیه شعب ( همه شعب همه شهرها ) را با یک کد 3 رقمی 111 مشخص می کنیم . سر فصل معین یک مرحله ریز تر شده و وارد شاخه ای جزء تر می شود و یک کد 2 رقمی به هر کدام اختصاص می دهد . مثلا کلیه بانک های کشاورزی کد معین آنها  01 111 است بانک های ملت 11102 است.

سرفصل های جزء آخرین مرحله از تعیین سرفصل ها هستند و با تعیین دقیق مشخصات آن واحد طرف معامله  یک کد 3 رقمی هم به آن اختصاص می دهند.مثلا بانک کشاورزی شعبه کشاورز دارای سرفصل کلی   001 01 111  است یا بانک ملت شعبه قیطریه سرفصل کلش 004 02 111 است.

نكته مهم در اينجا اين است كه موجوديتي با نام صندق وجود دارد كه در واقع جاي گزين جيب شخص هم مي تواند باشد . در حسابداري براي پولي كه به جيب  كسي ريخته مي شود يا از جيب كسي برداشت مي شود هم يك كد سرفصل تعلق ميگيرد.

بخش 1-2  سند زدن

دومين پروسه مهم در ثبت معامله سند زدن است . كليه معاملات صورت گرفته بايد در يك سند ثبت گردند . در اين سند هر معامله ( يك طرف پولي داده ، طرف ديگر پولي گرفته) به اين صورت به ثبت مي رسد كه يك سطرمتعلق به كسي است كه پولي پرداخت كرده و سطري ديگرمتعلق به شخصي است كه پولي دريافت كرده.

دريافت كننده پول را با ذكر كد سرفصل خود و ذكر مبلغي كه دريافت كرده (در ستون بدهكار) ومبلغ صفرريال در ستون بستانكار وارد مي كنيم .

پرداخت كننده پول را نيز با ذكر كد سرفصل خود(مثلا صندوق ، شخص حقيقي، حساب بانكي) و ذكر مبلغي كه پرداخته  (در ستون بستانكار) ومبلغ صفرريال در ستون بدهكار وارد مي كنيم .

ممكن است در يك سند (در يك معامله) پرداخت كننده 1 نفر ولي گيرنده چندين موجوديت متفاوت و با كد سر فصل هاي مختلف باشند ، در اينجا به هر گيرنده يك سطر تعلق مي گيرد و ميلغ دريافتي هر كدام نيزبه صورت جدا ذكر مي شود.در جدول 2-1 مي توانيد سند خوردن يك معامله را مشاهده بكنيد.

 نكته مهم اين است كه جمع كل ستون هاي بستانكاربا بدهكاربايد بايد صفرشود.

نمونه يك ترازنامه

توصیحاتی در باب DFD منطقی سطح یک

این DFD منطقی دارای 3 زیر سیستم است که در 3 بخش به توضیح آنها می پردازیم .

1)      واحد بررسی اسناد مکتوب

2)      واحد حسابداری اتوماتیک ( نرم افزار حسابداری )

3)      واحد ارائه اسناد غیر اتوماتیک

بخش 1-1  واحد بررسی اسناد مکتوب

ورودی ها  :

ü      فرم تسویه حساب از دانشجو

ü      فرم پرداخت جریمه کتابخانه از دانشجو

ü      فیش پرداخت بانکی از دانشجو

ü      فاکتورها از واحد اداری

ü      ترازنامه از واحد حسابداری اتوماتیک ( نرم افزار حسابداری )

خروجی ها :

ü      فرم تسویه حساب  تایید شده به دانشجو

ü      فرم پرداخت جریمه کتابخانه تائید شده به دانشجو

ü      سند حسابداری به واحد حسابداری اتوماتیک ( نرم افزار حسابداری )

ü      اطلاعات موجود به پایگاه داده داده های مکتوب

این واحد یک client  ازserver  اصلی ما( واحد حسابداری اتوماتیک ، نرم افزار حسابداری) است .در واقع این واحد دارای یک interface  است که به برنامه حسابداری وصل است و می تواند از ابزارها ی موجود در آن استفاده کند .

این واحد در این زیر سیستم وظیفه بررسی مدارک و اسناد دستی را بر عهده دارد.اسناد دستی توسط شخص ( نه شبکه داخلی سیستم ) به این واحد تحویل داده می شود ، این واحد بعد از بررسی آنها یا آنها را تائید میکند یا برای آنها سند می زند یا اینکه درپایگاه داده ذخیره می کند .

ارتباط با واحد دانشجو:

پروسه پرداخت جریمه کتابخانه: فرم پرداخت جریمه کتابخانه را به همراه فیش پرداخت بانکی را از دانشجو گرفته و با مقایسه مبلغ قید شده در فیش پرداختی با مبلغ قابل پرداخت درفرم جریمه کتابخانه ، اقدام به تائید فرم جریمه کتابخانه می کند .

پروسه تسویه حساب از دانشجو:  فرم تسویه حساب از دانشجو گرفته شده برای تائید این فرم باید ترازنامه را از واحد حسابداری اتوماتیک دریافت کند وبه کمک میزان ترازنامه دانشجو متقاصی تسویه حساب ( اگر میزان تراز نامه برای آن دانشجو  صفر باشد  دانشجو و دانشگاه بی حساب هستند) که فرم تسویه حساب داده است، فرم را تائید می کند .

ارتباط با واحد تدارکات

پروسه سند زدن : واحد تدارکات که یکی از زیر مجموعه های  واحد اداری است ، فاکتورهای خرید های خود را به واحد بررسی اسناد مکتوب میدهد ، این واحد بعد از بررسی اولیه این فاکتورها ( چک کردن موجودی با لیست خریدها و فاکتورها ی موجود) برای واریزپول فاکتورها به حساب تنخواه ، اقدام به سند زدن برای خریدها میکند. که بعدا در واحد ارائه اسناد غیر اتوماتیک به کمک این سند ها پول به حساب تنخواه واریز گردد.

این واحد فیش های بانکی رسیده را در پایگاه دادهای مکتوب  بایگانی می کند .

بخش 2-1  واحد حسابداری اتوماتیک ( نرم افزار حسابداری )

ورودی ها :

ü      هزینه کل تغذیه دانشجودر ترم پیش از واحد تغذیه

ü      سند حسابداری از واحد بررسی اسناد مکتوب

ü      اطلاعات قرارداد اساتید از واحد آموزش

ü      لیست انتخاب واحد دانشجو از واحد حسابداری

ü      اطلاعات رزرو خوابگاه از واحد خوابگاه ها

ü      سند حسابداری از واحد ارائه اسناد غیر اتوماتیک

ü      لیست دریافتی کارمندان از واحد اداری

خروجی ها :

ü      ترازنامه به واحد واحد بررسی اسناد مکتوب

ü      مبلغ قابل پرداخت برای انتخاب واحد دانشجو به واحد آموزش

ü      تائیدیه پرداخت وجه انتخاب واحد به آموزش

ü      تائید پرداخت برای رزرو به واحد خوابگاه

ü      اطلاعات اسناد حسابداری در پایگاه داده مربوطه

ü      ترازنامه به واحد واحد ارائه اسناد غیر اتوماتیک

ü      چک چاپ شده اساتید به واحد ارائه اسناد غیر اتوماتیک

ü      گزارشات مالی به امور اداری

ü      سند موقت به واحد ارائه اسناد غیر اتوماتیک

این واحد واحدی است که قرار است توسط گروه نرم افزاری پیاده سازی شود ، این قسمت یک نرم افزار حسابداری است که بوسیله شبکه داخلی دانشگاه اطلاعات را دریافت و خروجی این واحد نیز بر روی شبکه داخلی قابل دریافت است .

واحد حسابداری اتوماتیک ( نرم افزار حسابداری ) به کمک سند هایی که در واحدبررسی اسناد مکتوب وارد سیستم شده است تراز نامه هایی تنظیم و به واحد ذکر شده ارائه می کند . این سند ها هم برای دانشجویانی که پول به حساب دانشگاه واریز کرده اند صادر شده است و هم برای فاکتورهای خریدی که واحد اداری انجام داده است.

ارتباط با واحد های تغذیه ، خوابگاه و آموزش

پروسه محاسبه مبلغ ثبت نام دانشجو:از طریق شبکه داخلی هزینه کل تغذیه دانشجو در انتهای ترم قبل ( از واحد تغذیه ) وهزینه خوابگاه رزرو شده در ترم جاری ( از واحد خوابگاهها) ولیست  واحد های نتخابی دانشجو( ازواحد آموزش ) به این واحد فرستاده شده و این واحد با انجام پروسه زیر کل مبلغ قابل پرداخت توسط دانشجو را برای ثبت نام در ترم جاری  محاسبه و به واحد آموزش می فرستد .

   ابتدا مبلغ قابل پرداخت برای مجموع واحد های انتخابی دانشجو را با توجه به جدول قیمت دروس که در دیتابیس نرم فزارحسابداری موجود است ، محاسبه کرده  و سپس میزان شهریه ثابت دانشگاه  راکه این اطلاعات نیزدر جدولی در دیتابیس نرم افزار قابل دستیابی است  به آن اضافه کرده ،   هزینه کل تغذیه دانشجو در انتهای ترم قبل وهزینه خوابگاه رزرو شده در ترم جاری را هم با این مجموع واحد ها جمع و به عنوان مبلغ قابل پرداختی توسط دانشجو به آموزش می فرستد.

 آموزش وظیفه مطلع کردن دانشجو از مبلغ قابل پرداخت را برعهده دارد . دانشجو بعد از پرداخت پول ، فیش بانکی را به واحد بررسی اسناد مکتوب تحویل میدهد . این واحد برای آن دانشجو سندی در سیستم وارد می کند، واحد حسابداری اتوماتیک به کمک این سند،  تائیدیه پرداخت وجه دانشجو را به واحد آموزش می فرستد. 

مبلغ قابل پرداخت= (هزینه خوابگاه)+(هزینه کل تغذیه ترم قبل)+(شهریه ثابت دانشگاه)+(جمع  واحدهای انتخابی)

ارتباط با واحد اداری

پروسه تولید گزارشات :واحد حسابداری اتوماتیک  برای واحد اداری  دارای خروجی هایی است  مثل ترازنامه های جزء ، ترازنامه های کل ، دفتر کل، دفترمعین ،میزا ن کل بدهی ها و بستانکاری های دانشگاه ، میزان دارایی های دانشگاه و غیره

 این گزارشات به کمک سندهایی که در بخش های زیر ثبت شده اند امکان پذیر است.

ü      سند هایی که برای پرداخت وجه ثبت نام دانشجو ثبت شده 

ü      سندهایی که برای فاکتورهای خرید(توسط واحد تدارکات)و واریز به حساب تنخواه آن واحد ثبت شده

ü      سند هایی که برای پرداخت حقوق کارمندان دانشگاه توسط واحد حسابداری اتوماتیک  ثبت شده

ü      سند هایی که برای پرداخت مالیات ثبت شده

ü      سند هایی که برای پرداخت حقوق اساتید ثبت شده

ارتباط با واحد ارائه اسناد غیر اتوماتیک

پروسه ثبت سند غیر قطعی : این واحد برای انجام پروسه پرداخت حقوق کارکنان و اساتید و پروسه پرداخت وجه مالیات و بیمه به ادارات مربوطه در 2 مرحله این پروسه ها را انجام می دهد .

درابتدابه کمک  لیست دریافتی حقوق کارکنان ( از واحد اداری) واطلاعات قرارداد اساتید ( از واحد آموزش) 

یک سند موقت برای هر کدام از کارکنان و اساتید به مبلغ ذکر شده در لیستهای حقوق و قراردادها ثبت میگردد ، دراین سند ها سطر مربوط به کارمندان یا اساتید خالی می ماند تا بعدا که  توسط واحد ارائه اسناد غیر اتوماتیک وجه حساب کارمندان وارزشد یا چک به نام اساتید صادر شد این سطر پر شود و سند قطعی شود.در جدول 2-1 می توانید نمونه سند غیر قطعی را ببینید .

نمونه سند غیر قطعی

بخش 3-1   واحد ارائه اسناد غیر اتوماتیک

ورودی ها :

ü      چک چاپ شده اساتید از واحد حسابداری اتوماتیک

ü      ترازنامه از واحد حسابداری اتوماتیک

ü      سند موقت از واحد حسابداری اتوماتیک

خروجی ها :

ü      اظهار نامه مالیاتی به اداره مالیات

ü      چک حق التدریس به اساتید

ü      واریز در حساب تنخواه به بانک

ü      واریز در حساب کارمندان به بانک

ü      واریز در حساب بیمه به بانک

ü      واریز به حساب مالیات به بانک

این واحد نیز یک client  از server  اصلی ما( واحد حسابداری اتوماتیک ، نرم افزار حسابداری) است .در واقع این واحد دارای یک interface  است که به برنامه حسابداری وصل است و می تواند از ابزارهای موجود در آن استفاده کند .

ارتباط با واحدهای اداره مالیات ، اساتید و بانک

پروسه پرداخت حق الزحمه اساتید و کارکنان و سازمانها : این واحد در این زیر سیستم وظیفه ارائه اسناد غیر اتوماتیک را بر عهده دارد.این واحد با دریافت سند های موقت و ترازنامه ها از واحد حسابداری اتوماتیک و مقایسه آنها  ( در صورت صفر نبودن تراز این سندها ی موقت ) میتواند طرف افراد یا سازمانهایی را که دانشگاه باید به آنها پولی پرداخت کند را مشخص کند.

بعد از مشخص شدن این واحد ها و میزان قابل پرداخت به هر کدام ، واحد ارائه اسناد غیر اتوماتیک  اقدام به پرداخت وجوه میکند ، برای اساتید چک صادر می کند و به دست آنها می دهد و برای سازمانهای بیمه و مالیات به حساب بانکی آنها پول واریزمیکند و برای پرداخت حقوق کارمندان نیز وجه حقوق آنها به حساب بانکی آنها در بانک واریز می شود. البته بعد از پرداخت یا واریز وجه سند های موقت را کامل کرده ( سند ها را قطعی می کند).

این واحد اظهار نامه های مالیاتی را برای اداره مالیات پر میکند و برای آنها می فرستد .

 در زیرDFDسطح 1 منطقی را می توانید مشاهده بفرمایید .

در لینک زیر هم می توانید تصویر DFD سطح یک را مشاهده کنید.

 http://aycu25.webshots.com/image/2224/1735101089285640627_rs.jpg

ارتباط واحد های مختلف با واحد حسابداری:

واحد تغذیه:

این واحد در طول ترم به دانشجویان خدمات خود را ارائه کرده ، در ازای هر گونه خدمات ارائه شده در طول یک ترم مبلغ تمام شده خدمات را برای هر دانشجو جمع کرده ، مبلغ نهایی را که باید دانشجو بپردازد به همراه اطلاعات دقیق آن دانشجو از قبیل نام ، نام خانوادگی ، شماره دانشجویی و شماره شناسنامه را ، از طریق شبکه داخلی دانشگاه  به واحد حسابداری  اطلاع میدهد تا این واحد هم در ابتدای ترم بعدی در هنگام ثبت نام دانشجو این مبلغ را به هزینه ثبت نام ترم جاری اضافه کند.

واحد خوابگاه :

 قبل از شروع ترم دانشجویان با مراجعه به واحد خوابگاه اقدام به رزرو جا در خوابگاه می کنند . با ثبت نام در واحد خوابگاه مبلغ قابل پرداخت توسط  دانشجو مشخص می شود . همانند روش ارتباط واحد تغذیه با حسابداری در اینجا هم  مبلغ نهایی را که باید دانشجو بپردازد به همراه اطلاعات دقیق آن دانشجو ، از طریق شبکه داخلی دانشگاه  به واحد حسابداری  اطلاع میدهد تا این واحد در ابتدای همان ترم (بر خلاف واحد تغذیه که در انتهای هر ترم تسویه حساب انجام می شد) در هنگام ثبت نام دانشجو این مبلغ را به هزینه ثبت نام ترم جاری اضافه کند.

واحد آموزش :

دانشجو بعد از انجام عملیات مربوط به انتخاب واحد ،  واحد آموزش مبلغ نهایی و قابل پرداخت برای واحد های انتخایی و شهریه دانشجو را به او اعلام ، این مبلغ هم مانند مبالغ ارائه شده توسط واحد تغذیه و واحد خوابگاه به همراه اطلاعات دقیق آن دانشجو ، از طریق شبکه داخلی دانشگاه  به واحد حسابداری  اطلاع میدهد دانشجو با مراجعه به واحد حسابداری از جمع همه مبالغ قابل پرداخت مطلع شده و جمع این مبالغ را که شامل هزینه های خدمات گرفته شده از واحد تغذیه در ترم قبل ، هزینه ثبت نام خوابگاه برای ترم جاری و هزینه مربوط به انتخاب واحد و شهریه این ترو می باشد را به بانک پرداخت و فیش بانکی خود را به واحد حسابداری تحویل میدهد.

واحد اداری :

 واحد حسابداری انواع گزارشهایی را که واحد اداری( ریاست) درخواست  می کند به این واحد ارائه میکند. علاوه بر این طبق وظایف تعریف شده واحد حسابداری ، این واحد باید به طور منظم گزارشهایی مثل گزارش  یک سال کاری به صورت خلاصه ازهزینه ها ، مالیات ها ، اموال ، ... در پایان هر سال به عنوان تراز نامه به واحد ریاست ارایه دهد و تهیه این ترازنامه یکی از مهمترین وظایف واحد حسابداری به شمار می آید.این تراز نامه برآورد دقیقی از میزان دارایی های دانشگاه که شامل میزان حساب های بانکی ،ملک و املاک و مستغلات و ما شین آلات و... است می باشد. همچنین میزان بدهی های دانشگاه از سازمان ها و دانشجویان و همچنین بدهکاری های خود دانشگاه به دیگر مکان ها را نیز مشخص می کند یک گزارش ماهانه نیز به عنوان تراز آزمایشی به واحد ریاست ارایه می شود.که این گزارش زیرمجموعه ای از تراز نامه سالیانه به حساب می آید.

این واحد لیست همه کارکنان دانشگاه را به همراه میزان حقوق ماهیانه  آنها ، میزان تشویقی کارکنان ، مزایا ، حق عا یله مندی ، کسری بیمه ، کسری مالیات ، حق ماموریت ، اضافه کاری را به واحد حسابداری تحویل داده و این واحد هم در انتهای هر ماه میزان وجهه قابل پرداخت هریک از کارکنان خود را به حساب بانکی آنها واریز می کند.

واحد تدارکات هم که زیر مجموعه واحد اداری است  ، تعامل خود را با واحد حسا بداری به صورت زیر انجام میدهد

واحد تدارکات لیست خرید های انجام شده ، هزینه های پرداختی و غیره را به همراه فاکتور خریدها  را به صورت دستی تحویل واحد حسابداری می دهد و این واحد هم پول هزینه شده توسط واحد تدارکات را به حساب تن خواه تدارکات واریز می کند

واحد کتابخانه:

ارتباط واحد حسابداری با کتابخانه ، به منظور پرداخت جریمه توسط دانشجویان ، به ازای تاخیر در تحویل کتاب به امانت گرفته در مهلت مقرر می باشد .ارتباط این دو واحد بر خلاف ارتباط های موجود در این سیستم به صورت دستی و به واسطه دانشجو می باشد . دانشجو فرم جریمه را از واحد کتابخانه گرفته پس از پرداخت به بانک ، فیش آن را به واحد حسابداری ارائه می کند ، این واحد هم در صورت تطابق مبلغ ذکر شده درفیش جریمه با  فیش پرداختی ، تا ییده خود را اعلام کرده  ، فیش تایید شده توسط دانشجو به واحد کتابخانه تحویل داده می شود.

در جلسه اعضای گروه مقرر شد که ادامه کار در چند بخش ادامه یابد:
1. رسم DFD منطقی نهایی در تمامی سطوح موجود با توجه به مشخص شدن نحوه ارتباط بخشهای مختلف سیستم.
2. شروع فاز طراحی در سه بخش
a. طراحی مدل مورد استفاده سیستم
b. طراحی نرم‎افزار در سطح مؤلفه ها و واسط (Interface) های مورد نیاز برای ارتباط با واحدهای دیگر.
c. طراحی واسط گرافیکی کاربران (GUI)