אלון ארנסטי

מרינה,

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

עלויות פריטים בפועל מחושבים על-פי שיקלול כל התנועות או החשבוניות שהופקו עבור פריטים אלה. השיקלול מבוצע באחת משתי השיטות העיקריות שנבחרה: ממוצע נע (ממ"ן) או FIFO. זה מתואר באשף.
מחיר אחרון הוא ממש לא כמו מחיר עלות. מחיר אחרון משקף את המחיר האחרון ביותר שהתקבל למוצר ומדובר בעצם על המחיר המעודכן ביותר שהספק מציע. העלות משקפת את השיקלול של כל התנועות שהיו למוצר. העלות גם משקפת את תוספת העלויות הנילוות לפריט כגון הובלה.
לדוגמא, ספק רחוק מוכר לך 100 מנועים חשמליים במחיר של 10 שקל ליחידה. סך הכל יש לשלם לו 1000 שקל. צריך גם להוביל את הסחורה למחסן החברה שלך והתשלום להובלה הוא 100 שקל. סך הכל שילמת עבור הקניה 1100 שקל ולכן עלות של מנוע אחד היא 11 שקל, למרות שמחיר אחרון הוא 10 שקל. בסופו של דבר הפריט עולה לך יותר ממחירו של הספק כי את מוסיפה לו עלויות נלוות.

אני מקווה שזה קצת יותר מובן לך עכשיו.

אלון.

היי סוניה,

1)
אני לא ממש מבין את השאלה הראשונה. לפי מה שהבנתי, את מבקשת שכאשר מנהל בכיר כלשהו רוצה לשנות אל סטטוס 'תיקון', אז בשדה 'לטיפול' יהיה רשום גם הסוכן וגם מנהל X? זה בלתי אפשרי לקבוע את זה לשניהם בו זמנית.

אם תירצי רק לאחד מהם, קיבעי חוק במחולל הנתונים.

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

אלון.

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

מהי הסיבה שאתה מבקש לחרוג מהנוהל הסטנדרטי?

היי סוניה,

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

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

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

אלון.

אז אני מבין שמותקן אצל בנייד תוכנת פריוריטי עבור תירגול.

את הגדרת בסדר את הסטטוס. הסיבה שאותו היוזר אינו מקבל מייל הוא משום שאצלך לא פעילים ה-Services השונים כדוגמת Tabula Task Scheduler.

הפריוריטי היא מערכת המותקנת על מחשב שרת (Server) וה"יוזרים" שהם בעצם ה"לקוחות" (Clients) מתחברים לשרת על-מנת להשתמש במערכת. בשרת פועלים תוכנות אוטומטיות נוספות שתפקידן לנהל את תפעול הפריוריטי מבחינת האירועים שמתרחשים בו ואת כל נושאי המיילים בין המשתמשים ומיילים מחוץ ל-Domain של המערכת.

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

אלון.

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

חץ מסמל מעבר בין סטטוסים, ולכן חוק המוכל על חץ יופעל רק כאשר יהיה מעבר בין הסטטוס הנמצא במוצא החץ לבין הסטטוס הנמצא בסופו של החץ.

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

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

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

אלון.

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

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

אתן לך דוגמא מציאותית בתחום האלקטרוניקה:
נניח שקיימים שני נגדים בעלי אותו ערך ואותו פיזור הספק, אך אחוז הדיוק של נגד X הוא 5% ואחוז הדיוק של נגד Y הוא 1% שמדויק יותר (וגם לעיתים יקר יותר). כמובן שנגד Y מהווה תחליף לנגד X. השימוש בתחליפי נועד למקרה שאם במהלך הרצת MRP מתגלה שאין מספיק מלאי מ-X (הקיים בעץ של מוצר A), אז המערכת תמליץ לנפק את נגד Y, וזאת על-מנת לא לעכב יצור עד שיתמלא המלאי של X בעקבות תהליך רכש שיכול לפעמים להיות ממושך.

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

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

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

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

צר לי שלא יכולתי לעזור לך יותר.

בהצלחה,
אלון.

תאורתית ומעשית במבנה נתונים, בחיים לא יינתן האפשרות לתת סימן אוניברסלי כמו ה-$ עבור גישה ל-Sub Level.
הסיבה היא בגלל האנלוגיה למבנה של "עץ". לענף כלשהו יש רק אב ישיר אחד, אבל לאב כלשהו יכול להיות שיהיו לו יותר מבן אחד, לכן כיצד המערכת תדע בדיוק לאיזה בן לגשת עם ה-"מחוון האוניברסלי"?
כל שפות התכנות למיניהן "שונאות" כל מידה של אמביוולנטיות (דו-משמעי) שזה נוגע לפרמטר שצריך לפנות אליו.

אלון.