الأخوة الكرام ، أسمحو لي أن أدرج في قسم الفورمز هدية متواضعة لحضراتكم ، ألا وهي كارت الصنف "نظام المخزون السلعي"

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


ستجدون المثال علي ((( الرابط التالي )))


كل ما أتمناة رأيكم في طريقة التصميم
1- البنية التحتية لقاعدة البيانات ER, Data Fields, Relations.
2- البنية التحتية للشاشة والتقرير.




يا رب تعجبكم الفكرة ، وكل ما أتمناة رأيكم ودعواتكم الجميلة



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

Thanks For Sharing

My questions are
1-Why the single item take many taxes
2-Why you take the suppliers for the item in the Item Definition and not in the Purchase Invoice
Regards

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

بداية شكرا لك على حرصك الدائم على مشاركة الاعضاء فى اعمالك وعرض الافكار المختلفة فى البرامج او التحليل

( صراحة كنت افضل انك تستخدم برنامج مساعد للبدء فى تحليل وتصميم جداول النظام واعداد رسمة ال ERD )

- لقد قمت بتحويل وصف الجداول الذى ارفقته الى رسمة ال erd من خلال برنامج ال POWER DESIGNER
فظهرت بعض الملاحظات ... مرفق الرسم المبدئي نتيجة هذا التحويل

-- جدول الشركة المصنعة --
CREATE TABLE Companies
(
 Companies_ID   NUMBER(10),
 Companies_Code VARCHAR2(20),
 Companies_Name VARCHAR2(50),
 CONSTRAINT PK_Companies PRIMARY KEY(Companies_ID),
 CONSTRAINT UQ_Companies_CODE UNIQUE(Companies_ID),
 CONSTRAINT UQ_Companies_NAME UNIQUE(Companies_NAME)
)

فى هذا الجدول المفتاح الاساسي هو رقم الشركة المصنعه Companies_ID
ثم قمت بانشاء قيد == عدم التكرار == على نفس العمود مرة اخرى فى السطر
CONSTRAINT UQ_Companies_CODE UNIQUE(Companies_ID),
لماذا ؟

السؤال الهام هو ما هو الفرق بين
Companies_ID و
Companies_Code

وهذا الاسلوب مستخدم فى معظم الجداول يوجد عمودين احداهما ID والآخر CODE

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

لا يوجد ربط بين جداول الرموز والجداول الاساسية ... هل سيتم ربط العلاقات برمجيا ؟
مثلا فى جدول ال ITEMS يوجد عمود رقم الشركة المصنعة ولم يتم ربطه مع جدول الشركات المصنعه

ارجوا ان تشرح وجهة نظرك فى الاسلوب المستخدم فى تصميم الجداول

للموضوع تكملة

شكرا لك

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

صراحة كنت افضل انك تستخدم برنامج مساعد للبدء فى تحليل وتصميم جداول النظام واعداد رسمة ال ERD

للأسف أخ أمجد انا من سنة 2001 وأنا أتعامل مع الـ Microsoft PowerPoint في تصميم الـ ER-Schema ، رغم أنني لا أستخدمة سوي في بناء الـ ER فقط لا غير ، فدة تعود مش أكثر.

فى هذا الجدول المفتاح الاساسي هو رقم الشركة المصنعه Companies_ID
ثم قمت بانشاء قيد == عدم التكرار == على نفس العمود مرة اخرى فى السطر
CONSTRAINT UQ_Companies_CODE UNIQUE(Companies_ID),
لماذا ؟

السؤال الهام هو ما هو الفرق بين
Companies_ID و
Companies_Code

وهذا الاسلوب مستخدم فى معظم الجداول يوجد عمودين احداهما ID والآخر CODE

فعلاً أخ أمجد ، أنا حاطط حقلين ، الأول وهو الـ ID والثاني هو الـ Code

الـ ID هو جزء من Structure Database ، أو البنية التحتية لقواعد البيانات ، حيث يعتبر أهم شيء يحتاجة أي مبرمج ، فمن المفضل فصل يدي المستخدم عنه تماماً ، بالزات أنني لا أضمن شكل عملية الإدخال من طرف المستخدم هتكون شكلها إية !!!

يعني مثلاً أنا بدخل ترقيم تلقائي ، يعني ( 1، 2، 3، 4، 5، ...... ن ) ... لكن المستخدم ممكن يدخل هذا الحقل كما يلي ( 100، 200، 150، 600، 380، .... ن) ، وبالطبع لو عملت Order By السجلات هتختلف وهتضرب معاة ، ولو طلب مني أني أعدلة هتبقي مشكلة ، لذلك فصلت الموضوع عن يدي المستخدم.

بالإضافة الي أن العميل أحياناً بيكون خفيف الظل أو بمعني أصح "سخيف الظل" ، عايز يكون الرقم الكودي يكون بتنسيق معين حسب رغبتة ، يعني مثلاً :

E2009-00001HR
E2009-00002HR
E2009-00003HR
E2009-00004HR
E2009-00005HR
E2009-00006HR

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

بالإضافة الي أن عملية الـ Order By لحقل الرقم غير الحقل النصي ، مثال :

1
10
11
12
4
40
41
42
5
6
7
8
9

يعني لو حبيت أعمل ترقيم لازم أعمل To_Number ، وطبعاً لو كان المفتاح الرئيسي تكوينة E2009-00001HR ، يبقي مفيش غير أني أعمل Function يشيل القيمة النصية ويأخذ القيمة الرقمية أو حتي جملة SQL تشيل كل هذه التنسيقات كما يلي :

Select Emp_No, Emp_Name
From Emp
Order By To_Number(SubStr(Emp_No,7,11))

طيب السؤال لية اللفة دي كلها ولية كل المشاكل دي !!!!

أحسن شيء أني أعمل حقل PK ليا أنا كمبرمج ، وحقل للعميل وأخلص نفسي !!!

وإسمح لي أن أكرر ، حقلي الـ Primary Key و الـ Foreign Key جزء لا يتجزأ من البنية التحتية لفاعدة البيانات Structure Database ، لأن دة سبب من أسباب وجود قواعد البيانات من أساسة "تجانس البيانات" ، وعملية التجانسب بتتم عن طريق تصميم جداول والربط بينهم من خلال علاقات إرتباط Relations ، بتحتوي علي مفتاح رئيسي ومفتاح .

يا رب أكود قادر علي التوضيح

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

لا يوجد ربط بين جداول الرموز والجداول الاساسية ... هل سيتم ربط العلاقات برمجيا ؟
مثلا فى جدول ال ITEMS يوجد عمود رقم الشركة المصنعة ولم يتم ربطه مع جدول الشركات المصنعه

فعلاً أخي الكريم ، ودة كان مجرد سهو مني ، نسيت أعمل Export لقاعدة البيانات من جديد ، لكن علي ما أعتقد أنني قمت بإنشاء العلاقات في ملف الكود Code.txt ، علي كل حال أنا أرفقتة من جديد وآسف علي هذا الخطأ

Code.txt

My questions are 
1-Why the single item take many taxes
2-Why you take the suppliers for the item in the Item Definition and not in the Purchase Invoice
Regards

بص يا أخي أخوك مصطفي ضايع في اللغة الإنجليزية ، لكنني دخلت علي موقع ترجمة Translate.Google.com وترجمت ويا رب يكون الترجمية صحيحة ، انت ونصيبك

1- لماذا تتخذ العديد من الضرائب

لأن فية أنواع كثيرة من الضرائب ، وأنا لا أعلمها ، بالإضافة أنني أحب دائماً أأمن الوضح بالإخلاء التام ، بمعني أن أخلي يدي عن كل شيء وأترك العميل يفعل ما يشاء ((( شغلة وهو حر فية لية أعكر علية الصفو )))...

2- لماذا تتخذ الموردين لهذا البند في البند التعريف وليس في فاتورة الشراء.

من المفروض أن فية شركات بتتعامل مع أكثر من مورد لكل صنف "صح أم خطأ" ؟؟؟

بالطبع صح الصح !!!

لازم أعرف لكل صنف مين الموردين أللي بيوردولي الصنف دة ، عارف لية ، علشان لو عندي مئات الآلاف من الأصناف وخلص صنف منهم أقدر أعرف مين أللي بيورد ليا الصنف دة علشان أتصل به علي الفور !!!

بالإضافة الي ذلك أن من ضمن كل الموردين بيكون فية مورد مفضل دايماً بشتري من عندة ، لكن السؤال لو مثلاً لقيت عند المورد دة كمية صغيرة فكيف أسد العجز ؟؟؟

بالطبع هلجأ لأي مورد آخر ، لذلك وضعت "مورد مفضل" ...

أما بقي بخصوص الفاتورة فمثالي لم يتحدث عن ذلك ، دة كارت الصنف فقط لا غير


شكراً للجميع

آآة آسف أخ أمجد أنا نسيت أقول لك شيء ، الـ ER-Schema شيء و الـ ERD شيء آخر !!!!

الـ ERS هو تحليل نظم ، أما ERD فهو عرض الجداول وعرض العلاقات بينهم وكذلك الحقول !!!


دة تحليل نظم ، والمفروض أن أنا في دراستي أعتمدت أعتماد كلي علي نوعين من تحليل النظم

1- تحليل نظم البرامج
2- تحليل نظم البيانات


بالإضافة الي بعض التحاليل الأخري التي للأسف نسيتها لأنها كانت تحاليل فرعية



والله يا أستاذ أمجد كل أما أفكر أعمل شرح لهذه الجزئية ، وأعمل شرح لـ SQL وأعمل شرح عن الـ Database وسبب ظهورها من الأساس أو من "الجزور" للأسف بتجيني ظروف تمنعني ، ومش قادر أوعد أحد بيها ، علي كل حال أللي فية الخير يقدمة ربنا ، ولو جاني فرصة سأصنع ما تشائو


بالمناسبة ، ممكن تعمل ERD من علي Access أو من داخل الفيجوال 6.0 بإستخدام DDE !!!!

بس كما ذكرت ، الـ ERS شيء والـ ERD, DDE, Access شيء آخر


شكراً

Thanks for clearing those issues,My another comment is why you are saving for each Item unit a price while I can guess it is possible to compute it programatically from the base unit and its relation to other units defined for the item.Sorry for using english I don't have arabic keyboard.
Regards.

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

الأخ / مصطفى

انا من سنة 2001 وأنا أتعامل مع الـ Microsoft PowerPoint في تصميم الـ ER-Schema ، رغم أنني لا أستخدمة سوي في بناء الـ ER فقط لا غير ، فدة تعود مش أكثر.

لقد انتشرت منذ فترة ... البرامج المساعدة فى استخدام الاساليب الحديثة فى التحليل والتصميم مثل برامج ال
ORACLE DESIGNER
Rational Rose- SMARTDRAW - VISIO - POWER DESIGNER
وهى من المهام الاساسية للمبرمجين والمحللين . فيمكنك اختصار الكثير من الوقت والجهد فى عملية التحليل والتصميم ثم استخراج وصف الجداول مباشرة بدون اخطاء مع امكانية تحديد نوع قاعدة البيانات التى تتعامل معها ... بالاضافة لامكانية ال
REVERS ENGINEERING
وهى تحويل اوامر انشاء الجداول الى علاقات ورسومات بعد قراءة ملف انشاء الجداول المستخرج من برنامج اخر او قاعدة بيانات اخرى

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

أحسن شيء أني أعمل حقل PK ليا أنا كمبرمج ، وحقل للعميل وأخلص نفسي !!!

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

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

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

سؤال ما المقصود بلون الصنف ؟
هل يوجد احتمال ان يكون للصنف أكثر من لون مشترك

رجاء شرح العلاقة بين جداول ITEMUNITS - ITEMPRICE - ITEMPRICENAME
كيف يتم التسعير للاصناف وكيف سيتم ربطها فيما بعد مع جداول البيع او عند اصدار الفاتورة

شكرا لك على الجهد المتميز

عفواً الحديث طويل !!!!


أنظر المرفق

Mail.zip

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

الأخ / مصطفى

شكرا لك ... على الايضاحات الوجودة بالملف

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


شكراً

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