PriorityDev

Forum Replies Created

מוצגות 15 תגובות – 346 עד 360 (מתוך 419 סה״כ)
1 2 3 … 23 24 25 26 27 28
  • Replies
  • PriorityDev
    משתתף
    IL
    תודה.
    PriorityDev
    משתתף
    IL
    שלום, ארז

    ניסיתי להבין, מהי השאלה ולא כל כך הצלחתי.

    מה אתה מנסה לעשות בדיוק?

    PriorityDev
    משתתף
    IL
    שלום, ליאור.

    אתה מתכוון לעשות שתי "עטיפות" שונות – אחת ל-SCHEDULE ואחת להפעלה ידנית?

    PriorityDev
    משתתף
    IL
    ארז, שלום.

    רשימות בחירה דינמיות זה דווקא בכלל לא בעיה.

    PriorityDev
    משתתף
    IL
    תשמע, גם פתרון של 12 דוחות זהים הוא לא הכי טוב…
    אבל הבעיה היותר גדולה בפריוריטי – חוסר אפשרות לSQL דינמי.
    אין מה לעשות, סביבת הפיתוח של פריוריטי היא לא החדשנית ביותר…
    PriorityDev
    משתתף
    IL
    דוח טבלאי במקרה שלי לא היה עוזר

    כאיפיינו את הפרויקט, הייתה גם מחשבה לתת למשתמש לא דו"ח אלא מסך, ואז אותו צורך היה במסכים…

    PriorityDev
    משתתף
    IL
    שלום, ליאור

    אצלי, למשל היה צורך להריץ איזשהו דו"ח תחזית חצי שנה קדימה, כאשר השדות הם שמות חודשים, כלומר, אם מריצים מינואר או ממרץ – כותרות השדות משתנים.

    אחרי נסיונות למיניהם שיכפלתי את הדוח 12 פעמים והרצתי מהפרוצדורה את הדוח הרצוי באופן דינמי. כמובן, שעל כל שינוי קטן בדוח צריך עכשיו לחזור 12 פעמים.

    PriorityDev
    משתתף
    IL
    " פשוט לעשות כמה דוחות ולקרוא להם באופן דינמי."
    התכוונתי לכותרת דונמית בדו"ח שמופעל בפרוצדורה.

    במסך – אין לי עצות.

    PriorityDev
    משתתף
    IL
    שלום, מיכאל

    הפתרון של UPDATE כל כך לא מתקבל על הדעת, שאף אחד אפילו לא מדבר על זה…

    הפתרון שלך הוא בעצם אותו דבר כמו הפיתרון של ליאור בענף ההוא, אבל ספק גדול אם זה יעבוד. כנראה, יותר פשוט לעשות כמה דוחות ולקרוא להם באופן דינמי.

    PriorityDev
    משתתף
    IL
    1. נכון, אין במערכת את כל הנתונים הדרושים. וגם מה שכיביכול קיים בדו"ח הסטנדרטי, אינו משקף את התמונה האמיתית (למשל, איחורים באספקה הם לאו דווקא באשמת ספק).
    2. עדכון הנתונים צריך להתבצע לא ברמת ספק, אלא ברמת תעודה, כלומר, ע"י אנשי רכש, QA, מחסן וכו' – כל אחד בתעודות שלו. וזה דורש מחשבה רבה ופיתוח מורכב + מלחמת חינוך גדולה עם משתמשים שלא יהיו מוכנים למלא שדות נוספים מעבר למה שהם רגילים.
    3. נראה לי, שכבר הבנתה, שלא ניתן כאן לבנות משהו רציני ללא ניתוח מעמיק + מפתח מיקצועי.
    PriorityDev
    משתתף
    IL
    הסיבה שלא ניתן לשדרג את הדו"ח הסטנדרטי היא, שהחישוב מבוצע שם ע"י תוכנית מקומפלת ולא ע"י תוכנית SQLI עם קוד פתוח.
    PriorityDev
    משתתף
    IL
    שוגי, בוא נעבור ממשפטים כלליים להגדרות מדוייקות.
    1. איכות = "הכמות והאחוז של מוצרים שנפסלו וסיבות הפסילה" – ראה דוח סטנדרטי
    2. לו"ז = "מספר האיחורים באספקא" – ראה דוח סטנדרטי
    3. רמת שרות – מה זה?
    4. מענה מהיר לבל"מ – מה זה?
    PriorityDev
    משתתף
    IL
    לפי מה ששוגי שואל, נשמע שהוא דווקא מתיעץ, באילו פרמטרים ניתן לבחון ספקים.
    מה שתיארתי לו זה לוגיקה דומה לדו"ח הסטנדרטי (אמינות הספק) אך נותנת תוצאות אמיתיות. אנחנו לא היתקנו את הלוגיקה מהסנדרט, אבל זה מה שמתבקש ולא נראה שיש משהו אחר (במקרים הסטנדרטיים).
    PriorityDev
    משתתף
    IL
    שוגי, שוב, תלוי מה רוצים לקבל. בגדול, הנקודות שתיארתי, הן הנקודות בהן ניתן למדוד את הספק.

    מיכאל, רוב הפיתוח הוא לא בדו"חות.
    בשביל לדעת, אם הספק עומד בזמני אספקה, אתה צריך לפתח לוגיקה במסכי הזמנות רכש/קבלת סחורה מספק, המאפשרת לדעת, האם העיקוב היה באשמת הספק או גורמים אחרים.
    כמו כן, יש לפתח לוגיקה דומה במסך החזרת סחורה לספק.
    בנוסף, לא ידוע לי על מסך סטנדרטי, המאפשר מעקב אחרי מוצרים שנמצאים בתיקון אצל ספק. במקרה הזה נאלצנו לפתח מודול שלם עם סוג תעודות חדש, תהליך BPM מוגדר וכו' וכו'.
    כך שהדו"ח עצמו זה רק בורג קטן של המערכת.

    PriorityDev
    משתתף
    IL
    שלום,
    בנינו אצלנו כזה מודול. הלוגיקה שלו מאוד מורכבת. בגדול, מדדנו את הספקים לפי קריטריונים הבאים:
    1. הזמנות רכש, קבלת סחורה – עמידה בתאריכים.
    2. בדיקת מעבדה – אחוז פסילות.
    3. מוצרים שחוזרים לתיקון אצל ספק – איכות שרות, עמידה בזמנים.

    זה רק בגדול. מכאן הדרך ארוכה. קביעת אופן הניקוד יכולה לשנות את התמונה מקצה לקצה…
    תלוי באיזה זום אתה רוצה לראות. מערכת BI היתה תורמת כאן הרבה.

מוצגות 15 תגובות – 346 עד 360 (מתוך 419 סה״כ)
1 2 3 … 23 24 25 26 27 28