חיבור מערכת ל-Priority

מאת צוות מדיה דיל · 12.08.2026 · Automation & Integrations · 6 דק׳ קריאה

מה כרוך בחיבור Priority למערכות חיצוניות: API מול ODBC, הרשאות משתמש שירות, מיפוי טבלאות, טעויות נפוצות וסנכרון חד או דו-כיווני בין Priority לאתר, CRM או כלי דיווח.

Priority היא אחת ממערכות ה-ERP הנפוצות ביותר בישראל, ועסקים רבים שמנהלים בה מלאי, הזמנות וחשבונות מגיעים לנקודה שבה הם צריכים שהיא "תדבר" עם מערכות נוספות - אתר מסחר, CRM, מערכת סליקה או כלי דיווח. חיבור מערכת ל-Priority אפשרי ומקובל, אבל הוא דורש הבנה של האופן שבו Priority חושפת את הנתונים שלה, ולא רק "לחבר API" כמו במערכות SaaS מודרניות. במאמר הזה נסביר את העקרונות המרכזיים.

איך Priority חושפת נתונים החוצה

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

אימות והרשאות בסביבת Priority

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

מיפוי שדות וטבלאות

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

עבודה מול Priority Cloud לעומת התקנה מקומית

נקודה נוספת שמשפיעה על אופן החיבור היא האם Priority מותקנת מקומית (On-Premise) אצל הלקוח או מופעלת כשירות ענן (Priority Cloud). בהתקנה מקומית לרוב נדרשת חשיפת השרת החוצה בצורה מבוקרת, לעיתים דרך VPN או פתיחת גישה ממוקדת בלבד לכתובת השרת של האינטגרציה, כדי לא לחשוף את כל הרשת הפנימית. בגרסת הענן הנגישות ל-API פשוטה יותר בדרך כלל, אך עדיין דורשת תשומת לב לאותם עקרונות אבטחה - הרשאות מוגבלות, ניטור שימוש, וסביבת בדיקות נפרדת מהייצור.

סנכרון חד-כיווני מול דו-כיווני

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

טיפול בהיסטוריית נתונים ובייבוא ראשוני

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

טעויות נפוצות בפרויקטי Priority

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

מי בונה מה, וכמה זה עולה

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

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

תגיות: חיבור Priority · אינטגרציית Priority · Priority ERP API · אינטגרציית ERP · מיפוי שדות · סנכרון מלאי

← חזרה לבלוג · צור קשר