הרצת BACKFLUSH מטריגר של מסך

› פורומים › אפיון ופיתוח פריוריטי › הרצת BACKFLUSH מטריגר של מסך

  • Post
    • מרץ 24, 2019 בשעה 11:49 pm
    PriorityDev
    משתתף
    IL
    שלום לכולם,
    אני רוצה להריץ BACKFLUSH מטריגר של מסך (אם יהיה צורך אסביר למה אני צריך את זה).
    3 שאלות:

    1. האם הרצת BACKFLUSH תדירה באופן אוטומטי יכולה לשבש מלאים?

    2. האם הרצת BACKFLUSH ברקע יכולה לגרום למשתמש המתנה ארוכה?

    3. מצאתי ב-TTS הרצה ע"י סינטקס כזה:
    WINACTIV -P BACKFLUSH_ONACCBAL
    ב-WINDBI סינטקס כזה מחזיר הודעת שגיאה.
    ניסיתי:

    WINACTIV -P BACKFLUSH_ONACCBAL;
    EXECUTE WINACTIV -P BACKFLUSH_ONACCBAL;

    מישהו יודע איך להריץ את זה נכון?

    תודה.

מוצגות 8 תגובות – 16 עד 23 (מתוך 23 סה״כ)
1 2
  • Replies
    • מרץ 26, 2019 בשעה 2:12 pm
    PriorityDev
    משתתף
    IL
    נעם-גלובל כתב:

    אני מצטרף לדעה של שוגי. יש טעם להריץ BF רק כאשר יש הצטברות דיווחי יצור, וכמובן תלוי באיך אתם מגדירים/מתיחסים אל "REAL TIME" אצלכם.

    אצלי REAL TIME = יום, כך אין סיבה להריץ את BF יותר מפעם ביום. אם אצלכם RT = שעה, אז יש הצדקה להריץ (דרך TTS) פעם בשעה.

    OK, כנראה שאני צריך להסביר את הצורך שלי (אגב, את הפתרון כבר יישמתי והוא עובד).
    ה-BF אצלנו רץ פעם ב-12 שעות, וזה בסדר.

    יש כרגע בעיה נקודתית:
    פותחים פק"ע + הזמנת רכש לקב"מ.
    כשמקבלים סחורה לקב"מ, נוצר דיווח בפק"ע המקושרת להזמנה.
    כשמחזירים סחורה לקב"מ (נגיד בגלל פסילת איכות), זה מטפל במלאים וביתרות בהזמנה, אבל לא בדיווחים בפק"ע.
    אשבל כבר הכניסו את זה לתוכנית פיתוח עתידית שלהם, אבל כרגע הפתרון שהם מציעים הוא לעשות קבלת סחורה מספק במינוס.

    הפתרון הזה אכן עובד, אבל יש 2 בעיות:
    1. אם הפק"ע הייתה סגורה, היא לא נפתחת בחזרה.
    את הבעיה הזו פתרתי בקלות ע"י הרצת ממשק מהטריגר.
    2. נוצר מלאי לא מקוזז, כלומר, המערכות המיוצרות נגרעות מהמלאי, אבל רכיבי הניפוק מגיעים למלאי רק אחרי הרצת BF.
    לכן עלה צורך להריץ BF בו בזמן.
    ואני דווקא לא מחפש להריץ BF בתדירות גבוהה, אלא רק מתי שצריך (קבלת סחורה מספק במינוס לא קורת הרבה).
    אכן פתרתי את הבעיה כפי שתיארתי כאן:
    https://www.priority-forums.com/he/index.php/forums/6-%D7%90%D7%A4%D7%99%D7%95%D7%9F-%D7%95%D7%A4%D7%99%D7%AA%D7%95%D7%97-%D7%A4%D7%A8%D7%99%D7%95%D7%A8%D7%99%D7%98%D7%99/21493-%D7%94%D7%A8%D7%A6%D7%AA-BACKFLUSH-%D7%9E%D7%98%D7%A8%D7%99%D7%92%D7%A8-%D7%A9%D7%9C-%D7%9E%D7%A1%D7%9A#21510

    • מרץ 26, 2019 בשעה 3:47 pm
    אלמוני
    אורח
    הבנתי,
    אני לא רואה את זה כפתרון אידיאלי, זה יותר מדי פיתוחי ופחות מדי יישומי או מערכתי.
    אני פתרתי בעיות של פסילה ע"י יצירת פק"ע ייעודית לתיקון שמבוססת על הפק"ע המקורית אבל עם מספור שונה וללא ניהול מלאי של הפק"ע הזאת ותהליך שמתוקן ידנית לצורך התיקון (פעולות לדוגמא: הסרת ציפוי, פירוק וכו…).
    היתרונות הם:
    1) התיעוד של הקבלה מהספק רשום.
    2) התיקון הוא בפקע ייעודית שברור לכל כולל הספק שהיא REWORK – זה כתוב במספר הפק"ע ולכן זה מדיד – דבר שאתה מאבד בשיטה שלך.
    3) כל התיקון אינו משפיע על המלאי למעט מקרים בודדים בהם נדרשת תוספת חומר.
    4) החומר שצריך לתקן יוצא מהתהליך לתיקון וחוזר מתוקן לאותה נקודה בתהליך.
    כל זה עם דו"ח תקלה שמתעד את הפסילה אבל בלי כל ההרצות שרשמת.
    • מרץ 26, 2019 בשעה 4:11 pm
    PriorityDev
    משתתף
    IL
    לא יודע מה זה נקרא אצלך יותר מדי פיתוח.
    לי לקח כשעתיים-3, בלי להרבות בפק"עות מיותרות.
    וכן, המלאי חייב להשתנות.
    מה שנשלח בחזרה לספק, צריך לרדת ממלאי שלנו, וכשהתקבל שוב – צריך לחזור.

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

    • מרץ 26, 2019 בשעה 4:39 pm
    אלמוני
    אורח
    יותר מדי פיתוח זה לא כמה זמן לקח אלא באיזה דרך פותרים בעיה, כלומר: האם משתדלים לפתור בדרכים יישומיות שנשענות כמה שיותר על מה שקיים בפריוריטי ופחות על פיתוח או ההיפך.
    אני דוגל בגישה היישומית למרות שאני גם מפתח לא מעט, אחרים דוגלים באחרת וזה בסדר, לא חייבים לחשוב אותו דבר.

    אם הפתרון שמצאת טוב לך אז סבבה.
    יום טוב.

    • מרץ 26, 2019 בשעה 4:48 pm
    PriorityDev
    משתתף
    IL
    אני דוגל בפתרון שפותר את הבעיה עם כמה שפחות שינויים בתהליכים סטנדרטיים וכמה שפחות להרבות בישויות ומסמכים מיותרים.
    אם יישום עונה על זה – מצוין.
    אם פיתוח עוזר יותר טוב – צריך לפתח, בלי תאוריות.

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

    • מרץ 26, 2019 בשעה 6:06 pm
    אלמוני
    אורח
    איך הסקת שהפתרון המועדף עלי "משנה את כל סידרי העבודה בתפ"י/ייצור/רכש, הורס עקבות אחורה, גורם לעיוותים במלאים רק בגלל שהוא "דוגל בפתרונות יישומיים"."

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

    יום טוב.

    • מרץ 26, 2019 בשעה 6:28 pm
    yoram
    משתתף
    היי שוגי,

    שאלה לגבי התהליך שתיארת כי הוא מתאים לתהליך שאני גם יישמתי :

    1. אם הפק"ע באמצע התהליך נדרשת בתיקון – גם אז אתה פותח פק"ע תיקון ? ואם כן אז איך אתה סוגר בצורה נכונה את הפק"ע המקורית ? ומקשר ביניהן ?

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

    3.אם הפק"ע תיקון לא משפיעה על המלאי, אז איך בסוף התהליך נוצר מלאי מהפק"ע המקורית או מהפק"ע תיקון ?

    4. מה כוונה שביססת את הפק"ע תיקון על הפק"ע המקורית – האם יצרת קשר ביניהן ע"י שדה מותאם שמחזיק בפק"ע תיקון את מספר הפק"ע המקורית ?

    תודה.

    • מרץ 26, 2019 בשעה 6:41 pm
    PriorityDev
    משתתף
    IL
    איזו מלחמה, חבר? רק דנים דיון מקצועי.

    למה החלטתי שהפתרון שלך לא טוב – כבר הסברתי:
    1. היום התפעול עובד עם פק"ע אחת ורואה שם את כל התנועות. אתה מציעה להכריח אותם לשנות את סדרי העבודה, לפתוח פק"ע נוספת ולתחזק את שתיהן.
    2. בשביל לראות התנהלות מול קב"מ בכל פרויקט, יצטרכו לעקוב בשני מקומות במקום 1.
    3. יהיה צורך לשנות את הדו"חות (כולל BI) שמותאמים היום לתהליך הקיים, ומאידך – עדיין לתחזק דו"חות שמסתכלים על פרויקטים שלפני השינוי. קרי – חוסר עקבות אחורה + צורך בהרבה פיתוח.
    3. בפתרון שלך המלאי לא מתעדכן, וזה לא נכון. המלאי צריך להתעדכן. כל הפרויקטון הזה התחיל מהבעיה שהמלאים לא התעדכנו נכון. ואתה מציעה פתרון שלא יעדכן מלאי בכלל.
    כלומר, יש תהליך פשוט שעובד מצויין, רק חסר 10% לתוצאה הרצויה, שאפשר להשלים את ה-10% ע"י פיתוחון פשוט.
    ואתה מציע לשנות את כל התהליך כאשר הדבר יגרום שיהיה חסר 80% לתוצאה הרצויה + יגרום בעיות נוספות + יצור צורך בפיתוח הרבה יותר מסיבי.

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

    אז איזו דרך היא באמת קלה ופשוטה? ובלי הרבה פיתוחים? והעיקר – נכונה?

    שום דבר אישי, רק דיון מקצועי.

מוצגות 8 תגובות – 16 עד 23 (מתוך 23 סה״כ)
1 2
  • יש להתחבר למערכת על מנת להגיב.