yitzchok

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

ושם מוסיף את העמודות הנוסופת הרצויות.

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

בינתיים נניח שתעשה את הכל בשלבי הכנה.

הנחה נוספת: המקור שלך מסודר וכל תאריך סיום אחרי תאריך ההתחלה הקשור אליו.

אני הייתי עושה כך:

1. אוסף (MIN(SDATE ו- (MAX(EDATE על פני כל התעודות – נקרא לאלה MIN_SDATE ו-MAX_EDATE
2. עושה לולאה פשוטה (לא קורסור). מתחיל מ-MIN_SDATE, בוחן אם מדובר בששי/שבת (או בתאריך של חופשים אחרים) ומדלג אם כן. (אם יש מצב של ששי/שבת שיכול להיות יום עבודה אז חזור למה שכתבתי קודם על נושא זה ושנה כאן בהתאם). את התאריך הזה מכניסים לטבלה (אם לא מדלגים) – טבלת STACK מצויינת לזה, רק לעשות 0+ כדי להפוך את התאריך למספר. וחוזר עד שמגיע ל-MAX_EDATE.
3. עושה שאילתא על בסיס טבלת התעודות, וטבלת התאריכים מהשלב הקודם. עושים תנאי שהערך מטבלת התאריכים צריך להיות בין ה-SDATE וה-EDATE של התעודה (כולל, אם כך אתה רוצה) ואז קבץ לפי DOC ותוציא ספירה (COUNT) של מספר השורות שאתה מקבל לכל ערך של DOC. תוכל כאן לדעתי לדלג על שמירת SDATE ו-EDATE כי תוכל להביא אותם לדו"ח ביחד עם הערכים האחרים. כך שאתה צריך להכניס רק שני עמודות DOC ו-COUNT לאיזו טבלת לינק.
4. כמו שלב 3 שלך

מה דעתך?

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

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

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

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

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

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

תראה את זה ככה:

אפשר להגדיר לכל משתמש הרשאות משלו. זה ע"י סייר ההרשאות.

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

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

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

שבוע טוב