לצערי מקבלים את הרושם שכלי בפיתוח וכו' בפריוריטי אלה לא ממש פלטפורמה בא הם מנסים לתת לנו את כל הכלים שאולי היינו רוצים אלא מתחזקים מה שנח להם ומה שהם צריכים ואם אנחנו יכולים להשתמש בזה גם, כמה שיותר טוב.
אם הם לא מעוניינים להשקיע בזה – וטוב להם שנעבור ל-API – אז לא פלא שהם לא משקיעים.
אם יש workaround היה דורש כנראה להכין משהו דומה ולהתמודד עם השינוי ב-2017 שגרם להם לרדת מזה.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
הרי אם מדובר בהתקנה פרטית אבל משתמשים בממשק וובי, יתכן שאפשר יהיה לאפשר גישה לדטהבייס לצורך זה. כמובן בהתאם לכמה שרוצים לנתק את הדטהבייס מהעולם כדי להגן מפני פריצה.
מצד שני אם מדובר בפריוריטי כשירות, אני מתאר לעצמי שיש מצבים בהם הספק נותן גישה וובית למערכת ואולי גם מאפשר פעולות ספציפיות מול הדטהבייס באופן עקיף, אבל לא יאפשר גישה חופשית (אפילו מבוקרת) לדטהבייס.
כך שהתשובה שאתם צריכים עלולה להיות תלויה בתשתיות שלכם.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
פריוריטי סופטוור מכרו לכם את מודול ה-EDI במטרה המפורשת לתמוך בממשקים מול סגמנט? אני מציע שתבדקו שאמור לתמוך בהם.
מנסיון בעבר, החברות האלה יכולות לעבוד עם מבני קובץ שכמעט דומים אך שונים מספיק אחד מהשני עד כדי שממשק שבנוי עבור חברה אחרת לא תעבוד מולם, זאת אומרת צריכים ממשק שנכתב ספציפית לספק או תקן מאוד ברור וסגור.
יש חברות (לא PS) שמוכרות או ימכרו מודולים לעבודה מול סגמנט באופן מפורש. זה לא אומר שמודול ה-EDI של PS לא תומך/יתמוך בסגמנט, הרי מודול צד שלישי יכול להציע יתרונות אחרות כולל מחיר כדי שיהיה להם שווה להתחרות.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
ה-check field שלך מונע עדכון ומפיל את שאר העדכונים בממשק.
אם ה-check field לא פועל אז שולפים את הרשומה במסך העל ואז מוסיפים שורות למסך בן. אילו היה בקובץ מפתח יחודי של שורה במסך בן היה גורם לשליפה של השורה ועדכון שלו. בלי זה, ממשק מוסיף שורה.
אפשר להגדיר שמבסך הבן יש מחיקה והכנסה מחדש.
אבל נשמע לי שמניעת העדכון זה מה שצריך, ואתה רוצה להמשיך ברשומה הבאה במסך האב, זאת אומרת שכשלון במסך הבן יביא לדילוג של כל החבילה של השורה למסך האב והשורות למסך הבן.
תסתכל בהגדרות בכותרת הממשק. יש דגל או שדה (זה לא מולי כרגע אבל כזכור לי השם מזכיר דילוג) שקובע מה קורה במצב כזה, האם ממשיכים או האם זורקים את כל השאר שזה מה שאתה מזכיר עכשיו.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
הייתי חושב שלא יהיה חריג לתקוף את זה לא ברמה הטכנית אלא לומר שלא פשוט לכם אבל אין בעיה לשלוח לכתובת אחת ואם הספק רוצה שיארגן אצלו כתובת שהיא רשימת תפוצה ואז מיילים לאותה כתובת יגיעו למי שהוא ירצה…
אפשרות אחת, וזה תלוי בתהליך העסקי – להגדיר ב-BPM. או חוק אחד לפי שינוי סטטוס ההזמנה ובתנאי מספר הספק, שישלח לקבוצה שמוגדרת בפריוריטי, או כמה חוקים אחד לכל נמען. היתרון בראשון שיחסוך בחוקים והכנת מיילים והנמענים יראו את השני במייל, אבל צריכים שתהיה קבוצה כזו ברשימת הקבוצות הכללית.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
נראה לי שאחסון רשומות לא מתאים במקרה זה, למיטב ידיעתי הפונקציה הזאת מעתיקה רק לאותו מסך תחת רשומה אחרת.
לא יודע לענות לגבי הפיכת האותיות.
אולי כמות ההזמנות קטנה ולא שווה להשקיע אבל לרוב היינו ממליצים לארגן הוצאת הנתונים מהאתר שהיה נותן לקלוט את הנתונים בפריוריטי בממשקים. כל עוד הקבצים יהיו בצורה הנכונה לא צריך להיות צורך לפיתוח בפריוריטי.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
עד כמה שאני זוכר היה קשור לשכבה של השכתוב מה-SQL של פריוריטי ל-SQL של הדטהבייס מתחת. או שהתרגום עצמו הסתבך והתעכב בגלל מספר הטבלאות (או מופעים של אותה טבלה, אני לא זוכר) או שבגלל כמות הטבלאות יצאה שאילתא לא יעיל וזה הקשה על הדטהבייס מתחת.
אני לא אומר שזה בטח מה שקורה כאן אבל הייתי חושש שיכול להיות משהו דומה.
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
שאלתי את השאלה הקודמת בעיקר להבהרה כי למונח "חתימה אלקטרונית" יש כבר מובן אחר בפריוריטי.
כנראה אנחנו לא יודעים לענות לכם.
אני הייתי מנחש שטכנית יהיה אפשר, אבל אולי חוקית תהיה שאלה. אני לא יודע כמה צריכים לשמור תעודה לשימוש אישי. תלוי אולי בסוג התעודה – יש גם אישית וגם ארגונית?
[ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
