اذهب الي المحتوي
أوفيسنا
بحث مخصص من جوجل فى أوفيسنا
Custom Search

استعلام خصم واضافة - مرتجع المبيعات


kalll

الردود الموصى بها

السلام عليكم

الاخوة الخبراء

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

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

وشكرا لكم على المساعده

وذادكم الله علمأ

System.rar

رابط هذا التعليق
شارك

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

لذا خبرتي في هذه المواضيع قليلة

ومع ذلك احفظ في مكتبتي العديد من الامثلة  في هذا الباب ، والقصد من ذلك الرجوع اليها في مثل هذه المواقف

 

واليك هذا المثال الذي تناول صاحبنا فيه المخزون والمرتجعات لعلك تجد فيه ما يفيدك

 

 

zz.rar

  • Like 1
رابط هذا التعليق
شارك

اللهم ارحم موتنا وموتا المسلمين

ولاكن للاسف اخى ابوخليل ليس فى البرنامج اى مردودات للمبيعات او المشتريات

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

رابط هذا التعليق
شارك

اخي الفاضل

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

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

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

 

 

تمهيد
------


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



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

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

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



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

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

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



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



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



الطريقة

-------

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



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



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

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

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

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

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

 

...

...

...

خاتمة

------

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

 

والنقل عن مذكرات متخصصة للأخ أحمد مبارك / اليمن

  • Like 1
رابط هذا التعليق
شارك

اذا كنت قد حليت المشكلة فلله الحمد والمنة, وإن لم فما استطيع قوله لك:

1: اما ان تجعل للمرتجعات عمود وحقل خاص بها في جدول المخزن وتستغني عن حقل نوع الفاتورة او نوع الحركة

لكنك ستقع في اشكال التفريق بين المرتجعات التي لك على الموردين وبين التي عليك لصالح العملاء..

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

ويتم ادخال قيم وعدد اصناف المرتجعات التي للعملاء عليك في حقل qty_in او بالمحلي في حقل "له" للعميل لأنها تحسب للعميل وتخصم من رصيده ولأنها الان تدخل في حقل qty_out اي مبيعات مرة اخرى

مع بيان نوع الحركة "مرتجع مبيعات"..

رابط هذا التعليق
شارك

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

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



سجل دخولك الان
  • تصفح هذا الموضوع مؤخراً   0 اعضاء متواجدين الان

    • لايوجد اعضاء مسجلون يتصفحون هذه الصفحه
×
×
  • اضف...

Important Information