ابوخليل

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

المشكلة التي ظهرت سببها واضح وهو الرقم المعرف .. فلما نختار طالب رقمه 1 فالمعيار سيجلب اي طالب لديه رقم 1 ضمن رقمه اي سيظهر 11 و 12 و 417 وهكذا الحل : ان يكون المعيار حسب رقم الهوية دعني ارى اذا يوجد حل من غير تغيير في الجدول تفضل غياب_مهذب2.rar

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

السلام عليكم يسرني المشاركة مع التحية لاخي العزيز احمد وخبيرنا الغالي وأستاذنا في التواضع والأدب الجم وحدات ابي هادي النمطية والوظائف الخاصة بتقويم ام القرى والتي تحاكي وظائف التاريخ الميلادي في فيجوال .. نكتب التاريخ فيها في حقول نصية ، حيث لو جعلنا نوع الحقل تاريخ فلا بد ان يحدث تعارض في اكسس .. مثلا لن يقبل تاريخ 29/2 ولا 30/2 وهذه مشكلة كبيرة لمن يعتمد التاريخ الهجري خاصة في الامور المالية والعقود . زيادة في الإيضاح : في اكسس عندما نحول التاريخ من اعدادات العميل في قاعدة البيانات من الميلادي الى الهجري فان اكسس يقوم بعملية رياضية (طرح 622 سنة ومقسوم على 0,97 ) .. والا فان التاريخ ما زال ميلادي .. اي ان اكسس ينظر اليه كميلادي قبل 622 سنة ... أمل ان الفكرة اتضحت طيب سيقول القائل لا بأس نعتمد الحقول النصية ولكن ستظهر المشكلة عند التصفية فلا يمكن البحث بين تاريخين .. هنا يوجد حل وهو تحويل النص الى تاريخ باحدى دالات التحويل ثم نجري عملياتنا . بالنسبة لمثال الأخ السائل فيمكن عمل التصفية في الاستعلام مصدر التقرير مباشرة ولكن ضع في علمك انك يوما ما ستواجه مشكلة لن تعرف سببها عند تسجيل غياب يوم لا يعترف به أكسس Between [forms]![غياب]![from_Date] And [forms]![غياب]![to_Date] تم تغييير اسمي حقلي البحث لأن واحد حروف عربية والثاني كلمة to محجوزة غياب2.rar

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

تفضل تصفية واختصار بعض الحقول محمد غياض شبعا2.rar

تفضل .. اتمنى هو مطلوبك تم تصفية النموذج الفرعي الثاني بناء على الرقم الاساسي في الفرعي الأول 1_2.rar

جرب تم التعديل على نموذج الحركة : تعطيل خيار المناقلة فقط واضافة حقل مخفي لمعرف المستفيد iduser في النموذج الفرعي من اجل جعله كمعيار آخر في تقرير الاستلام (زيادة ضبط) تم التعديل على مصدري التقريرين ( الاستعلام الداخلي) devicesdb16.rar

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

اضافة مميزة الى مكتبة المنتدى جزاك الله خيرا

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

الامر يسير جدا تنسيق مثل التنسيقات في وورد formattext2.accdb

نسيت ان اذكر شيىئا ، وهو انه لا يمكن الدخول لنموذج الحركة الا رسميا من خلال فورم الدخول

تم التعديل في اماكن متفرقة من البرنامج 1- اضافة حقلين في جدول الحركة واحد يخص نوع الحركة والآخر لمدخل البيانات ( حقل نوع الحركة صفر و واحد لم اوظفه بعد ولكن قد تحتاجه في التصفية) 2- لمسات على مصدر بيانات التقارير 3- نموذج للدخول 4 مستخدمين (كلمات المرور .. 1 و 2 و 3 و 4) يمكن لكل واحد منهم تعديل كلمة مروره (خصوصية) 4- عملت متغيرين عامين يحملان اسم ورقم المستخدم ( انظر في اعلى نموذج الحركة عند الدخول وبناء على متغير معرف المستخدم يتم ادراج معرفه داخل جدول الحركة 5- مخرجات التقارير ثابتة ( الاستلام والتسليم ) : اظهار آخر استلام للجهاز مع اظهار اسم الموظف المسؤول الذي ادخل البيانات اظهار آخر تسليم للجهاز مع من ادخل البيانات اذا واجهت صعوبة في فهم اي شيء عند النقل والتطبيق ,, لا تتردد أسألني ‏devicesdb15.rar

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

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

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

نسيت اذكر ان فورم العمليات يفتح آليا على حركة المبيعات ، ولأنه عند التبديل بين الحركات لا يوجد ما يستدل به على نوع الحركة ، لذا اضفت لمسة تعريف بنوع العملية . buyAsale2.rar

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

السلام عليكم ورحمة الله وبركاته سبق وان عملت امثلة وبرامج مصغرة ومختصرة للمبيعات والمشتريات ، ويمكن من خلال البحث في المنتدى تجدونها .وهذا العمل يختلف نوعا ما عن ما سبق . يسعدني ان ارفق اخر تطوير لعمليات البيع والشراء والمخازن ومنهجي الدائم في جميع مشاريعي هو استخدام الجدول الواحد في هذا العمل المرفق تم تحقيق التالي : 1- العمل المرفق هو زبدة النظام وان شئت نسميه المحرك الأساسي ، ويمكن ان يبنى عليه جميع التقارير التي تخطر على البال بلا استثناء 2- يشتمل على عمليات البيع وعمليات الشراء واختيار المخزن المناسب 3- يشتمل على عمليات المرتجع من المبيع او المشتريات على فرضية ان مرتجع البيع هو في الحقيقة شراء والعكس صحيح 4- امكانية البيع والشراء بالنقد والآجل 5- احتساب الضريبة في المبيعات . فقط 6- عملية تسجيل الاصناف بطريقة احترافية 7- استخراج ارصدة الاصناف حسب المخازن عند كل حركة 8- سهولة في الاستخدام ( جميع عملياتك بنقرة واحدة ) 9- المخرجات لم اعملها وانما تركتها لكم .. علما انه يمكن استخراج : - ارصدة المواد - الدائن والمدين والأرباح - الكاش والآجل للجميع او حسب كل عميل وأشياء اخرى يمكن استخراجها ستكتشفونها عند فحص وتجربة المثال اتمنى ان تجدوا فيه الفائدة .. ولا تنسوني من دعوة صالحة بظهر الغيب buyAsale1.rar

اكتب بريدك الاكتروني المسجل بالموقع بدلا من اسم المستخدم

اعداد المثال اخذ من وقتي اياما فرأيت ان افرده في موضوع يخصه هنا بأمل ان يتم تطويره

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

هل يعني هذا ان المطلوب تحقق؟ وطلبك هذا جديد ؟ بمعنى انك تريد تطبيق المعايير على استعلام آخر ؟