yitzchok

6. testcompany – שם חברה בפריוריטי.

הכוונה לשם הפנימי של החברה/סביבה. לא מה שרואים בכותרת המסך.

לגבי tabula_ini אצלי זה tabula.ini – יכול להיות שפרט זה השתנה בין גרסאות פרירויטי?

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

ממשק מסך יכול לשמש לפריקת נתונים גם כן.

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

אני מקווה שכל זה עונה על שתי השאלות שלך.

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

הדבר לא פשוט

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

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

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

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

כתבתי הרבה, מקווה שאתה מבין את הקושי

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

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

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

בבקשה alunh תתני קצת יותר פרטים כי ממה שאני ראיתי בצילום המסך זה לבד לא קידם אותנו

לצערי אין לי פתרון של ממש להציע 🙁

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