ایجاد یک پروژه نه چندان ساده

با سلام خدمت دوستان

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

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

بخش اول:

مراحل کلاسیک ایجاد دیتابیس: (رک http://office.microsoft.com/en-us/ac...#_Toc270678228 )

1- اطلاعات مورد نیاز و سازماندهی آنها

2- تقسیم اطلاعات در جداول مختلف

3- تعیین فیلدهای جداول

4- تعیین کلید اصلی جداول

5- ایجاد ارتباط بین جداول

6- اصلاح عیوب طراحی

7- نرمال سازی جداول

حالا به شرح هرکدام ازمراحل میپردازیم :

اطلاعات مورد نیاز:

مشخصات واحدها

دریافت ها

پرداخت ها

مبلغ شارژماهیانه

....................

خب دوستان میتوانند بحث را ادامه داده وکمک نمایند.

با سلام خدمت تمامی دوستان گرامی مخصوصاً جناب امیری عزیز که همیشه در ایجاد و گسترش مباحث مفید پیش قدم هستن

به نظر من میشه این پروژه رو به این شکل تحلیل کرد :

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

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

در جدول سوم نیز منبع و مبلغ در آمدها رو کنترل میکنیم و نحوه ارتباط دهی و کلید اصلی نیز همانند جدول دوم انجام میدیم

در ادامه میشه از طریق ایجاد کوئری و گزارشات، درآمدها و هزینه هارو مشخص کرد

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

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

به نام خدا
با سلام. با تشكر از آقا عباس اميري، اين برنامه به كار هاي ديگري هم مي خورد. خيلي از كسبه و اصناف حسابداري بلد نيستند يا حوصله ندارند. يك چيز ساده مي خواهند تا حساب روز و حساب چك هايشان را داشته باشد. درعين حال اين برنامه به ظاهر ساده مي تواند قابليت كار حرفه اي راهم بصورت دستي داشته باشد. درواقع پس زمينه اين برنامه يك حسابداري حرفه اي و اتوماتيك است.
به نظر من دو موضوعي كه در اين پروژه حل آنها مهم است يكي نحوه اختصاص حساب به مشتري پيش بيني نشده است. ديگر نحوه تنظيم سند حسابداري به شكل تركيبي است. منظورم اصطلاح سند مركب در حسابداري نيست. منظور اسنادي است كه مثلا يك بستانكار و چند بدهكار دارند.
يكي دونمونه قبلا در تالار بود. اگر پيدا كردم مي گذارم (يا اگر كسي دارد بگذارد)تا به عنوان (بقول امروزي ها) پايلوت(!؟) روي آن كار كنيم. يعني فكر مي كنم شرايط تالار طوري است كه با نمونه عيني بهتر مي شود كار كرد. انبار داري و سيستم تعمير و نگهداري شاهد من براي اين قضيه است. بقول آن دوستمان: ياعلي!

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

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

ممنون از جناب امیری بابت ارائه طراحی اولیه

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

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

نقل قول:

---

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

---

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

سلام
ایا جدول units نیاز به فیلدی جهت ارتباط با جدول blocks ندارد؟(مثلا blockid)

نقل قول:

---

ایا جدول units نیاز به فیلدی جهت ارتباط با جدول blocks ندارد؟(مثلا blockid)

---

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

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

با سلام دوباره
ازهمه موارد که بگذریم نحوه محاسبه شارژ بزرگترین چالش روبروست .
حالت های مختلف تعیین شارژ با توجه به مقتضیات مجتمع ها:
1 - همه واحدها مقدار یکسانی پرداخت میکنند
2 - برحسب ضریبی از متراژ واحدها ویا نفرات و یا ترکیبی از آنها
3 - برحسب رنج هایی از موارد قبلی مثلا از متراژ X تا Y فلان مبلغ و ....
4 - ویا اینکه بعضی واحد بنا بر ملاحظاتی مبالغ خاصی داشته باشند .

پیشنهاد دوستان چیست ؟
فعلا تعدادی از جداول را در فایل زیر آپلود میکنم تا دوستان هم موارد مورد نظر ویا نظرات خودرا اعلام نمایند

این هم فرمت 2003

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

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

نقل قول:

---

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

---

به نظرم رسید که با توجه به نوع عملیات محاسبات در یک مجتمع که شامل :
دریافت شارژ ار ساکنین
صرف شارژ در موارد مربوط به مسایل مشترک اعضا

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

نقل قول:

---

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

---

لذا با توجه به موارد فوق و راهکاری که استاد نبیل ارائه نمودند من به نظرم میرسه از این نوع ارتباط در جداول استفاده بشه راحت هست !

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

خدا نگهدار .

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

ضمن عرض سلام

نقل قول:

---

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

---

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

باتوجه مواردی که قبلا بحث شد حهت به سرانجام رساندن سریعتر تاپیک ، پاره ای موارد خدمت دوستانی که بحث رادنبال میکنند بعرض میرسد:

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

ضمیمه 92923

جدول شارژ جا ماند

ضمیمه 92924

با سلام مجدد

این پروژه قرار است چه کاری برای ما انجام دهد؟

ثبت مشخصات اشخاص

ثبت مشخصات واحدها

تعریف انواع هزینه

ثبت دریافت شارژ ازساکنین + نمایش اتوماتیک سال وماه شارژبعدی وهمچنین مبلغ شارژ باتوجه به تاریخ ماه وسال

ثبت پرداخت هزینه ها

گزارش وضعیت صندوق

گزارش حساب واحدها ( باتوجه به تغییرات نرخ شارژ از ابتدا تاکنون )

گزارش ونمودار هزینه ها

مقدار شارژ واحدها : چنانچه فیلد Subscription (شارژ) در جدول واحدها غیر صفرباشد از آن استخراج ودرغیر اینصورت از فیلد SubscriptionAmount ازجدول ChargeTable گرفته میشود.

در ثبتهای دریافت وپرداخت مانده حسابهای ثبت شونده وهمچنین صندوق نمایش داده شود.

حالا وقت اینست که دست بکار شوید وهنر خودرا به بقیه دوستان نشان دهید.

با سلام خدمت دوستانی که همراهی نمی کنند .

روالی که بنده درمورد محاسبه مانده حساب ساکنین مجتمع در نظرم است ، به این صورت است که مبلغ بدهکار: باتوجه به تاریخ ومبالغ ثبت شده در جدول ChargeTable ، توسط یک تابع تعداد ماههای بین تاریخهای متوالی ضربدر مبلغ شارژ، محاسبه و این مقادیر تاتاریخ جاری جمع وبرگردانده شود. و مبلغ پرداخت شده هم با جمع مبالغ پرداختی نقدو چک تا تاریخ جاری بدست می آید.

برای جلوگیری از درج اطلاعات اضافی درجدول ChargeTable چنانچه فیلد UnitID مقدار غیرصفرداشته باشد جهت آن واحد و درصورت صفر بودن جهت تمام واحدهایی که دراین جدول ، UnitID بنام آنها نیست.

جهت الگوریتم فوق حتما بایستی تمام تغییرات شارژ، چه عمومی وچه اختصاصی بادرج تاریخ در جدول ChargeTable ثبت شوند.

در همین رابطه تصویر جدول ChargeTable وبه همراه یک نمونه فرم ازآن در ذیل خواهدآمد.

ضمیمه 92979

https://barnamenevis.org/images/misc/pencil.png

اگه فيلدهاي هر جدولي رو با يک نام اختصاري بهش اختصاص بديم بهتره مثلا فيلد Tel که درتمامي جدول ها تکرار شده ... حالا ما براي مديريت بهتر در اطلاعات فيلدمون مخفف جدولمونو بياريم و پيشوند فيلدها قرار بديم مثلا جدول Persons از PrTel به جاي Tel استفاده کنيم و تمامي فيلدهاي اين جدول با پيشوند مخفف شده Pr شروع شوند يا در جدول Units ميشه UnTel ...

سلام دوباره

نقل قول:

---

براي مديريت بهتر در اطلاعات فيلدمون مخفف جدولمونو بياريم و پيشوند فيلدها قرار بديم مثلا جدول Persons از PrTel به جاي Tel استفاده کنيم و تمامي فيلدهاي اين جدول با پيشوند مخفف شده Pr شروع شوند يا در جدول Units ميشه UnTel ...

---

نکته ای دوست عزیزم ARData توضیح دادند بخصوص در کوئریهایی که از دوجدول با فیلدهای همنام استفاده شده است مفیدخواهد بود البته چنانچه قبل ازنام فیلد نام جدول بیاید مشکلی ایجاد نخواهدشد مانند Persons.Tel
به احتمال زیاد مجبورنخواهیم بود از کوئری با فیلدهای همنام استفاده کنیم . با اینحال از توصیه منطقی ایشان سپاسگزارم

در نمونه زیر روشی برای محاسبه مبلغ بدهکار واحدها (این غیراز مانده بدهکار است یعنی جمع ستون بدهکار) درست کرده ام که کمی پیچیده است حالا اگر دوستان راه آسان تری دارند ارائه دهند.
تابع CalcDebit در ماژول basCharge انجام اینکاررا بعهده دارد . با کمی تغییر میتوان ازآن ریز مقادیر را هم گرفت و درگزارش آورد.

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

با سلام

اگر درست متوجه شده باشم سر کار ما با واحد مسکونی و ساکنین آن است (که ممکنه خود مالک آن واحد ساکن باشه یا مستاجر او )
هر واحد مسکونی دارای یک مالک است مثل مشخصات دیگر .....شماره تماس و ...
1) به نظر من تفکیک این دو در جدول Units نیاز نیست برای نرمال سازی جداول میشه نظر داد ارتباط چند به چند بدون واسطه نمیشه تو جدول Persons همانطور که میبیندفیلد ID هم باOwner ارتباط داره و هم با PersonID ارتباط یک به چند !

2) سوال : چرا تو جدول هزینه ها برای پرداختها 2 فیلد نقد و چک منظور کردید CashAmount و ChequeAmount مگه این جدول با جدول CostTypes مرتبط نیست ؟

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

3) در مورد نحوه محاسبه شارژ قطعا دوستان نظر میدند به نظر من که روش جالبی بود منتها رابطه اش با جدولCash را متوجه نشدم اگه میشه راهنمایی کنید

با سلام دوباره
ضمن تشکر ویژه از توجه دوست خوبم عبدالرضا که از معدود کسانی است که دانسته ها وحتی ندانسته هایش را هم به اشتراک میگذارد و همگان میتوانند استفاده کنند .

نقل قول:

---

برای نرمال سازی جداول میشه نظر داد ارتباط چند به چند بدون واسطه نمیشه تو جدول Persons همانطور که میبیندفیلد ID هم باOwner ارتباط داره و هم با PersonID ارتباط یک به چند !

---

سوال خوبی است که شاید برای خیلی ها که نمی دانند اینجا جواب داده شود

برای ارتباط N گانه بین جداول با استفاده از جداول با نام مستعار استفاده میشود مانند, Persons_2, Persons_1 Persons_3، ......که در پنجره Relationships میتواند با درگ کردن مجدد جداول آنها را ایجاد کنید . به تصویر زیر توجه کنید:

ضمیمه 93108

نقل قول:

---

سوال : چرا تو جدول هزینه ها برای پرداختها 2 فیلد نقد و چک منظور کردید CashAmount و ChequeAmount مگه این جدول با جدول CostTypes مرتبط نیست ؟

---

CashAmountو ChequeAmountدر دوجدول Cash و Costs فقط برای تفکیک نوع وجه دریافتی ویا پرداختی است . CostType طبقه بندی هزینه است : برق عمومی ، سرایدار ،تمیزکاری و ...

نقل قول:

---

در مورد نحوه محاسبه شارژ قطعا دوستان نظر میدند به نظر من که روش جالبی بود منتها رابطه اش با جدولCash را متوجه نشدم اگه میشه راهنمایی کنید

---

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

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

من فلسفه وجود دو تیبل units و person رو نمی فهمم.
یک مدیر ساختمان معمولا با شارژ واحد های مختلف سرو کار دارد تا افراد. منظورم اینه که اینجا بیشتر واحد ها مهم هستند تا افراد داخل ان. و مشخصات افراد(اعم از شماره تماس و نام مالک) رو میشه داخل جدول واحد نیز اورد.

میشه در این باره کمی توضیح دهید.

و پیشنهاد میکنم که شماره یک واحد (unitID) بر اساس یک فرمت خاص که نشان دهنده شماره بلوک شماره طبقه و شماره واحد هست باشه.مثلا یک شماره 4 رقم اول نشان دهنده شماره بلوک دو رقم بعدی نشاندهنده شماره طبقه و رقم اخر نشان دهنده شماره واحد واقع در ان طبقه باشه.

با سلام خدمت تمامی دوستان و اساتید گرامی و به قول جناب امیری عزیز

نقل قول:

---

با سلام خدمت دوستانی که همراهی نمی کنند .

---

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

آیا برای این موضوع نیازی احساس نخواهد شد ؟ در صورت نیاز چگونه باید کنترل کرد ؟

به نظر من میتوان در یکی از جداول، روزهای خالی بودن واحد رو ذخیره کرد و به تناسب ، از مبلغ تعیین شده نهایی جهت شارژ ، کسر کرد.
میتوان این تناسب را نیز درصدی حساب کرد و نسبت به قوانین وضع شده در مجتمع اعمال نمود . مثلاً 10% از شارژ

نقل قول:

---

نوشته شده توسط hf.farhadi

با سلام خدمت تمامی دوستان و اساتید گرامی و به قول جناب امیری عزیز


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

آیا برای این موضوع نیازی احساس نخواهد شد ؟ در صورت نیاز چگونه باید کنترل کرد ؟

به نظر من میتوان در یکی از جداول، روزهای خالی بودن واحد رو ذخیره کرد و به تناسب ، از مبلغ تعیین شده نهایی جهت شارژ ، کسر کرد.
میتوان این تناسب را نیز درصدی حساب کرد و نسبت به قوانین وضع شده در مجتمع اعمال نمود . مثلاً 10% از شارژ

---

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

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

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

سلام
بهتر بود تاپیک جدید ایجاد می کردید
درفایلی که در پیام تان فرستاده بودید ، در جدول Order ویا OrderMaterial مشخص نبود کدام فیلد مربوط به Products است .
شما بایدبرای هر فیلدی که امکان تکرار موضوعی درآن وجود دارد جدول درست کنید . مثل Customers, Suppliers, , .... , ویا حتی اگر چنین نوع ماشین آلات دارید و هرمحصولی ممکن است باآن ساخته شود ، جدول مربوط به ماشین آلات.

و درجداول دیگر بجای نام این موجودیتها ، از ID آنها استفاده کنید

ضمیمه 101270

با سلام
یکی دو ماه پیش برای مجتمع مسکونی 40 واحدی ای که بنده در یکی از واحدهای آن سکونت دارم برنامه ای بر حسب نیاز مجتمع جهت مدیریت شارژ و تهیه گزارشات مالی تهیه کردم که تصاویری از قسمت های مختلف این برنامه رو در اینجا به نمایش میگذارم .
ضمناً نمایش تصاویر این برنامه به هیچ وجه جنبه تبلیغی ندارد,چون این برنامه برای فروش تهیه نگردیده است.

5 تصویر بعدی ...

تصویر بعدی ...

نقل قول:

---

نوشته شده توسط eb_1345

با سلام
یکی دو ماه پیش برای مجتمع مسکونی 40 واحدی ای که بنده در یکی از واحدهای آن سکونت دارم برنامه ای بر حسب نیاز مجتمع جهت مدیریت شارژ و تهیه گزارشات مالی تهیه کردم که تصاویری از قسمت های مختلف این برنامه رو در اینجا به نمایش میگذارم .
ضمناً نمایش تصاویر این برنامه به هیچ وجه جنبه تبلیغی ندارد,چون این برنامه برای فروش تهیه نگردیده است.

---

سلام و روز خوش

جناب بهرامی، بعد اون برنامه حسابداری (که نمیدونم چی شد تاپیکش) این دیگه رسما مایه شکستن دل فقرا و فرو بردن جوونا در یاس فلسفی هست!

نقل قول:

---

نوشته شده توسط mazoolagh

سلام و روز خوش

جناب بهرامی، بعد اون برنامه حسابداری (که نمیدونم چی شد تاپیکش) این دیگه رسما مایه شکستن دل فقرا و فرو بردن جوونا در یاس فلسفی هست!

---

سلام و عرض ادب جناب آقای مازولاق عزیز!
واقعیتش از شما چه پنهان , علت حذف اون تاپیک برنامه حسابداری در اوایل امسال این بود که احساس کردم خیلی دارم وقت خودم رو صرف کاری میکنم که بیشتر جنبه سرگرمی برام داره و ترجیح دادم بیشتر وقت خودم رو صرف امورات مهمتری بکنم ؛ به هممین خاطر از مدیر محترم تالار جناب آقای ميرزازاده گرامی خواهش کردم که تاپیک رو حذف نمایند ؛چون احساس کردم اینجوری دیگه وسوسه نمیشم که باز هم بر روی اون برنامه کار کنم .
تهیه این برنامه هم ببشتر بخاطر این بود که دیدم مدیر مالی قبلی ساختمان از طریق برنامه اکسل گزارشات حسابداری رو بصورت ناشیانه ای تهیه می کنه و همین کار باعث شده بود امور مالی ساختمان از شفافیت لازم برخوردار نباشه و صدای ساکنین دربیاد و مجبور شدم خودم دست بکار بشم و یک برنامه مالی درست و حسابی برای ساختمان تهیه کنم.