yitzchok

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

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

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

מקווה שעכשיו זה יותר ברור

אם כן, ראה פרק 15 של ה-SDK (אצלי עמוד 206)

פקודה של SQL Server כזו

select host_name()

תביא לך את שם התחנה.

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

מקווה שאתה איתי…

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

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

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

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

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

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

(למען האמת אני לא יודע איך זה עובד כשלר עובדים ישירות מול בית התוכנה כמונו)

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

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

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

אם אתם שואלים על גרסת SQL אני שואל לעצמי אם אתם לא בגרסת windows שישנה מדי או קרוב לזה.

תחום הרישוי של תוכנות מיקרוסופט באופן כללי אפור וקשה לקבל תשובות. מה שכן, כדאי להבין שאם קונים רשיונות למשתמשי SQL וזה נכון גם ל-windows server) בשיטת CAL – בעצם רק ככה קונים לפי משתמשים – שאלה מקנים זכות לחבר לכל ה-SQL שיהיו לכם בגרסאות המכוסות – כך שגם אם לא תמצאו דרך לחסוך רישוי עבור שרת פיתוח זה לא יכפיל את העלות אלא יוסיף רק עלות רשיון שרת.

הערה לגבי כמות הרשיונות: רישוי משתמשים במיקרוסופט עד כמה שידוע לי זה הקצאה למשתמש אנושי ורק ככה.
יוצא שאם אתם ברשיון צף בפריוריטי של 10 רשיונות אבל בפועל יש 20 עובדים במשמרות שונות תצטרכו 20 רשיונות CAL. מצד שני אם אתם ברשיונות named ויש לכם עובד אחד שהוא משתמש ב2 חשבונות פריוריטי המיועדים לו (אף אחד אחר לא משתמש בהם) אז מהבחינה הזאת תצטרכו אולי רשיון CAL אחד פחות מרשיונות פריוריטי.

מקווה שזה ברור וגם נכון…

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

יכול להיות שאתם עושים תנועות יומן שלא הזכרת? או אולי כבר יש תשלום בתשלומים במערכת, אך חשבוניות עדיין לא היו?