انجمن‌ها

سلام

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

شاید واقعا اشکال از مرورگر باشد.

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

سلام

آنچه ما در اختیار داریم ارتباط حساب با تفصیلی‌ها است + ارتباط حساب‌ها و تفصیلی‌ها با بخش‌ها

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

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

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

معلوم است که فرمایش شما به صورت لفظی به معنی اختیاری بودن تفصیلی نیست؛ اما همین‌که برای یک حساب در برخی شرایط باید تفصیلی درج شود و در برخی شرایط نباید درج شود از دید سیستم به این معنی است که حساب برخی از موارد دارای تفصیلی و در برخی موارد فاقد تفصیلی است و این "به صورت دقیق و از روی کتاب تعریف موردی است که در آن درج تفصیلی برای یک حساب اختیاری است".

حالا شما هر چه بفرمایید ما در حد توان و در چارچوب تعریف‌های فوق در خدمتیم.

از طرف دیگر بنده در زمینه مالی صاحب‌نظر نیستم اما یک چیزی را خوب یاد گرفته‌ام و از آنجا که برای کار سیستمی ما هم خیلی مطلوب است خوب در ذهنم مانده است: ثبات رویه.

ارادت مضاعف

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

ممنون از لطف شما

سلام

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

اینکه "در سند برای بخش 1 تفصیلی از ما میخواهد که با آن بخش ارتباط ندارد" به این دلیل است که در جایی که تفصیلی اختیاری است، می‌خواهید به زور تلفیقی را اجباری کنید. توضیح هم در بخش‌های قبلی داده شده است.

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

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

باز هم اگر راه حلی دیگری به نظر شما می‌رسد بفرمایید تا در خدمت باشیم.

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

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

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

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

ارادت