PriorityDev

Forum Replies Created

מוצגות 15 תגובות – 1 עד 15 (מתוך 419 סה״כ)
  • Replies
  • PriorityDev
    משתתף
    IL
    תודה, הסתדרתי. כתבתי ככה.

    /*———————————————————–*/
    :PART = :SERN = 0;
    SELECT PART INTO :PART FROM PART WHERE PARTNAME = :$.PRT;
    /*———————————————————–*/
    LINK SERNUMBERS TO :$.PAR;
    GOTO 888 WHERE :RETVAL <=0;
    SELECT SERN INTO :SERN FROM SERNUMBERS WHERE PART = :PART;
    UNLINK SERNUMBERS;
    LABEL 888;
    /*———————————————————–*/
    SELECT SQL.TMPFILE INTO :$.PAR FROM DUMMY;
    LINK SERNUMBERS STK TO :$.PAR;
    GOTO 999 WHERE :RETVAL <=0;
    INSERT INTO SERNUMBERS STK
    SELECT * FROM SERNUMBERS ORIG WHERE SERN = :SERN;
    UNLINK SERNUMBERS STK;
    LABEL 999;
    /*———————————————————–*/

    • התגובה הזו עודכנה לפני לפני שנה 1, 11 חודשים ע"י PriorityDev.
    • התגובה הזו עודכנה לפני לפני שנה 1, 11 חודשים ע"י PriorityDev.
    PriorityDev
    משתתף
    IL
    ניתן לקבוע ערך חדש ב-PAR וה-HTMLCURSOR יתיחס לערך החדש

    יצחק,

    למה התכוונת? תוכל לתת דוגמת קוד?

    PriorityDev
    משתתף
    IL
    אתה צודק יצחק.

    אבל כאן כמדומני ה-HTMLCURSOR מקבל רק את ה-PAR המקורי ואי אפשר למסור לינקוק אחר.

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

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

    אפשר להוסיף שלב SQLI בין ה-INPUT ל-HTMLCURSOR.

    לשלב זה יש למסור גם את הפרמטר PAR וגם את הפרמטר הנוסף שלפיו רוצים לסנן את הטבלה של PAR.

    מלנקקים את הטבלה הרלוונטית ל-PAR ומוחקים מהטבלה המלונקקת ב-DELETE את הרשומות הלא רלוונטיות (כאן אפשר חופשי לבצע חיתוכים ע"י כל פרמטר נוסף).

    לאחר מכן ה-HTMLCURSOR יתייחס לפרמטר PAR עם השינויים שבוצעו ולא כפי שנקלט ב-INPUT.

    PriorityDev
    משתתף
    IL
    מסך האב והבן הם במצב שליפה.

    מסך הנכד (שעליו רוצים לעשות עיצוב שדות) – מצב כתיבה.

    רק קבוצת משתמשים מסוימת לא מסוגלת לבצע עיצוב שדות על המסך הנ"ל (לקבוצה זו יש הרשאת כתיבה על המסך הנ"ל).

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

     

    PriorityDev
    משתתף
    IL
    תמיד הייתי עושה כך:
    SELECT ATOD(DTOA(SQL.DATE,'DD/MM/YY'),'DD/MM/YY') FROM DUMMY FORMAT;
    PriorityDev
    משתתף
    IL

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

    +1000000!

    ENTMESSAGE זה הפתרון.

    PriorityDev
    משתתף
    IL
    איזו מלחמה, חבר? רק דנים דיון מקצועי.

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

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

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

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

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

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

    PriorityDev
    משתתף
    IL
    לא יודע מה זה נקרא אצלך יותר מדי פיתוח.
    לי לקח כשעתיים-3, בלי להרבות בפק"עות מיותרות.
    וכן, המלאי חייב להשתנות.
    מה שנשלח בחזרה לספק, צריך לרדת ממלאי שלנו, וכשהתקבל שוב – צריך לחזור.

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

    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

    PriorityDev
    משתתף
    IL
    yitzchok כתב:

    שקול גם EXECUTE BACKGROUND
    אולי גם ACTIVATE במקום WINACTIV

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

    בינתיים עשיתי כפי מה שרציתי. זה עובד מצוין.

    תודה, יצחק.

    PriorityDev
    משתתף
    IL
    yitzchok כתב:

    אם אני לא טועה באחת הגרסאות האחרונות אמרו ש-backflush כבר לא אמורה להפריע לעבודה. כדאי לבדוק.

    בדקתי. כן מפריע. תוקע את המסך עד סוף הריצה.
    גרסה 18.1

    PriorityDev
    משתתף
    IL
    yitzchok כתב:

    michaelm כתב:
    [quote]הודעת שגיאה.
    "D:\tmp/file.in", line 1: parse error at or near symbol BACKFLUSH_ONACCBAL

    נכון
    אני שם לב עכשיו שחסר לך פסיק אחרי ה 'P-'

    שלוף דוגמאות דרך windbi ותראה[/quote]

    צודק, פיספסתי פסיק.
    עכשיו עובד.

    PriorityDev
    משתתף
    IL
    בהתחשב במה שנעם כתב שזה יגרום להמתנה ארוכה במסך, אני חושב לעשות את זה אחרת:

    1. אבנה פרוצדורה על בסיס BACKFLUSH_ONACCBAL, רק שהיא בודקת קבוע מערכת (שאגדיר אותו) שיש בו דגל ורצה רק כשהדגל מורם.
    2. אריץ ב-TTS את הפרוצדורה החדשה (כל 10 דקות) בדומה להרצת BACKFLUSH_ONACCBAL.
    3. ארים את הדגל מהטריגר במסך לפי הצורך, ובסוף ריצת הפרוצדורה אוריד אותו.

    זה יפתור לי גם את בעיית הפרעות למשתמש המסך וגם את בעיית הסינטקס.

    מה אתה אומר, יצחק?

מוצגות 15 תגובות – 1 עד 15 (מתוך 419 סה״כ)