برامج و حلول محاسبية ب SQL SERVER

شكرا لك أخي

PATCH DEVELOPER

كنت أقصد أن accountid هو رقم الحساب و في نفس الوقت مفتاح رئيسي و طالما أنه

مساو تمتا للــ leftextent في كل الأوقات أليس من الممكن القول إن الحسابين

1001 - 1001 - 1001

1001 - 1001 - 1006

يمكننا التعبير عنهما كا التالي

1001 - 1001

1001 - 1006

و يمكن القول أن الحساب الأول رقمه 1001 و حده الأيسر 1001 و حده الأيمن 1001

و هو حساب فرعي

أما الحساب الثاني رقمه 1001 و حده الأيسر 1001 وحده الأيمن 1006

و بهذه الطريقة يمكن الاستكفاء بعمود واحد و كذا يمكن من اختصار الكود الموضوع في ال trigger

فلا يهمنا أن Accountid=leftextent

أما إذا كان عندك فكرة أخرى غير التي فهمتها أنا فأرجو التوضيح

و الملاحظة الثانية

و لكن لما لا تواصل الإبحار في الموضوع

ختى نستفيد منالمعلومات التي معك

السلام عليكم و رحمة الله و بركاته

أخي الكريم عارف مرة أخرى أرد على تساؤلاتك

اقتباس

كنت أقصد أن accountid هو رقم الحساب و في نفس الوقت مفتاح رئيسي و طالما أنه

مساو تمتا للــ leftextent في كل الأوقات أليس من الممكن القول إن الحسابين

1001 - 1001 - 1001

1001 - 1001 - 1006

يمكننا التعبير عنهما كا التالي

1001 - 1001

1001 - 1006

و يمكن القول أن الحساب الأول رقمه 1001 و حده الأيسر 1001 و حده الأيمن 1001

و هو حساب فرعي

أما الحساب الثاني رقمه 1001 و حده الأيسر 1001 وحده الأيمن 1006

و بهذه الطريقة يمكن الاستكفاء بعمود واحد و كذا يمكن من اختصار الكود الموضوع في ال trigger

فلا يهمنا أن Accountid=leftextent

أخي الكريم أولاً أود أن ألفت نظرك إلى شئ مهم هو أنك وقعت في فخ و لبس عليك الأمر

فأولاً لا يمكنني أن أدخل في الجدول accounts حساب رقمه 1001 و حده الأيسر 1001 و حده الأيمن 1001 و في نفس الوقت تدخل حساب أخر رقمه 1001 و حده الأيسر 1001 و حده الأيسر 1006 لماذا ؟ لأنك كررت المفتاح الرئيسي هنا و على ذلك فإنك عندما تكرر رقم الحساب هنا لن تقبله قاعدة البيانات و سوف تظهر عندك رسالة خطأ

و بالتالي أخي الكريم لن يمكنك الأستغناء عن الحد الأيسر و الحد الأيمن و الذين مهمتهما الرئيسية تحديد ما إذا كان هذا الحساب فرع أم مجموعة و أهمية أخرى لهم هو تحديد الهرمية التي تكلمنا عنها و عدم تداخل الأختصاصات و ذلك بأستغلالهم في الأجراء القادح الذي ذكرته سابقاً

أما بالنسبة للأستفسار الثاني و هو

اقتباس

و الملاحظة الثانية

و لكن لما لا تواصل الإبحار في الموضوع

ختى نستفيد منالمعلومات التي معك

أخي الكريم عارف سوف أحاول أن أبذل جهدي في سبيل ذلك و لكن هذا الموضوع موضوع كبير فأنا قبل أن أكتب أي مقال أو مشاركة أتوخى الحذر و أحاول أن أرجع إلى مراجعي العلمية و المحاسبية لكي تكون المعلومة دقيقة قدر المستطاع ،

و على كلاً لو كان لك أي طلب يتعلق بموضوعنا أنا تحت أمرك في أي توضيح تريده حتى تصل المعلومة إلى ذهنك و هذا لك و لغيرك من إعضاء هذا المنتدى

و أشكرك على مشاركتك و أسألتك

و السلام عليكم و رحمة الله و بركاته

أنا ضربت مثالا و أخذت الحسابين من ردك السابق

و الذي فيه

(و بالتالي لا تخلط بين وظيفة ACCOUNTID التي هي مفتاح رئيسي في الجدول ACCOUNTS و بين إدوات تعريف مدى الحساب و هما الحقلين LEFTEXTENT و RIGHTEXTENT فمثلاُ عندما نقول أن لدينا حساب رقم تعريفه هو 1001 و أن الحد الأيسر له هو 1001 و الحد الأيمن له 1001 فإن هذا يعبر عن أن هذا الحساب فرع ، و لو قلنا أن الحساب 1001 الحد الأيسر له 1001 و الحد الأيمن له 1006 فأننا نقول أن هذا الحساب مجموعة مداها من الحساب 1001 إلى الحساب رقم 1006

)

هذا هو نص كلامك و كان قصدي الحساب الأول يفهم منه كذا لو وجد في قاعدة البينات

مثلا و أنا قصدت من هذا الكلام أنه لو وجدنا في قاعدة البيانات حساب و كان رقمه 1001 و حده الأيمن 1001 مباشرة أقول أن الحساب مداه من 1001 إلى 1001

و لو كان الحساب رقمه 1001 و حده الأيمن 1006 معنى هذا أن مداه من 1001 إلى 1006

و إلا كمفهوم من قاعدة بيانات لا يمكن أن يوجد حسابين بنفس الرقم خاصة و أن الرقم

primary key

و شكرا

السلام عليكم و رحمة الله و بركاته

أخواني عارف و نشوان أسف للتأخر عليكم و لكني إن شاء الله سوف أرد على مداخلاتكم في أقرب فرصة إن شاء الله

و السلام عليكم و رحمة الله و بركاته

السلام عليكم و رحمة الله و بركاته

أخي الكريم عارف

حقيقة تفكيرك منطقي فعلاً و أنا سوف أسير معك بنفس المنطق و سوف أفرض مثال للبت في هذا المنطق كالتالي :

رقم الحساب أسم الحساب الحد الأيمن

1001 الأصول 1015

1002 الأصول المتداولة 1005

1003 النقدية 1003

1004 البنوك 1007

1005 بنك القاهرة 1005

الأن سؤالي أنا لك و للسادة القراء هل من طريقة لضبط التداخلات بين مجموعات الحسابات ؟

ارجو منكم المحاولة لضبط التداخلات في ضوء المعطيات السابقة

محلوظة : يوجد تداخل بين مجموعة البنوك و مجموعة الأصول المتداولة

أنا سوف أكون في أنتظار مشاركتكم يا أخواني فلقد جاء دوركم للتفكير ولكن أرجو أن يكون التفكير بصوت عالى و على مرئى من قراء هذا المقال

أخي الكريم نشوان

ألم يحن الوقت للتصميم على أس كيو أل سيرفر ؟الرجاء أعادة تصميم تصميمك على أس كيو أل سيرفر مع توضيح المخططات و عدم الخلط بين الجزئيات التالية :

الجزئية الأولى : والتي نحن في صدد تصميمها هنا هي خاصة باليومية العامة أو مايسمى GL و هي سوف تكون بمثابة الأدارة المركزية في النظام بالكامل

الجزئية الثانية : العملاء

الجزئية الثالثة : الموردون

الجزئية الرابعة : المخزون

الجزئية الخامسة : الموارد البشرية

فأرجو منك أخي الكريم تفهم ذلك مع إعادة تخطيطاتك بأستخدام SQL DIAGRAM حيث سوف تكون العلاقات واضحة

أما بالنسبة للسادة قراء المقال الأعزاء :

نحن هنا لسنا في أكاديمية أو جامعة بحيث أن السيد الدكتور يتكلم و يصف و أنتم فقط تنصتون ، نحن هنا في معمل للتجارب فلا تستحوا من عرض تصميماتكم حتى و أن كانت بدائية فنحن سوف نعرض تصميماتنا هنا و مقترحاتنا و كلاً منا سوف يعدل في تصميمه و يعرضه بعد التعديل لكي يستفيد منه الأخرون .

و أشكركم جزيلاً

و أنا أعتذر منكم لتغيبي الفترة السابقة لأنشغالي بدراسة بعض المشاكل المحاسبية

و السلام عليكم و رحمة الله و بركاته

أولا أشكر الأخ patch developer على رده لي

أما بالنسبة للتداخلات سبق و أن وضعت لها حلا في ال Trigger الذي و ضعته مسبقا والذي يحتاج لتعديل بسيط حتى لا تتداخل الحسابات مع بعضها البعض

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[TempoA]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[TempoA]


CREATE TABLE [dbo].[TempoA] (
[AccountID] [int] NULL ,
[ParentAccount_Node] [int] NULL ,
[RightExtent] [int] NULL 
) ON [PRIMARY]

insert into dbo.tempoa (accountid,parentaccount_node,rightextent)
select accountid,parentaccount_node,rightextent from accounts where parentaccount_node = @parentacc and accountid<>@account and leftextent<>rightextent

declare tempoa_crsr cursor
forward_only
keyset
for select accountid,parentaccount_node,rightextent from dbo.tempoa open tempoa_crsr
fetch next from tempoa_crsr into @accountcr,@parentacccr,@rightextentcr while (@@fetch_status<>-1)
begin if (@@fetch_status<>-2)
begin if @accountid> @accountcr and @rightextent >= @rightextentcr
begin update accounts
set rightextent = @account
where accountid =@account
end
fetch next from tempoa_crsr into @accountcr,@parentacccr,@leftextentcr,@rightextentcr end
end
close tempoa_crsr
deallocate tempoa_crsr

إذا في خطأ أرجو التوضيح

السلام عليكم

اود ان اطرح مداخلة بسيطة فيما يخص تساوي الحد الايسر مع رقم الحساب

قد يكون منطقيا ان تكرار المعلومة في الجدول الواحد غير مرغوبة ونقوم لذلك بعمليات ال NORMALIZATIONS

للتخلص من التكرارات ولكن ليس امرا اجباريا ففي بعض الاحيان يكون التكرار محببا لتسهيل استخراج تقرير معين أو لوجود تعريفين مختلفين لمعلومة واحدة تجري عليها اختبارات مختلفة فيمكن تكرار المعلومة في الحقول لتسهيل عمل الكود اللازم ولكي يصبح مقروء اكثر

وغيرها من الاسباب التي قد يرى المصمم تكرار الحقل في نفس الجدول أو في جداول اخرى

وليس من المنطقي ان نستمر في هذه الجزئية لان الطريقتين في اعتقادي صحيحة

والاهم من ذلك ان ينظر الميرمج في الشروط الاربعة التي اوردها الاخ حميد ويعيها تماما

اقتباس

1-@leftextent = @account

هل الحد الأيسر يساوي رقم الحساب - فهذه هي قاعدة أساسية من القواعد التي فرضناها سابقاً

2-@rightextent < @prightextent

هل الحد الأيمن أقل من الحد الأيمن للحساب الأب - للتأكد أن المدى لن يمتد لأبعد من المدى المخصص للحساب الأب

3-pleftextent-@prightextent <>0

هل الحد الأيمن للأب - الحد الأيسر للأب لا يساوي صفر و هذا طبعا للتأكد من أن هذا الحساب ليس حساب طفل أو فرع

4- @rightextent>=@leftextent

هل الحد الأيمن أكبر من أو يساوي الحد الأيسر ( يجب أن أنوه أن علامة يساوي في الكود المدرج في المشاركة رقم 5 لم تدرج )

وفيما يخص انشاء قائمة حسابات بطريقة المجموعات وحتى لايحدث تداخل بينها فان وجود حساب رئيسي اب للجميع من الضرورات الاجبارية وبالتالي فاني اقترح ان يكون هذا الحساب رقم صفر ويكون مدخل في القاعدة اجباريا ولايمكن حذفة من قبل المستخدم ويمثل هذا الحساب حساب المنشأة بشكل عام

وانا متشوق جدا لمناقشة الموضوعين التالييين الذين اوردهما الاستاذ حميد لانهما بحسب خبرتي السابقة من القضايا الشائكة التي يمكن ان يناقشها المبرمج مع المحاسبين العاديين و تسبب له صداع متواصل

اقتباس

أولا : هل سنعتمد نظام أقفال سنوي بشكل مبرمج ؟

ثانيا : هل سنعتمد أستراتيجية للترحيل الحسابي و الأرشفة ؟

ملحوظة : يوجد نظام محاسبي مفتوح المصدر ومعرب من قبل مبرمج مصري ومكتوب بلغة PHP وقواعد بيانات MYSQL ويسمى النظام OPEN-ACCOUNT على ما اذكر

اقتباس

ألم يحن الوقت للتصميم على أس كيو أل سيرفر ؟الرجاء أعادة تصميم تصميمك على أس كيو أل سيرفر مع توضيح المخططات و عدم الخلط بين الجزئيات التالية :

الجزئية الأولى : والتي نحن في صدد تصميمها هنا هي خاصة باليومية العامة أو مايسمى GL و هي سوف تكون بمثابة الأدارة المركزية في النظام بالكامل

الجزئية الثانية : العملاء

الجزئية الثالثة : الموردون

الجزئية الرابعة : المخزون

الجزئية الخامسة : الموارد البشرية

فأرجو منك أخي الكريم تفهم ذلك مع إعادة تخطيطاتك بأستخدام SQL DIAGRAM حيث سوف تكون العلاقات واضحة

استاذي العزيز حميد ولا يهمك إن شاء الله سوف اقوم بنقل التصاميم الى SQL SEV

رغم اني افضل التصميم في الـ VISIO لسهولة التعديل وكتابة الملاحظات وغيرها

وإن شاء الله ((سأتفهم))واقوم بابعاد الجزئيات الخاصة بالانظمة الفرعية

وأسفين جدا

السلام عليكم و رحمة الله و بركاته

أخواني الكرام

أكثر ما كان يقلقني في الفترة الأخيرة هو أن نعمل كلاً في وادي و بشكل غير منسق و لكن أعتقد الأن بعد أن وجدت أخوة لنا مجتهدون مثل الأخ نشوان و الأخ عارف قد تشجعت لكي أعرض عليكم ماهية التنسيق الذي أقترحة للأستمرار في هذا الموضوع الهام

أولا أنا أقترح على كل من يشارك في الموضوع أستخدام الصور لتوضيح الرسومات التوضيحية diagrams التي يصمم عليها تصميمه و سوف نمشي في أتجاهات مختلفة فأنا لا أريد أن أفرض تصميمي و لكن سوف يكون الهدف واحد ، كيف يكون الهدف واحد كأن نفرض أن هدفنا الأولي هو عمل حل لليومية العامة و هذا ما نعمل عليه الأن ثم يأتي مثلاً أخ لنا مثل نشوان فيقدم لنا تصميمه مع أرفاقه في صورة deattached database في zip file فإن كان لدي تعديل فسوف أعدل في نفس التصميم و أعرض التعديل الذي أراه و أشرح وجهة نظري مثلما فعل الأخ عارف بارك الله فيه

الأن تخيلوا معي لو ذادت عدد المداخلات من هذا النوع البناء و كل شخص يرى في نفسه أنه قادر على عرض تصميم أفضل سوف يدرجه و يشرح وجهة نظره ، أعتقد أن النتيجة سوف تكون مبهرة و سوف يكون هذا الموضوع مبهر للغاية و مرجع لكل من يريد أن يستزيد من هذا الفرع من العلم

و الأن لكي نطبق هذا المفهوم أرجو من أخونا عارف أن يحمل أخر تعديل لي على تصميمي ثم يعدل فيه التعديل الذي رأه و يغير في الجدول accounts ثم يغير في الأجراء القادح لضبط عدم تداخل المجالات ثم يجربه و أن واجهته مشكلة يكتب إلينا و سوف نساعد في حل المشكلة بإذن الله و يعرض صور للتصميم بعد التعديل ثم شرح الإجراء القادح بعد التعديل حتى تتسنى الأستفادة الكاملة للسادة قراء المقال

و أخونا نشوان طبعاً نحن في أنتظار تصميمه و سوف نحاول مناقشته و لكن بعد التعديلات الازمة عليه

و أخيراً رداً فقط على أخي نشوان عن أستراتيجة الترحيل و الأقفال سوف أوجز هنا لأن لي تصوراً قد وضعته مسبقاً للتعامل مع ذلك

ما هو أقفال السنة المالية ؟

أقفال السنة المالية (بالنسبة لجانب تصميم قواعد البيانات ) : هو تصفير كافة حسابات الأيرادات و المصروفات و جعلها صفر فسوف تجد في تصميمي ما يجعلنا أن نميز بين ما هو إيراد أو مصروف ،، هل تتخيل معي ؟

و حقيقة يجب أن نملك إدوات معينة كتحديد أين سوف يكون حساب الارباح و الخسائر الذي سوف تقفل فيه الأيرادت و المصروفات و طبعاً عندما نصل إلى هذه النقطة و نناقشها فسوف يكون هناك تعديل في قاعدة البيانات لكي نجعلها تناسب هذا الغرض

أما بالنسبة لعملية الترحيل : فهي عملية روتينية و أهم ما يهمنا فيها هو أننا يجب أن نحددها قبل الدخول في مرحلة الأستعلامات حيث أني يجب أن أبني جداول أخري مماثلة للجدولين JournalVoucherHeadr و TransactionsDetails ثم سوف يجب أن نقوم ببناء إجراء مخزن لحذف عدد معين من الصفوف من جداول الأدخال و أضافة نفس الصفوف لجدول القيود المرحلة

نعم إن عملية الترحيل ما هي إلا عملية حذف و عملية أضافة ، حذف في جدول و أضافة في جدول مماثل

و لماذا قلت أني يجب أن نحددها هنا قبل عملية الأستعلامات لأن القيود هنا سوف تكون مقسمة على نوعين من الجداول نوع سوف يستقبل القيود الغير مرحلة و نوع أخر مماثل سوف يستقبل القيود المرحلة و هنا يتعين علينا أستعمال الدالات الجدولية أو tabular functions و سوف نستخدم الخاصية union لتجميع البيانات بين نوعي الجداول المتماثلة و سوف تقوم الأستعلامات على هذه الأستراتيجية

سوف نأتي للحديث عن ذلك إن شاء الله في وقته و بالتفصيل العملي إن شاء الله

و أشكركم

أخوكم

الأخ نشوان

نحن لا نريد أن نتوقف عند هذه الجزئية لاننا لا نريد الاستمرار

و يعلم الله كم أنا مشتاق للاستمرار في الموضوع و لكن

يجب أن نبدأ من الأول بداية سليمة لتكون قاعدة البيانات سليمة

و لا أقصد أن الأخ قصر فيها لكن طول الTrigger مما جعله صعبا حتى للفهم

و هو قد طلب منا أن نحاول الاختصار

و أنا فكرت بهذه الطريقة طالما أن العمودين هما نفس بعض فلما لا نوفر طلب فحص العمودين هل هما نفس القيم أم لا

خاصة و أن استبعاد هذا العمود سيقلل مرات الفحص من 16 حالة إلى 8 حالات

ألستم معي في هذا الموضوع

أما الأخ فيكفيه شرفا أن بدأ فكرة الموضع التي لم نكن لنراها في هذا المنتدى

و أرجو منكم المعذرة لأني سأتغيب عنكم لفترة لأني سآخذ إجازة حتى يوم الأحد

مع خالص شكري للجميع

السلام عليكم و رحمة الله و بركاته

أخي الكريم عارف

اقتباس

الأخ نشوان

نحن لا نريد أن نتوقف عند هذه الجزئية لاننا لا نريد الاستمرار

و يعلم الله كم أنا مشتاق للاستمرار في الموضوع و لكن

يجب أن نبدأ من الأول بداية سليمة لتكون قاعدة البيانات سليمة

أنا أشكرك على توضيحك و أنا أحترم رأيك بشدة و لكن كيف لك أن تحكم أن قاعدة البيانات التي بنيتها في مرحلتها السابقة ليس لها بداية سليمة ؟

على كلاً أنا لا أعرف أسبابك و لكني أيضاً أحترمها مقدماً ، و لكن أخي الكريم أنا كانت لي رؤية معينة حتى عندما وضعت الأجراء القادح الذي قلت أنه طويل كانت لي رؤية معينة و أنا أقولها لك أنا لم أصمم أي مقطع من مقاطع قاعدة البيانات بدون تخيل كيف سوف تكون الأستعلامات التي سوف تبنى عليها ، و الأخ نشوان بارك الله فيه قد وضع لنا هنا طريقة أخرى لضبط عدم تداخل المجالات و هي تبنى على وضع حقل لتحديد المستويات رغم أنه لم يضبطها برمجيا و لكن هو وضع الأدوات المساعدة لذلك و هو حقل المستوى .

ما كان يهمنى عند وضعي لجدول الحسابات الذي هو النواة في تصميمي هو عدم تداخل المجال و أنا قد وصلت لهدفي و الحمد لله و قد تمت تجربته قبل نشره في هذا المنتدى

أما أنك قد علقت على كيفية الوصول لهدفي (تداخل المجالات ) فهذه رؤيتك الخاصة التي لم أفترض على الأطلاق خطأها و لكني طلبت منك المضي قدماً في التصميم على الفرضية التي وضعتها

و أخي الكريم إن كانت الأسس التي وضعتها للحل الذي عرضته لم تقم على أسس سليمة فأنا أرحب بكل رأي بناء سوف تمضي فيه قدماً فأنا أريد الأستفادة ولا أتعالى أبداً على العلم ، فأنت لك رؤية أهلا و سهلا بك فأوضحها لنا و أوضح لنا السبيل في كيفية بناء قواعد بيانات مالية ولك أعظم الثواب إن شاء الله

اقتباس

و لا أقصد أن الأخ قصر فيها لكن طول الTrigger مما جعله صعبا حتى للفهم

و هو قد طلب منا أن نحاول الاختصار

و أنا فكرت بهذه الطريقة طالما أن العمودين هما نفس بعض فلما لا نوفر طلب فحص العمودين هل هما نفس القيم أم لا

خاصة و أن استبعاد هذا العمود سيقلل مرات الفحص من 16 حالة إلى 8 حالات

ألستم معي في هذا الموضوع

أخي الكريم عارف أنا وضعت الإجراء القادح ووضعت الهدف منه و كان ما يهمنى هو الهدف بل و عرضت على كل قراء المقال و أوضحت بالرسومات التوضيحية المشكلة التي تواجهنا لكي يتسنى للسادة القراء الأبداع و الخلق و لكن لم يجبني أحد ، فلا تلومن علي لأجل ذلك فأنا توقعت أن يظهر أحداً مثلك أو مثل نشوان لكي يقترح طرق أو بدائل و لكن للأسف كانت المداخلات ليس بالقوة التي توقعتها ، و أنا أعتقد أن أي كود سوف يوضع لحل أي مشكلة هو نتاج فكري ليس بالضروري تطبيقه بحذافيره و لكن أنا منذ بدء الموضوع و أنا أوضح المشكلة و أوضح الحل فمن يتفق معي في الحل فهذا له أما من لا يتفق معي في الحل فأنا أوضحت المشكلة و رحبت بكل رأي لحل أي مشكلة مطروحة

اقتباس

 

أما الأخ فيكفيه شرفا أن بدأ فكرة الموضع التي لم نكن لنراها في هذا المنتدى

أنا أشكرك على هذه الكلمات

و السلام عليكم و رحمة الله و بركاته

تحياتي للجميع

لدي بعض الاقتراحات ارجوا عدم اهمال الموضوع لاننا اذا كنا سوف نستمر على هذا المنوال فوالله الذي رفع السماء بغير عمد لن نفهم شيئا

اخواني الاعزاء هذه ملاحظاتي واقتراحاتي :

1- كلنا والله الحمد ما اجتمعنا ولا جلسنا نتصفح هذا الموقع عبثاً وعلى الاقل نحاول ونجتهد للخروج بالفهم العميق من ناس اجلاء وكبار امثالكم ولكن ليس هذا هو الاسلوب للتعلم وايجاد حلول

لمشاكلنا وانا لم اقدم شي حتى الان لاني ما ادري ماذا اعمل هل اطبق ما ذكره الاخ حميد ام اتباع مقالات وكتب في هذا الخصوص

2 - اقترح كما ذكر الاخ حميد بتخصيص المهام لدى المشاركين وعدم الانتقال الى موضوع او جزئية الى بعد الفهم العميق للموضوع الذي نحن بصدده ووالله اني من اشد المعجبين بهذا الشخص فهذا هو العطاء وهذا هو الشخص الذي ننهل من علمه يا اخون يكفي ان الاخ حميد مفرغ نفسه لهذا العمل النبيل

3- انا من ناحيتي لا اتقن البرمجة ولكن سوف اعمل على تحليل ومناقشة بعض الافكار التخصصية في علم المحاسبة لاني لان افيد في المشاركة في تصميم قواعد البيانات ومتى ما وجدت نفسي مؤهلاً للتحليل والتصميم لان ابخل باي شي

4- انا والله يشرفني العمل معكم ولكن لا اعرف من اين ابدا وكيف افيد غيري هل بان اعمل مشاركة غير منظمة وفي غير موضوعها وبالتالي اعمل لاخبطه وكثر كلام من غير فائدة ام ماذا افيدوني .. !!!!

5- اقترح ان يكون فريق عمل يسند الى الاشخاص كلاً على حسب ما يجيد من مهارات وامكانيات فوالله الذي رفع السماء بغير عمد ان الكل يرغب المشاركة ولكن ... أه كيف ..

6 - ان لا يبنى حل من الحلول الا بعد التنحيص ووضع الافترضات على الحل وان يكون الحل شاملاً يعني ان لا يقتصر على الاوامر البرمجية مع شرحها بل مع الاسباب وكيف معالجة الحل يدوياً ونظرياً اولا ثم تحويلة الى الاوامر البرمجية

7- يا اخوان ليس من المعقول ان لا نتفق على كيفية توزيع الاعمال فيما بيننا او هذكا نحن العرب اتفقنا على ان لا نتفق

8 - لا يقولي واحد وماذا انت قدمت علشان تجي وتضع مقترحات او نصائح لنا اقول له يا اخي انا اريد ان افهم لكي اشارك واقولها باعلى صوتي والله لن يستفيد احد من هذا الاسلوب وسوف نخرج جميعنا بالسالب ومجرد مهاترات وكلام ومضيعة للوقت

يا اخواني ارشدوني كيف السبيل الى متابعة هذا الموضوع فوالله لم افهم شي ولن افهم شي بهذا الاسلوب .. ارحمونا يا عباقره انتم املنا وطولو بالكم علينا ولا تزعلو منا فالهدف واحد ولكن يختلف المجهود المبذول من كل شخص فذالك الشخص يقدم مقترحات وذلك الشخص يقدم الحلول البرمجية لهذه المقترحات وهكذا لا تتوقعو ان يشارك احد وهو لم يفهم

ارجوا اني ما اطلت عليكم وسامحوني فهذا من غيرتي عليكم انتم ايها المعلمون

تحياتي

الله يجزيكم الف خير

واستمر بالمراقبة ......

Aref21 كتب:

الأخ نشوان

نحن لا نريد أن نتوقف عند هذه الجزئية لاننا لا نريد الاستمرار

و يعلم الله كم أنا مشتاق للاستمرار في الموضوع و لكن

يجب أن نبدأ من الأول بداية سليمة لتكون قاعدة البيانات سليمة

و لا أقصد أن الأخ قصر فيها لكن طول الTrigger مما جعله صعبا حتى للفهم

و هو قد طلب منا أن نحاول الاختصار

و أنا فكرت بهذه الطريقة طالما أن العمودين هما نفس بعض فلما لا نوفر طلب فحص العمودين هل هما نفس القيم أم لا

خاصة و أن استبعاد هذا العمود سيقلل مرات الفحص من 16 حالة إلى 8 حالات

ألستم معي في هذا الموضوع

أما الأخ فيكفيه شرفا أن بدأ فكرة الموضع التي لم نكن لنراها في هذا المنتدى

و أرجو منكم المعذرة لأني سأتغيب عنكم لفترة لأني سآخذ إجازة حتى يوم الأحد

مع خالص شكري للجميع

←

السلام عليكم

اخي عارف

ما كنت ارمي اليه هو مادامت الفكرة سليمة والنتيجة صحيحة فعملية التحسين و رفع الكفاءة ممكن ان تأتي لاحقاً

و على كل جزاك الله خير

و ارجو استمرارك معنا خوفا من ان يمل الاستاذ حميد مني و يقرر اقفال الموضوع :rolleyes:

مع خالص التحية

السلام عليكم

مرفق تصميمي السابق مرسوم في SQL SERVER

واسف على التاخير وإن شاء الله ارفق قاعدة البيانات لاحقا لانها ليست معي الان

مع تحياتي للمشاركين

السلام عليكم و رحمة الله و بركاته

سوف نعود معاً إلى مختبرنا قريباً إن شاء الله مع أضافة تعديل على التصميم إن شاء الله لكي يناسب مراكز التكلفة COST CENTERS و هو موضوع ذو أهمية و بسيط إن شاء الله و سوف يعطي الحل المالي الخاص بنا قوة من حيث الأمكانيات

و سوف نناقش أيضاً بإذن الله تصميم أخونا نشوان جزاه الله خيراً

و أشكركم

السلام عليكم و رحمة الله و بركاته

أخي الكريم خالد

أشكرك على مداخلتك فأنا أعرف ما تعانيه و أعرف حرصك الشديد على المنفعة و مراعاتك عدم إدراج أي مشاركة أو تصميم بدون أن يكون واضح المعالم و لكن أخي الكريم

نحن هنا لكي يقدم كل واحد منا ما عنده و هذا ليس قاصر علي أنا فقط فهناك محاولات مثل محاولة الأخ نشوان جزاه الله خيراً و هو يمشي في أتجاه أخر و لكنه يمشي و هذا شرف له و أنا أمشى في أتجاه أخر غير أتجاهه في التصميم و الأختلاف هنا سوف يبرز للقارئ الأراء المتعددة التي هي في صالحه في النهاية

فأنا أن قلت لك أن الموضوع سوف يقتصر على تصميم واحد فقط فأنا بذلك أجعل الموضوع يعاني من فقر دم في الأفكار و لكن إن فتحنا الموضوع لكل من لديه تصميم و أقتراح و مشاكل تتعلق بالمحاسبة لإيجاد الحلول هنا عندما نقرأ موضوع مثل ذلك فسوف تثرى العقول و تغنى بإذن الله

أخي الكريم اليوم أحببت أن أتصفح الموقع و أستخدم محرك البحث الداخلي للموقع و قد كانت كلمة البحث محاسبة ووجدت العديد من المحاولات القديمة في هذا المضمار و لكنها كلها باءت بالفشل و ركيكة و لا أعلم حقيقة هل هذا من جهل أم من تجاهل كثيراً من العلماء الذين توصلوا إلى مثل هذه التقنيات و لم يفيدوا بها أحداً أم غياب الخبراء المحاسبيين و الماليين للإدلاء بأراءهم في هذا الموضوع المهم أم ضعف القائمين على هذه الموضيع و جهلهم بالمشاكل التي يفترض أن يحلوها بهذه التصميمات

فتجد مثلاً أحدهم يقول لك مراقبة على مخزون و ينسى مشكلة تذبذب الأسعار السوقية و طرق تقييم مخزون أخر المدة و أنت أدرى بهذه المشاكل فأنت محاسب ممارس و تعلم ما أقول

على كلاً أخي خالد أرجو منك مرة أخرى أن تضع تصميماتك و حلولك هنا في المنتدى لأنك بذلك لن تأخذ برأيي فقط و لكن بأراء السادة قراء المقال و سوف تفتح لك أبواب كثيرة و من المشاكل التي تواجهها في تصميماتك و المقترحات لها سوف يتم أثراء هذا الموضوع الذي سوف يكون مرجعاً لمن يهوى برمجة الحلول المالية إن شاء

و أخيراً أخي الكريم أنا وضعت هذا الموضوع و قد أفترضت في القارئ أن يكون على علم و دراية كافية بقواعد أس كيو إل سيرفر و أنصح أي أحد لا يفهم كود أو تصميم من التصميمات المقترحة هنا أن يدرس أساسيات أس كيو إل سيرفر و سوف يكون الأمر بالنسبة له سهلا إن شاء الله ، فأنا أعرف بعض المبرمجين الأن يدرسون محاسبة لكي يعرفوا ماهية الفكرة العامة و كيف يتعاملون مع عملاؤهم بالخارج و أتمنى لهم التوفيق و أحيي فيهم هذه الروح المقدامة

و أتمنى لك التوفيق و ارجو منك أن لا تقسوا على نفسك كثيراً فالأمر بسيط ألخصه لك في نقطتين

1-أدرس أساسيات أس كيو أل سيرفر

2-أفهم المشكلة التي سوف تحلها بتصميمك جيداً

و أشكرك أخي الكريم ، و أتمنى أن يوجد كثيراً مثلك من المحاسبين المجتهدين

و السلام عليكم و رحمة الله و بركاته

السلام عليكم و رحمة الله و بركاته

أخي الكريم نشوان

ما أردت أن أعرفه هو ما هي فائدة GL_BATCH ؟

و ما فائدة GL_CODING ؟

و ما فائدة COMPANY ؟ هذا إذا كنت سوف تنظم شجرة الحسابات بطريقة المستويات

و كيف سوف تحكم المستويات LIVEL_ID و عدم التداخل بينهم ؟ و ما هي رؤيتك التي بنيت عليها تصميمك ؟

الرجاء توضيح كافة النقاط السابقة و أشكرك و اسأل عن تغيبك في الفترة السابقة فلعل المانع خيراً أن شاء الله

و السلام عليكم و رحمة الله و بركاته

السلام عليكم و رحمة الله و بركاته

أخواني الكرام المشاركة الخاصة بالتوسعات في الحل المالي GL جاهزة و لكن للأسف لتوقف خدمة تحميل الصور في المنتدى في هذا الوقت سوف أدرجها في وقت لاحق إن شاء الله و أتمنى أن لا تحذف إدارة المنتدى الصور الأيضاحية لهذا الموضوع مع مرور الوقت .

و أشكركم

ها أنا عدت

أعتذر للأخوة

و أرجو المسامحة

كلنا يخطئ و يصيب و نيتنا أن نعمل لنرضري ربنا ولنعمل سويا من أجل نهضة أمتنا

السلام عليكم و رحمة الله و بركاته

أخواني الكرام

سوف ندخل الأن إلى مرحلة أخرى و مقالة أخري و تعديل و توسيع لقاعدة بياناتنا التي سوف تكون بإذن الله نواة حل محاسبي متكامل بإذن الله

أخواني الكرام تكلمنا في المقالة السابقة عن كيفية توسيع قاعدة البيانات و تضمينها خاصية مهمة من خواص الحلول المالية و المحاسبية و هو خاصية تعدد العملات أو MULTI CURRENCY و سوف نرجع مرة أخرى معكم إلى خاصية مهمة و خاصية COST CENTERS أو مراكز التكلفة أو ما يمكن أن نسميه أيضاً JOB COSTING أو تكاليف الشغلة و في حقيقة الأمر أن إدراج هذا النوع من التحليلات في الحلول المالية ذو أهمية خاصة بالنسبة للإدارة المالية و متخذي القرارات

و في تعريف بسيط لمراكز التكلفة سوف نجد أنها هي أسلوب لقياس التكاليف لمشروع معين أو لطلبية معينة تكون في الغالب مطلوبة من العملاء بمواصفات خاصة

و هذا له العديد من المزايا من أهمها أنها تمنح الأدارة المالية مقاييس للمقارنة بين المشاريع المختلفة أو أوامر الأنتاج المختلفة و تسهل من مراقبة التكاليف في خلال فترة الأنتاج

و في حقيقة الأمر إن التكاليف التي يجب أن نحملها على أي مشروع تنقسم إلى أربعة أقسام من الممكن أن تعالج في هيكل الحسابات و هذه الأقسام هي

1- تكاليف المواد

2- تكاليف العمل

3- التكاليف الأخرى المباشرة

4- الأعباء الأخرى

و في التعديل الذي تم في GL لم يتم إدراج أي تقسيم من هذه التقسيمات السابقة إذ أننا ببساطة شديدة من الممكن أن نحكم هذه المسألة من خلال هيكل الحسابات ( و هذه أحدى نقاط قوة هيكل الحسابات الذي تم إحكام تداخل مجالاته بشدة ) و لكن تم إدراج جدول جديد أسمه CostCenterDetails و ذلك لإدراج تفاصيل مراكز التكلفة و تم ربطه بالجدول Accounts

و سوف تكون التعديلات كما هو موضح لكم في الشكل التالي :::::::::

و تم تغيير مسميات الجداول الأتية كما هو موضح في الصورة السابقة

الجدول JournalVoucherHeader إلى JVHeaderNPosted و سوف تكون مهمته التفاصيل الرئيسية للقيود الغير مرحلة

الجدول TransactionsDetails إلى JVDetailsNPosted و سوف تكون مهمته التفاصيل القيود الغير مرحلة

و تم أضافة الجدولين JVHeaderPosted و JVDetailsPosted لإدراج تفاصيل القيود الرئيسية و الفرعية و التي سوف يتم ترحيلها

و بذلك نكون قد وضعنا أستراتيجية للترحيل و سوف تتضح عند الدخول على مرحلة الأستعلامات التي باتت وشيكة بإذن الله و من أهم ما يميز هذه الأستراتيجية هو مراعاة إداء قاعدة البيانات مراعاة تامة و عدم الأثقال عليها حيث ستكون البيانات موزعة على جدولين متماثلين

و سوف تبنى إن شاء الله الأستعلامات على دالات جدولية و سوف أوضح ما هو الطريق لذلك

أخواني بهذا التصميم سوف تتضح لكم معالم قوة هيكل الحسابات و كيفية أستغلاله الأستغلال الأمثل للتحكم في هيكل حسابات ضخم بدون أية قيود ، فأنا قد وجدت بعض مصممي قواعد البيانات قد فصلوا تفاصيل الشركة بشكل منفصل عن قاعدة البيانات و لكني هنا أعتبرت أن الشركة نفسها داخلة في تكويد هيلك الحسابات و أنا بذلك قد أعطيت لنفسي مساحة لتقليل تعقيد الإستعلامات و أيضاً هذا يناسب فكرة القوائم المالية الموحدة و يساعد عليها في المستقبل بإذن الله

في المستقبل بإذن الله سوف نتعرف على أستراتيجية جديدة نوعاً ما علينا و هو كيفية تضمين جدول حسابات تحكم لربط الحلول الفرعية الأخرى مثل ACCOUNTS RECEIVABLE و ACCOUNTS PAYABLE و INVENTORY و PAYROLL أو HUMAN RESOURCES و FIXED ASSETS في المستقبل القريب

و أحب أن أنوه إلى أننا سوف نعدل في تصميمنا بما يتناسب و مرحلة تصميم الأستعلامات و هذا طبيعى في مرحلة التصميم و يا أخوة سوف نبنى جميع تقاريرنا على الأستعلامات و الأجراءات المخزنة و الوظائف بإذن الله

سوف تجدون قاعدة البيانات في صورة Deattached DataBase مرفقة

شكرا

GL.zip

السلام عليكم و رحمة الله و بركاته

أخواني الكرام قراء هذا الموضوع

مالي لا أرى مداخلات لكم ، ماذا حدث هل خمدت ناركم أم أننا أكتفينا بما قمنا به و قد أصابنا الأنهاك و التعب و أستكثرنا على أنفسنا ما قمنا به

لا أدرى ماذا أقول لكم ؟

اللهم أهدني و أياهم يا رب إلى سواء السبيل و أغفر لنا و أرحمنا و من علينا بنعمة العلم و إرزقنا تعلمه و تعليمه

اللهم أمين

و السلام عليكم و رحمة الله و بركاته

احنا معك متابعين و الله ما ملينا

لا يوجد على هذا الجهاز sql فلست قادرا على إضافة أي شيئ

لكن لي سؤال هل لأي حساب مركز تكلفة واحد فقط

يعني هل الحساب لا يمكن أن يرتبط بأكثر من مركز محاسبيا

و شكرا أخي على عملك وكم احسدك عليه

و ثق أني معك أتابع كل ما تكتب

و أدعو لك بكل التوفيق و السداد

اخواني أرجو منك الاجابة على الاستقصاء على موقع عمرو خالد

استقصاء حول موضوع - البطالة بين الشباب في الوطن العربي ..الأسباب وطرق العلاج

و جزاكم الله كل خير