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

[ali_kolahdoozan]

سوالم فقط مربوط به #c نیست و میتونه به تمام winapp ها که می خواهند تحت شبکه کار کنند مربوط میشود و اما مشگل و سوال من


یک فاکتور داریم که دیتابیس طبق معمول mster/detail تعریف میگردد . اما این برنامه باید بره روی شبکه و تحت یک lan با حداقل 15 سیستم به صورت client کار کند . خوب تا اینجا هم مشکلی نیست و اما ما در interface برنامه یک شماره فاکتور و ... داریم که مربوط میشوند به جدول به اصطلاح master ما . حالا بحث اینجاست که من وقتی کاربر قصد ثبت نهایی داره برای کل فاکتور اول رکورد جدول مستر رو میزنم و بعد با استفاده از id آن رکورد detail رو پر میکنم . اما قبل از زده دکمه ثبت نهایی من به کاربر به عنوان شماره فاکتور چی نشون بدم . نمی تونم شماره آخرین رکورد زده شده در master رو نشون بدم . چون ممکنه قبل از ثبت نهایی بقیه کلاینتها زودتر یک یا چند رکورد بزنن بره و اینجاست که من مجبورم قبل از ثبت نهایی هیچ شماره ای به عنوان شماره فاکتور نشون ندم یا راهی هست؟

[SalarSoft]

اولین نظر و ساده ترین راه شاید نشون ندادن شماره فاکتور باشه، ولی خب نشون دادن اون لازم به نظر می رسه!

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

[ali_kolahdoozan]

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

[rezamim]

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

[iman_s52]

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

[hrshojaei]

سلام ، به نظر منم نشون دادن شماره فاکتور از اول لزومی نداره مثل سیستم مکاتبات اداری که شماره اندیکاتور نامه ها بعد از تایید نهایی اختصاص پیدا می کنه اما اگه مهمه که شماره فاکتور از اول نشون داده بشه می تونی آمار بگیری که تعداد فاکتور های ابطالی در روز چند تا است و چه نسبتی از کل فاتورهای صادر شده داره . یعنی فاکتورهایی که قبل از ثبت نهایی Cancel میشه . اگه این نسبت کمه ، خوب می تونی شماره فاکتورو در هنگام شروع صدور فاکتور رزرو کنی و Lock باشه ، بعد همون شماره رو بهش بدی . ایراد کار اینجاست که اگه فاکتور Cancel بشه اون شماره از بانک اصطلاحا سوخت میشه و این شاید توی سیستمهای مالی برای پیگیریهای بعدی کار جالبی نباشه . یادمه سر کلاس SQL SERVER 2005 استاد پیشنهاد می کرد که هیچ چیزیو از بانک DELETE نکنید بلکه یک فیلد اضافه کنید که نشون بده اون رکورد پاک شده . بهتره برای شماره های سوخت شده هم یه ردی توی بانک که نشون بده توسط کدوم اپراتور سوخت شده باشه ، یعنی یه log کوچیک داشته باشه .

[Ghasem Dehghani]

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

در بانک اطلاعاتی مربوط به فاکتور هم یک فیلد اضافی به نام کد کارمند را ایجاد کنید با این کار هر وقتی که خواستید فاکتور جدید را ایجاد کنید کد کارمند را به آخرین شماره فاکتوری که توسط همین کارمند ایجاد شده رو میخونید و بهم میچسبونید و به عنوان شماره فاکتور نشون میدین .
این کار دارای محاسن زیر میباشد :
1- فاکتورهای ایجاد شده توسط هر کارمند قابل شناسایی است .
2- هیچ اختلالی در هنگام ایجاد شماره فاکتور به وجود نمی آید چون فاکتور ایجاد شده توسط هر کارمند با کد همان کارمند درهم آمیخته است و یک شماره کاملا منحصر به فرد را وجود آورده است .
3- و هر فاکتور دارای شماره منحصر به فرد است .

برای مثال اگر کارمندی دارای کد 100 باشه و آخرین فاکتور صادر شده توسز این اربر 1200 باشه شما میتونید به این صورت شماره فاکتور رو نشون بدین : 1200-100
بهتره در هنگام ذخیره شماره فاکتور یک - هم بذارین تا تشکیل یک عدد تک ندهد چون ممکنه در مرور زمان مثلا کارمند با کد 1001 بخواهد فاکتور 200 را ایجاد کند که اگر علامت - را نگذارید ممکن
است به شکل روبرو درآید 1001200 که تشخص این فاکتور با مثال بالا ممکن نخواهد بود .
موفق باشی .

[SalarSoft]

این کار دارای محاسن زیر میباشد :
1- فاکتورهای ایجاد شده توسط هر کارمند قابل شناسایی است .
2- هیچ اختلالی در هنگام ایجاد شماره فاکتور به وجود نمی آید چون فاکتور ایجاد شده توسط هر کارمند با کد همان کارمند درهم آمیخته است و یک شماره کاملا منحصر به فرد را وجود آورده است .
3- و هر فاکتور دارای شماره منحصر به فرد است .
موفق باشی .

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

[rezamim]

رنجشی نبود دوست عزیزم

[Ghasem Dehghani]

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

و باعث رنجش شما و یا سایر دوستان شده صمیمانه و از صمیم قلب معذرت خواهی میکنم . برای نشون دادن حُسن نیتم مطلبم رو ویرایش کردم لطفا شما هم با بزرگواری در متن فوق تجدید نظر کنید .
با آرزوی موفقیت برای همه دوستان به خصوص آقای rezamim .
برادر کوچک شما Ghasem Dehghani .

[Sorenaa_s]

من 2 تا راه برای حل این موضوع پیشنهاد می کنم:
1. برای حل مشکل شماره فاکتور، شماره های فاکتور رو بصورت AutoNumber در نظر نگیرید، بلکه همیشه آخرین مقدار رو در یک Table دیگر نگهدارید، هر بار که به شماره فاکتور جدیدی نیاز دارید رکورد حاوی آخرین شماره فاکتور رو Lock کرده، آخرین شماره را گرفته، یکی به آن اضافه کرده و بعد UnLock کنید. در زمانیکه شما رکورد رو Lock کردید بقیه درخواستها برای گرفتن شماره فاکتور در حالت Wait می مونن.
2. برای حل مشکل Concurrency در بقیه موارد از ّTimeStamp استفاده کنید، تو DataBase تو Table ها تون یه فیلد از نوع TimeStamp بگیرید، همونطور که می دونید با هر بار Update شدن یک رکورد، مقدار فیلد TimeStamp تغییر می کنه. زمان Update کافیه که شما چک کند که مقدار TimeStamp شما کمتر از مقدار در Table نباشد.

[ali_kolahdoozan]

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

[Sorenaa_s]

دوستان اگر شماره دستی باشه ...

منظورتون از دستی چیه؟!!!

[mobtady]

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

[ali_kolahdoozan]

این آخری با وجود دردسر و اینکه به ذهن خودم هم رسیده بود بد نیست . اما اگر بعد کنسل کرد چی؟ یعنی فاکتور رو ثبت نکرد . و بقیه بعد از اون عدد فاکتور زدند ترتیب میخوره به هم

[iman_s52]

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

[ali_kolahdoozan]

خوب اگر موقت نکرد و پاک کرد چی؟

[iman_s52]

دیگه یا باید اون شماره رو بی خیالش بشی یا اونو از لیستت یه جوری ورش داری؟؟؟؟؟
اگه ش فاکتور رو بذاری که دستی هم باشه کاربر می تونه بیاد ش فاکتور رو رو دستی تنظیم کنه و شماره جا افتاده رو وارد کنه و صادر

[ali_kolahdoozan]

و اما ادامه داستان فاکتور روی شبکه

کاربر A از روی سیستم خودش شروع می کند به وارد کردن کالا به فاکتور در اینجا لازم به ذکر است که هر کالا باید راست موجودیش بشه از انبار برداشت کرد نه بیشتر . خوب حالا A موجودی رو میرسنونه به 0 و B وقتی می خواهد جنس وارد کند میببینه موجودی نداره و نمیزنه بعد A بیخیال فاکتور میشه و کنسل میکنه و همه چیز برمیگرده اینجا با توجه به سیاست بعضی موسسات مبنی بر فروش بیشتر حقوق بیشتر به B ظلم شده و A هم که فاکتور رو کنسل کرده . حالا باز میشه موقع ثبت کلی موجودی رو چک کرد و هشدار داد . یا حتی تا قطعی نکرده از موجودی کم نکرد که در این صورت ممکنه تا میاد قطعی کنه موجودی 0 بشه و A ضایع بشه . اما باز هم همین منطق قطعی کردن و بعد کسر موجودی و موقع قطعی کردن چک کردن موجودی از بقیه بهتر است . اما به صورت کلی باز اینجا ضایع بازی رخ میده . رئیس موسسه استفاده کننده به من میگه برنامه رو شما گفتید تحت شبکه فلان قیمت اما این اصلا یه برنامه دیگس . همه منطقهاش فرق داره . و این داره خراب کاری به بار میاره


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

[rezamim]

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

[jome ramezani]

و اما ادامه داستان فاکتور روی شبکه

در این صورت ممکنه تا میاد قطعی کنه موجودی 0 بشه و A ضایع بشه .

با سلام
اکه سیستم را مانند آنچه در زیر است تعریف کنی کاربر A ضایع نمگردد

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

مثال
کالای D به تعداد 5 عدد در انبار است
کاربر A به تعداد 5 عدد از کالای D را در یک فاکتور ثبت موقت میکند
کاربر B به تعداد 5 عدد از کالای D را در یک فاکتور ثبت موقت میکند(زیرا موجوید آن 5 است ثبت موقت Aتاثیر در تعداد Dنگذاشته است)
کاربر C به تعداد 5 عدد از کالای D را در یک فاکتور ثبت نهایی میکند

پس هیچ کدام از کاربران A و B نمی توانند فاکتور خود را ثبت نهایی کنند زیرا کاربر C موجودی کالا را صفر کرده است

بنابراین کاربر A ضایع نمگردد