انجمن‌ها

سلام

مطلب بسیار خوب و مفید است.

نکته قابل توجه اینکه در کل سیستم سعی شده بین تعاریف و داده‌ها تمایز قائل شویم - مواردی مثل فرم‌ها یا شیوه‌ها که فرمودید، عملا تعاریف هستند و همراه داده‌ها صادر نمی‌شوند - همانطور که فرمودید به صورت مستقل صادر می‌شوند.

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

برخی از داده‌ها هم اصولا قابل درج در XML نیستند (بدون تبدیل ساختار) مثل یادداشت حساب که به خاطر یک لوس‌بازی در ابتدای پیاده‌سازی سیستم، Rich Text هستند. شرح‌های استاندارد هم جا افتاده و احتمالا در نسخه بعدی اضافه می‌کنیم. ارتباط تفصیلی با دفتر تلفن هم احتمالا در نسخه بعدی اضافه خواهد شد. هر دو مورد "فرض" هستند و باید بیشتر بررسی کنم.

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

رسیدها هم موجودات مستقلی نیستند و فقط برگه‌های ضمیمه برای اسناد هستند و به همین دلیل هم به صورت مستقل قابل صدور نیستند و به همراه اسناد صادر می‌شوند.

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

به جرئت عرض می‌کنم که تولید یک تصویر XML از اطلاعاتی که در یک پایگاه اطلاعاتی با کمک SQL Server مدیریت می‌شود، با حفظ 90 درصد روابط و با امکان یافتن مراجع مناسب و حالا هم که با مسیر حرکت داده مارپیچی سخت‌ترین کاری بوده که تا به حال انجام داده‌ام. خدا به سر شاهد است که هر وقت روی این داستان کار می‌کنم، شبها خواب Node و Tag می‌بینم و به خصوص Nodeهای سرگردانی که در زیر سرگروه مناسبشان درج نشده و در کل XML شناور هستند. مسیر حرکت مارپیچی هم که خاطرتان هست؛ درخواست از یک سیستم به سیستم دیگر بروی، در آنجا تحویل شود و به سیستم اول (یا سیستم سوم) بازگردانده شود و پس از فراخوانی درخواست اولیه پاس شود - و شبیه همین داستان برای تمام جاهایی که از ارتباط رخدادها استفاده شده است.

از پست مفید شما هم کمال تشکر را دارم

ارادت

سلام

نکته‌ای هم در مورد اسناد دریافت و پرداخت و انبار به نظرم رسید

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

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

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

ارادت

سلام

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

ممنون