yitzchok

למיטב ידיעתי כך המערכת עובדת ועמודות ריקות נעלמות רק בתעודות ולא בדו"חות רגילים

בסגורה הכוונה למותאמת או פשוט סופית?

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

זה ברמת הדטהבייס שלכם
אם זה mssql או אורקל הכל בהתאם

(אבל אם אתם משתמשים בשירות של פריוריטי בווב אז יהיה סיפור אחר, דבר איתם)

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

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

במסמך sdk יש פרק שמזכיר פונקציות שימושיות.

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

שאלות נוספות אפשר לשאול כאן.

אתה יכול להסתיר את העמודה במחולל הדוחות. הפתרון כדי לשמור על הצביעה הוא לתת לעמודה של הצבע ערך ב"ע. מיון" – ערך גבוה שלא יפריע למיון האמיתי.

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

Note: If you wish to create a customized user report generator from a
standard report generator form other than ASSETREP, make sure to choose
one in which the expression defined for the TYPE column is 'r' (in the Form
Column Extension sub-level of the Form Generator). While different values in
the TYPE column were once used to distinguish between different types of
user generated reports, newer report generators all use the same TYPE ('r'),
and assign each report name a different prefix instead.


כמובן התכוונתי למסך הבן…

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

אם המטרה היא למנוע גישה למסך הבן למה החסימה לא ב-PRE-FORM של מסך האב?

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