אלון ארנסטי

Forum Replies Created

מוצגות 15 תגובות – 31 עד 45 (מתוך 359 סה״כ)
  • Replies
  • ראיתי שבפסוקית ה-INSERT INTO שלך את ביקשת לבצע הזנה אל 11 שדות שונים, אך בחלק של VALUES בפועל קיימים רק 7 ערכים לטעינה. על-פי המשפט שרשמת, הערך של פרמטר POS ייטען אל העמודה METBASEDATE.
    מה לגבי ה-4 הנותרים?
    ניסית לבצע את המחיקה באמצעות Ctrl+Delete?
    היי סוניה,

    במסך חשבונות מערכת איזה חשבון מקושר אל קניות/מלאי?

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

    האם בדקת שתופעה זאת קורית עבור כל הספקים?

    אלון.

    • in reply to: טבלה
    שלום יוסי,

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

    אני מבין שבנית את הטבלה שלך ממחולל הטבלאות והטבלה מכילה את המפתח הראשי שלך מטיפוס מפתח A, ואני גם מניח מטיפוס נתון INT.
    עוד לפני שאתה ניגש למחולל מסך הצעות מחיר באמצעות F6, את אותה עמודת המפתח מהטבלה שלך אתה חייב להוסיף גם לטבלת CPROF עם אותם המאפיינים. קוראים לזה "מפתח זר". באמצעות מפתח זר ניתן לבצע בדיוק את הקישור המבוקש מטבלת CPROF אל הטבלה שלך. דרך אגב, בטבלת CPROF, סוג המפתח של העמודה יהיה מטיפוס N, או שלא תספח לה מפתח בכלל. טיפוס N אומר שניתן לשלוף שאילתות באופן מהיר יותר מעמודה זו (מכנים את זה: אינדקס. כפי שקיים בסוף רוב ספרי הלימוד) ומותר שיהיו ערכים זהים של העמודה ברשומות שונות בטבלת CPROF.

    אחר-כך תוכל לגשת למחולל המסך של הצעות מחיר ולהוסיף שתי שורות:

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

    ב) עמודת התיאור מתוך הטבלה שלך. זאת תהיה העמודה אשר יהיה גלוי ותוכל כמובן לבצע ממנו רשימת בחירה באמצעות בניית טריגר CHOOSE-FIELD על המסך שתבנה גם לטבלה החדשה שלך. התכנות של הטריגר מתואר ב-SDK.

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

    היי סוניה,

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

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

    אלון.

    האופציה לא קיימת לעומת תעודות משלוח ללקוח.

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

    היי במבי,

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

    אלון.

    ניהול ספרי חשבון חלק א'
    מאת: דוד טל ודליה רז
    הוצאת: טור

    יש גם חלקים ב' ו-ג' אבל זה כבר לרמה מתקדמת.

    שלום גלית,

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

    התשובות לשאלותייך
    1) כן.

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

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

    4) בקשר לתכנון נכון של רכש עבור פריטים בעלי Lead Time ארוך במיוחד, הכל תלוי בדרך שאתם "מכוונים" את המערכת.
    תביני שהבסיס לריצת MRP הם ההזמנות. קיימות שתי סוגים של הזמנות עיקריות: הזמנות לקוח "ספונטניות" והזמנות למלאי של המפעל. במקרה שבו ציינת, על המפעל לדעת כיצד להיערך מראש במקרה של קבלת הזמנת לקוח הדורשת רכש של פריטים "ארוכי טווח". הדרך לעשות זאת היא באמצעות קביעת עיתוד מלאי נכון וקביעת מדיניות ניהול מלאי ויצור. את בדיוק נגעת כאן בנושא שמאוד כואב להנהלת המפעל והוא: כיצד ניתן לספק מוצר ללקוח במינימום זמן ובמינימום הוצאות תפעוליות? להחזיק תמיד מלאי של רכיב בעל LT ארוך עולה כסף ובוודאי שאינו מועיל לשמור כמות גדולה במלאי אם הזמנות לקוח אינם מבוצע באופן שוטף. קיים כאן חשש להצטברות מלאי מת בעתיד, ובעיקר זה יהיה קריטי כאשר לא תוכלו למכור פריטים אלה לגורם שלישי כי הפכו להיות פגי-תוקף או טכנולוגיה ישנה.
    אחד הדברים שניתן לעשות במקרה הנ"ל, הוא להחליט על מלאי בטחון אופטימלי לרכיב זה ולקבוע עבורו טיפוס מדיניות עיתוד שלא לפי דרישות פיצוץ עץ ( טיפוס B ).

    אלון.

    היי עופר ובמבי,

    עוד מספר תוספות:

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

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

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

    אלון.

    מה את מבקשת לעשות?
    לבנות סטטוס שכאשר תבצעי את הקישור של תע' המשלוח אל ההזמנה ותחליטי שאת רוצה לשנות את תאריך האספקה בהזמנה, אז אוטומטית תאריך האספקה הרשום בתע' משלוח ישתנה בהתאם?

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

    אלון.

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

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

    אנסה בכל זאת להעביר לך את הדברים העיקריים ואתחיל בלענות על שאלותייך:

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

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

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

    אלון.

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

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

    אלון.

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

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

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

    אלון.

    התשובה היא לא.

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

    ציטוט קודם:

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

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

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

    אלון.

מוצגות 15 תגובות – 31 עד 45 (מתוך 359 סה״כ)