ما هي الخوارزميات الممكنه لحساب (كمية ، و سعر) منتجات في مخزن معين ؟
- sami-abdo
- 2015-12-13T11:56:26+00:00
- 2017-11-03T06:12:24+00:00
السلام عليكم و رحمة الله و بركاته
منذ فترة أعمل على نوع من أنظمة إدارة المحلات التجارية و المخازن ، و من مهام هذا النظام تسجيل عمليات البيع
المشكلات التي واجهتني :
أن لكل منتج عدة عبوات من الممكن أن يباع بها
و لكل عبوة سعر محدد
و كل كمية عبوة تعتبر كمية من عبوة أخرى أكبر منها أو أخرى تحتوي على عبوة أصغر منها .
في الحقيقة فكرت في أن أجعل البائع يكتب السعر و نوع العبوة ، ولكن هذا يطئ عملية البيع و هو غير عملي ،
و فكرت في تسجيل كل عبوة و سعرها ، لكن المشكلة في ألية حساب الكمية التي نقصت من المنتج
فما هي أفضل خوارزمية لكي أربط بين هذه العبوات و أسعارها و كمياتها ، مع المحافظة على سهولة عملية البيع .
ملاحظة
يعتمد على هذه العمليات (أقصد عمليات البيع) تقارير و إحصائيات
سأجيبك حسب ما فهمت (اذا كنت مخطئا فصحح لي حتى اصحح من اجابتي) :
في أنظمة POS وأنظمة المخازن يخزن كل صنف في سجل منفصل مثلا : عبوة حليب بسعة ٣٠٠ مل من ماركة "x" لها سجل منفصل عن عبوة ٥٠٠ مل من نفس الماركة وبقية البيانات المكملة تعتبر بيانات وصفية Meta.
مبدئيا يجب ان يكون هنالك جدول لـ Inventory او جدول المخزون الذي يضم اسم المنتج مثلا ( حليب x الصغير ) وسعر الواحدة Unit Price وكمية المخزون Stock وطبعا بما ان المنتج له سجل منفصل سيكون له باركود منفصل.
يجب ان يكون هنالك جدول ايضا لـ Meta وتربط كل سجل برقم المنتج في جدول Inventory واسم التوصيفة مثلا (الحجم) وقيمة التوصيفة مثلا (٣٠٠ مل). وكما تلاحظ في هذه الحالة يمكن ان تصف منتجا معينا بعد لا محدود من الاوصاف. فمنتج الهاتف المحمول قد يمكنك وصف لونه وحجم شاشته لكن الحليب لا يمكنك وصف لونه بل تصف كميته ونسبة الدسامة فيه وهكذا.
كل عبوة يكون مطبوع عليها باركود وبكل سلاسة عند الشراء يقرأ البرنامج الباركود ليتعرف على المنتج واوصافه وسعره وعند اتمام الشراء سيتم انقاص الـ stock من سجله.
بالنسبة لحساب الكميات فبكل بساطة ستشنئ تقريرا يجمع السعر (Stock * Unit Price) لمنتج معين وبالنسبة لحساب كميته فسيقوم بجلب القيمة الوصفية للتوصيفة التي اسمها (حجم) ويضربها في Stock.
تحليلك رائع للأمر ولكن المشكلة أني لا أتكلم عن منتج ذو وحدة واحدة كمثال ( قارورة حليب ) بحجمين مثل 400ML و أخر 500ML إنما أتكلم عن حزمة قوارير الحليب و زجاجة(قارورة) الحليب ، و طريقة بيع الاثنين مع حساب لكمية و سعر المنتج على أساس ( الوحدة التي بيع بها) ؛ لتوصيف الامر أكثر :
إذا جاء زبون و كان في المحل 3 حزم لقوارير حليب ، و كل حزمة تحتوي على 20 قارورة ، فأراد الزبون شراء حزمة قوارير و نصف ، فكيف أحسب السعر الكلي و الكمية التي إشتراها و الكمية الباقية عبر خوارزمية معينة .
حسنا لنقوم بتحليل الأمر :
قم باضافة التالي على تحليلي السابق.
بالنسبة للعبوات الوحيدة التي ليست مربوطة بحزمة معينة ستندرج ضمن المنتجات العادية.
الحزمة التي تحتوي على ٢٠ قارورة هي منتج لذلك اضف سجلا جديدا في Inventory تحت اسم ٢٠ عبوة حليب والسعر يكون عبارة عن سعر الحزمة لان احيانا سعر الجملة يختلف عن سعر الوحدة واما Stock سيكون عدد الحزم المتاحة وايضا سيكون هنالك حقل Is Pack في الجدول فهنا اعطيه قيمة yes.
سنضيف جدول جديد تحت مسمى Packs يحتوي على رقم تعريف الحزمة ورقم الباركود الخاص بها في جدول Inventory.
سنضيف جدول اخر باسم Pack Items ويحتوي على رقم تعريف ورقم الحزمة ورقم الباركود الخاص بالمنتج وعدده. وهذا الجدول كما تلاحظ خاص بوصف المنتجات وعددها التي تتكون منها الحزمة المعينة.
على كل حزمة في المخزن سيتم لصق الباركود الخاصة بالحزمة. وببساطة عند شرائها سيتم شرائها مثل اي منتج وسيتم انقاص عدد الحزم من Stock الخاص بها.
اذا قرر المشتري شراء نصف حزمة اخرى (١٠ قوارير مثلا) ستقوم بكتابة (نصف 0.5) في جدول العدد Qty في شاشة الكاشير وهنا سيقوم النظام اولا بتحديد اذا ما كانت Is Pack واذا كانت كذلك فسيقوم بتحويل كل مكونات الحزمة تلك من القوارير ويضيفها ل Stock الخاص بالمنتج الاصلي وسيقوم بانقاص عدد الحزم في Stock الخاص بمنتج الحزمة. لأن الحزمة هنا فقدت سمتها كحزمة واصبحت منتجات مفرقة تحتسب على اساس سعر الحبة الواحدة. بعد هذه العملية سيقوم النظام بتغيير رقم الباركود في شاشة الكاشير للمنتج الاصلي(القارورة) وتغيير الكمية إلى 10 وتحتسب على اساس ذلك السعر.
شكراً على التوضيح الاضافي ، و من الممكن أن يكون حل إبتدائي ^_^ ، ولكن إذا كنت تعرف ما هي De-normalization في قواعد البيانات فهذا الحل يشببه كثيراً حيث أن بيان واحد يفصل إلي عدة بيانات أخرى على أساس وصف إضافي بسيط يمكن تقسيمه إلي جدول أخر وربطه بهذا البيان الاساسي .
الشئ الوحيد أن إحصائياتي بالنسبة للمواد المقسمة بهذه الطريقة سوف تختلف قليلاً .
عادة يوجد شيء اسمه مذكرة إدخال أو إخراج من المخزن وذلك لتوثيق حركة المواد ولأي سبب
كأن تنقل كمية من مخزن لمخزن أو كمية ما تلفت أو بيعت أو اشتريت كمية جديدة
في هذه الحالة تقوم بعمل مذكرة إخراج حزمة ومذكرة إدخال 20 عبوة فيتم تحول المواد من مادة لمادة وتبيع بعدها
يمكن عمل ذلك من خلال نافذة تسميها مثلا تحويل أصناف فتختار كمية الاولى و كمية الثانية وهو يقوم بعملية الإنقاص والزيادة مع اصدار مذكرات تلقائيا بناء على أمر التحويل
بحسب ما أعلمه يوجد شيء في أنظمة المحاسبة تسمى أدلة أو تعريفات مثل تعريفات الوحدات وتعريفات الأسعار
- فمثلا الوحدات التي تتعامل معها
عبوة أو قطعة أو حبة
درزن أو دزينة أو حزمة
صندوق أو كرتون
طبلية
- وتقوم بتعريف الوحدات المناسبة لكل نوع من المنتجات
كأن تعرف للحليب 300 مل مثلا
الوحدة الأولى : عبوة
الوحدة الثانية: صندوق(12)
الوحدة الثالثة : صندوق(24)
- وتقوم إن أحببت بإضافة خانة تمثل عدد الاجزاء من وحدة أخرى
كأن يكون الوحدة الأولى عبوة (أساس)
الوحدة الثانية: صندوق(12) : 12 عبوة
الوحدة الثالثة: صندوق(24) : 24 عبوة
الوحدة الرابعة: طبلية : 20 صندوق(12)
وطبعا يمكن معرفة المستوى الأدنى من الاجزاء من خلال التعريف الذي في نفس الجدول
أي يمكن أن تحصل على أن الطبلية هي 12×20 = 240 عبوة
هذه الأنواع تكون في جدول ليكون مرجع لجداول أخرى
-الآن يتم تعريف أيضا تعريفات للتسعير
كأن تسميه
الافتراضي
المفرق
الجملة
العروض
رمضان
الصيف
الشتاء
وذلك حسب مواسم التسعير لديك
- بعد ذلك لكل مادة يجب أن تضيف تعريفات الوحدات مع التسعير وتضع القيمة
كمثال لديك عبوة حليب 300 مل
تضيف لها
عبوة | مفرق | 1 دولار
عبوة | جملة | 0.9 دولار
دزينة(12) | مفرق | 11 دولار
صندوق(24) | مفرق | 21 دولار
صندوق(24) | عرض | 20 دولار
وهكذا
وللعلم السعر لا يشترط أن يكون قيمة فيمكن أن تجعله نسبة مئوية من الوحدة المركبة منها
كمثال: إذا كانت العبوة 1 دولار
يمكن تعريف الصندوق(12) على أن سعره 90% وبالتالي يكون 12×0.9 = 10.8 دولار مثلا
- وهذه التعريفات تختار منها عندما تصدر فاتورة بحيث يقوم بجلب السعر المناسب
وأيضا يتم الخصم من المخزن بحسب تركيبات الوحدات
فعندما يتم فتح صندوق لبيعه بالعبوات يجب أن تقوم بعمل حركة بحيث تنقص عدد الصناديق واحدا وتزيد عدد العبوات بعدد عبوات الصندوق
وعادة ما يتم تعرف لكل وحدة باركود مختلف أي وكأنه مادة مختلفة في حال لم ترغب بنظام التعريفات أعلاه
حقيقةً أخي كفيت و وفيت ، لكن أليس هذا حل معقد قليلأ على المستخدم ؟
شئ أخر ألية ربط بين كل عبوة و قيمة العبوة التي هي جزء منها أو هي جزء من عبوة أخرى كمثال من كلامك
الوحدة الثانية: صندوق(12) : 12 عبوة
الوحدة الثالثة: صندوق(24) : 24 عبوة
الوحدة الرابعة: طبلية : 20 صندوق(12)
هنا يوجد ربط بين الوحدة الثانية و الوحدة الرابعة فهل من الافضل ربط كل الوحدات مع الوحدة الاساسية فقط ؟
أنا ذكرت لك الأمرين المبسط والاحترافي المفصل والاختيار عائد إليك، المبسط هو أن تعتبر كل وحدة كأنها مادة مختلفة وعندما تريد أن تفتح حزمة لتبيعها بالقطعة يجب عليك عمل حركة تنقص من واحدة وتزيد في الأخرى ثم تبيع
بالنسبة للربط الأمر يعود للمستخدم فله كامل الحرية في توصيف التعريفات بما يناسب احتياجاته وما يراه مناسبا له.
لكن الربط بين وحدة ثالثة وثانية هي من أجل التحويل، كمثال أردت أن تجعل طبلية مفتوحة لتبيعها بالصناديق فكيف ستحول من من الكبير إلى الأصغر ، إلا إذا كنت ستستخدم عملية حسابية من خلال التحويل من العبوة إلى الصندوق وكذلك تقسم الكبيرة على الناتج لتحصل على عدد الصناديق، فتكون قد اضططرت لخطوة إضافية كما في الحالة الأولى.
عذراً على التأخر في الرد ، ولكن لم أفهم هذه الفقرة
لكن الربط بين وحدة ثالثة وثانية هي من أجل التحويل، كمثال أردت أن تجعل طبلية مفتوحة لتبيعها بالصناديق فكيف ستحول من من الكبير إلى الأصغر ، إلا إذا كنت ستستخدم عملية حسابية من خلال التحويل من العبوة إلى الصندوق وكذلك تقسم الكبيرة على الناتج لتحصل على عدد الصناديق، فتكون قد اضططرت لخطوة إضافية كما في الحالة الأولى.
مشكلتك تكمن في بنية البيانات لذالك يجب ان تدرس مادة مهمه -لاتدرس في الجامعات غالباً- اسمها Design pattern يمكنك بعد ذالك ان تصمم Builder Pattern تصميم كلاسات لحفظ كل نوع وتحليله وحسابة :
http://www.tutorialspoint.c...
بالتوفيق
لا تدرس لأنها متقدمة جدا، غالبا يأخذها الطالب في الماجستير تخصص هندسة برمجيات
نعم يوجد نماذج شهيرة ك MVP و MVC و MVVM كما يمكنك أن تصنع نموذجك الخاص بما تجده يسهل عملك، كمثال قمت بعمل نموذج أسميته MOV هو شبيه بـ MVC لكني أطبقه حاليا على تطبيقات WPF
وبحيث يسهل علي تحويله إلى MVC عندما أريد تحويل التطبيق إلى ويب، الـ MO هي النواة وتكون كمكتبة وفيها كل العمل أما V فهي تمثل أي نوع من التطبيقات سواء WPF أو WinForm أو حتى Consol أو ASP.Net و مستقبلا ممكن جوال سواء Windows 10 أو بقية المنصات من خلال الوسيط Xamrin
فكرة النموذج MOV فكرة رائعة بالفعل ...
حاولت قطع الاتصال نهائيا بين طبقة View و النواة ويكون الاتصال باتجاه واحد أي أن النواة لا تدري من هو الدومين الذي يستضيفه إن كان تطبيق مكتبي أم ويب أم جوال أم سطر أوامر
وهذا له فوائد كثيرة، أولا أن النواة تعتبر تطبيق متكامل يقوم بجميع الوظائف المناطة به، فقط تتطلب من يستدعيها، من جهة أخرى يمكنني عمل Test لجميع الوظائف ، النواة قابلة لأن يكون ال Front End المستضيف لها من أي نوع، لأنه في النهاية هو عبارة عن واجهة مستخدم يدخل ويظهر القيم ويعطي الاوامر لتنفيذ الوظائف
النواة قابلة لأن يبنى عليها تطبيقات أخرى، وكذلك يمكن تحويلها إلى SDK بحيث يقوم أي مطور بتضمينها ضمن تطبيق خاص به ليستفيد من خدماتها
النواة يمكن عمل ربطها بلغة سكربت لجعل التطبيق يقبل البرمجة مثل الماكرو والسكربتات كالتي موجودة في برامج أوفيس أو تطبيقات الجرافيك
باختصار النواة تمثل طبقتي Business Logic مع أي طبقات أخرى كـ Data Access أو واجهات أو خدمات
قبل أيام كنت أفكر في فصل وحدة التحقق من صحة البيانات إلى موديل منفصل ليسهل علي جعله في النواة أم من جهة ال View وذلك في حال أردت أن يكون التحقق من طرف العميل في حال تطبيقات الويب
بدلا من الذهاب والعودة إلى السيرفر
بالنسبة للموديل فهو لا يحوي إلا خصائص Property صرفة ولا يحوي أي وظيفة Method لأن وظيفته حمل القيم الخاصة بالتواصل مع طبقة العرض وأما بقية الخصائص الثانوية والوظائف فتكون حصرا ضمن المشغل Operator الذي يقوم بالوظائف على الخصائص ضمن الموديل والعرض يجلب أو يغير قيم الخصائص بناء على تفاعل المستخدم
ولو لاحظت من المخطط أنه يجب ربط مشغل لأي واجهة في طبقة العرض والتي بدورها تؤمن الموديل الذي سيشكل حاضنة البيانات DataContext
جميل جداً ومفصل .. بالنسبه لتطبيقات الويب في اخر مشروع لي قمت ببرمجه اطار عمل من الصفر منفصل جدا عن ال front-end حيث اريد جعله -اطار العمل في بدايته- ديناميكي الى اقصى حد حيث يجلب البيانات ويتاكد من صحتها البيانات المدخله والمخرجه ويقوم بكل العمليات بشكل ديناميكي تخيل معي نظام يقوم بتحليل قاعدة البيانات التي لديك فقط بادخال اسم قاعده البيانات وعلى اللاطار كل شي (التعرف على الحقول والجداول وغيرها ) ثم تنظيم عمليه الادخال والاخراج ... كنت سانشر الاطار على github لاكن يوجد الكثير من ال random codes هنا وهناك ..
ويتاكد من صحتها البيانات المدخله والمخرجه
هذه ستكون من طرف السيرفر أليس كذلك، لكن لو تلاحظ يوجد في بعض الأطر مكتبات تجعل التحقق من طرف الكلينت أي فوري وآني أثناء الكتابة دون انتظار إلى ما بعد الإرسال
وأظن أن إحدى مكتبات جيكوري تقوم بذلك.
لايمكنك ابداً التحقق من طرف الكلينت والذي يتحقق من طرف الكلاينت فقط لمساعده تجربه المستخدم وليس الامن حيث يجب التحقق من السيرفر للامان .. لان في الاخير امن الموقع هو عبر تامين كل طلب صادر من الكلاينت والتاكد من المدخلات من السيرفر pure
لا مفر من إدخال بيانات المُنتجات وتعديلها عند وورود طلبيات جديدة أو تحويل طلبيات أو إعدام طلبيات مُنتهية الصلاحية على سبيل المثال، ولكن الذي سيختلف هو آلية التعامل مع تلك البيانات بشكل سلس.
مبدئياً سيتم تعريف جميع الأصناف المُتواجدة في المخزن (لبن،شاي،سكر،...) من حيث (السعر، العدد، تاريخ الصلاحية، ...) وإن تواجد أصناف يتم بيعها بوحدات أكبر منها ستُضيف أعمدة بالمستويات المُتاحة -أو أضف جدول جديد بعلاقة مع جدول الوحدات- (مستوى أول، مستوى ثان، مستوى ثالث، ...) وكل مستوى لكل مُنتج سيحتوى على (عدد الوحدات في المُستوى، سعر المُستوى ككل، اسم المُستوى).
عند عملية إدخال الأصناف للمخزن سيتم وضع العدد الكلي من الوحدات على نوع الوحدة الموجود مُسبقاً أو إدخال نوع جديد
عند عملية البيع تكون لكل وحد باركود من خلاله يتم تحديد المنتج على النظام لخصم الكمية المُباعة من العدد الإجمالي في المخزن سواء تم بيع وحدة منفردة أو مستوى أعلى من تلك الوحدة.
مثال:
لدينا مُنتج قارورات حليب سعر القارورة 10$ وباقي مواصفاتها ... ولدينا مستوى أعلى لقارورة الحليب وهو حزمة حليب كل حزمة تحتوى على عدد 5 قارورات حليب وسعر الحزمة هو 45$ ولدينا مستوى أعلى وهو صندوق حزم قارورات حليب، يحتوى الصندوق على 10 حزم قارورات حليب وسعر الصندوق 400$ وهكذا ...
الآن سنقوم بتعريف هذا المُنتج على النظام لبدأ إدخاله للمخزن تمهيداً لعملية بيعه، سيتم إضافة منتج جديد وهو قارورة حليب بالمواصفات الفلانية وبسعر 10$ ومبدئياً عدد صفر قارورة بالمخزن ويوجد منه مستوى أول(حزمة) بعدد 5 قارورة بسعر 45$ ومستوى ثان (صندوق) بعدد 10 حزمة بسعر 400$.
تم إدخال عدد 100 صندوق و5 حزم وثلاث قارورات سيكون إجمالي عدد القارورات في المخزن 100X10X5)+3) تساوي 5003 قارورة حليب
من خلال عدد الوحدات الكلي ستتعرف على عدد الكمية المُتاحة من كل مستوى.
عند بيع وحدة قارورات مباشراً سيتم احتساب سعر القارورة وخصم العدد من العدد الكلي في المخزن، وعند بيع حزمة سيتم خصم 5 قارورات من العدد الكلي في المخزن وبيعهم بسعر 45$ وإن تم بيع صندوق سيتم خصم 50 قارورة حليب من العدد الكلي في المخزن وبيعهم بسعر 400$.
و كل كمية عبوة تعتبر كمية من عبوة أخرى أكبر منها أو أخرى تحتوي على عبوة أصغر منها .
ممكن توضح اكثر ؟
كمثال:
- إذا كانت صيدلية تبيع بندول فهي تشتريها بالكرتونة (هذه العبوة الاولى لهذا المنتج) و كل كرتونه تحتوي على - كمثال - (30 صندوق دواء) وهذا الصندوق يحتوي على (شريطين-كمثال-) و هذه النوع الثالث من هذه العبوة
سؤالي كيف أربط بين هذه العبوات كمثال من ناحية الكميات ؟
اذا تريد شيء جيد هيكلينا و لكن معقد، فعليك ان تستعمل هيكل شجري او ArrayList
لماذا لا تستعمل شيء مثل Enum؟
مثلاً :
enum BoxSize{
BigBox(30), SmallBox(2), OneTape(1);
private int size;
BoxSize(int size)
{
this.size = count;
}
public int getCount()
{
return this.size;
}
}
و هناك Method لإضافة الدواء ، مثلاً
void Add(BoxSize b, int count)
كتبتها بلغة الجافا ، و ذلك تضامناً مع الأخوة "جافاويين" هنا :)
لقد ذكرت انه مثل الدواء في الصيدلية ، يكون في صندوق مكون من 30 صندوق اصغر و كل واحد منها مكون من شريطين.
عند الإضافة أو الشراء ، و الذي يكون كعدد صحيح ، مثلاً إضافة صندوق و 10 اشرطة ، بدل ان تكتب أنه 70 شريط ، تستعمل Enum للشريط الصندوق الكبير ثم 10 مرات enum للصغير.
مثلاً عند البيع ،
void Sell(BoxSize b, int count)
{
من قاعدة البيانات التي لديك أنقص
b.getCount() * count
}
هل وضحت الفكرة؟
لا أقصد أن المستخدم هو من يحدد أسماء العبوات و كمياتها من ناحية الصلة بينها وبين عبوة أخرى
أنظر إلي مثال @عبد الرحمن أحمد في
مجتمع للمبرمجين من جميع المستويات لتبادل المعرفة والخبرات. ناقش لغات البرمجة المختلفة، الحلول البرمجية، والمشاريع.