• 1
أحمد مبارك الحيقي

كيف تعالج المرتجعات؟

سؤال

تمهيد

------

واحدة من النقاط التي لا تأخذ عادة حقها من النقاش في الأمثلة والدروس المطروحة (ولذلك تستمر حولها التساؤلات)، هي قضية المرتجعات في برامج المخازن والمبيعات. فيما يلي أحاول المساهمة بشرح طريقة أراها مناسبة لمعالجة الموضوع، سبق أن أشرت إليها من قبل (في سلسلة المذكرات المثبتة هنا في القسم)، عند مناقشة تصميم مقترح لقاعدة بيانات مخازن ومبيعات، لكن من المستبعد أن يقرأها أحدهم هناك الآن. من أجل ذلك، رأيت أن أفرد بعض القضايا التي يكثر حولها التساؤل في مواضيع مستقلة، لعلها تجد حظها من الدراسة، وتلقي بعض الضوء على مثل هذه القضايا.

ما هي المرتجعات؟

-------------------

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

افتراضات أولية

---------------

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

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

نحتاج في عملية الإرجاع إلى تحديد الكميات أيضاً (حتى ولو كان الإرجاع يتم بناء على فاتورة سابقة) لأنه من الممكن أن يتم رد بعض كميات المواد فقط (مثلاً، الكميات المعطوبة). ونحتاج إلى تحديد سعر الإرجاع أيضاً لأنه من الوارد أن يتم الإرجاع بسعر أقل (حسب الاتفاق).

الطريقة

-------

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

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

§ إذا تم تحديد رقم فاتورة مصدر، فيجب التأكد من تقييد إدخالات المواد وكمياتها بالفاتورة الأصلية؛ يجب ألا تزيد الكمية المردودة مثلاً عن الكمية الموجودة في الفاتورة الأصل، كما يجب ألا تدخل مادة لم تكن موجودة أصلاً في الفاتورة الأصل.

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

§ في كل الأحوال، يجب التأكد من أن هنالك كميات كافية في المخزن من المواد التي يتم ردها في حالة مرتجع الشراء.

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

§ يجب كذلك مراعاة رصيد العملاء في حالة الرد بالآجل. فمثلاً، كما أن البيع بالآجل يزيد من رصيد العميل المدين، فكذلك مرتجع البيع بالآجل ينقص من رصيده المدين. لاحظ أننا أتحنا المجال للرد بالآجل في تصميم الفاتورة (حقل طريقة الدفع)، لأن هذا يمكن أن يحدث.

خلاصة

-------

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

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

هل كان ذلك واضحاً؟ جيد، إذاً دعنا الآن نكسر بعض افتراضاتنا السابقة! التحليل قد يخبرك بمتطلب دقيق لصاحب المحل، ولا بد من مراعاته في التصميم. قد يشترط صاحب النظام أن يرتبط كل مردود بفاتورة أصلية محددة من حيث الأصناف والكميات. معنى ذلك أنه في حالة رد بضاعة مباعة (مردود بيع) يجب أن يتم رد البضاعة على أساس فاتورة البيع التي تم فيها بيع هذه البضاعة بعينها. لا يمكن رد بضاعة لم يتم شراؤها في فاتورة البيع هذه نفسها، ولا رد كميات أكبر من الكميات المباعة في نفس الفاتورة. في هذه الحالة، ستحتاج إلى تضمين حقل آخر اسمه مثلاً (الفاتورة المصدر)، يربط كل فاتورة مردود بفاتورة أصلية. هنا بضع ملحوظات:

  • ينبغي عليك كمبرمج أن تتأكد من أن فاتورة المردود تلتزم بأصناف وكميات الفاتورة المصدر.
  • هذا الحقل (الفاتورة المصدر) يحوي أرقام فواتير، وهي المفتاح الأساسي لجدول الفواتير، وعلى هذا فإن هذا الحقل هو مفتاح أجنبي (غريب وسط أهله!)، يربط جدول الفواتير بنفسه، ويسمى هذا self-relationship، علاقة ذاتية.
  • لاحظ أن هذا الحقل سيبقى فارغاً في أغلب السجلات، وهي فواتير البيع والشراء الأصلية، لكن هذا لا بأس به باعتبار أننا وفرنا إنشاء أكثر من جدول، وما يستتبع ذلك من ربط في الاستعلامات المختلفة.

خاتمة

------

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

4

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

6 إجابة على هذا السؤال .

  • 0

كلام مية مية

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

بصراحة اثرت موضوع ارهقني كثيرا من كثرة التفكير في آلية معالجته ووضع يدك على الجرح ووضعت الامور بنصابها الصحيح

اعجبتني فكرة شراء،بيع،مرتجع شراء،مرتجع بيع،

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

حياك الله أخي الكريم...

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

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

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

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

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

بسم الله الرحمن الرحيم

بارك الله فيك اخي الكريم

الحقيقة الموضوع شيق وجميل

ولا ادري لماذا وضع التقييم بالسالب

اعتقد انها غلطة

والذي يؤكد كلامي لو كان يريد التقييم بالسالب لقام بذلك في المشاركة الاساسية

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

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

شرح اكثر من رائع استاذي احمد 1+

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

عملة مثال خاص بالمستودعات والمخازن المشكلة الي واجهتني كانت كيفية منع المستخدم من صرف كمية اكثر من الموجوده او ارجاع كمية لم تصرف في الاساس

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

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

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

علي الرغم من ان الموضوع مر عليه وقت طويل ..

 

اريد اضيف فقط ان :

يجب مراعاة الخصومات والبوانص .

كمثال : اذا كانت المؤسسة تقدم علي 10 قطع من صنف ب قطعة بونص اضافية ، فاذا قام العميل قد اشتري من هذا الصنف 10 قطع واخذ عليهم 1 قطعة بونص ومن ثم قام بعمل مرتجع لقطعتين  فلابد من الغاء البونص عن طريق احتساب قيمته خصم ( علي فاتورة المترجع هذه لصالح المؤسسة ) او حساب سعر القطع المرتجعة من قيمة المدفوع الفعلية للصنف بعد الخصم والبونص .

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

من فضلك سجل دخول لتتمكن من التعليق

ستتمكن من اضافه تعليقات بعد التسجيل



سجل دخولك الان

  • يستعرض القسم حالياً   0 members

    لا يوجد أعضاء مسجلين يشاهدون هذه الصفحة .