yitzchok

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

בתנאים מסוימים יכול להיות שהמחיר – ליחידה (בלבד, אם אני לא טועה) – בשורת החשבונית נקבע במטבע אחר

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

דוגמה קלאסית מלפני המעבר לשימוש בשקל בארץ:

חשבונית מוגדרת בשקל

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

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

אותם דולרים הפכו לשקלים וסה"כ בחשבונית היה בש"ח

ואני פורס על שורות כדי שהכינון יהיה ברור יותר
)
ROUND(INVOICESA.AVRGDATE) <> 0
?
((0 + INVOICES.PAYDATE) – ROUND(INVOICESA.AVRGDATE)) / 1440
:
0
(
המשמעות:

אם אין תאריך ממוצע אז חוזרים ל 0

אבל אם יש אז לוקחים את התאריך פרעון (בדקות, מאלצים לא להיחשב כתאריך, תאריך הוא בעצם INT מיוחד) ומורידים את תאריך הממוצע (בדקות, כמספר שלם, הרי הוא שמור כ-REAL) ואז מחלקים כדי לקבל מספר ימים

גם אם זה לא מה שאתה צריך אני מקווה שזה יקדם אותך

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

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

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

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

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

את החלק הזה אני פשוט לא מבין

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

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

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

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

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

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

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

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

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