אינטגרציה עם API של פריוריטי: מדריך שטח למפתחים

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

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

למה ההערכות יוצאות שגויות

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

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

לכן השאלה הראשונה בכל פרויקט פריוריטי היא לא טכנית. היא: אפשר לקבל סביבת בדיקות ורשימת שדות?

צ'קליסט לפני אפיון

אל תתמחרו אינטגרציית פריוריטי לפני שיש לכם תשובות לכל אלה:

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

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

דפוסים שמחזיקים

כתיבות אידמפוטנטיות

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

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

שכבת ביניים לפני רישום

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

חיפושים ניתנים למטמון, מסמכים לא

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

מפו שגיאות מוקדם

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

הזרמים שבאמת בונים

התאמת לקוחות היא העבודה האמיתית

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

1. התאימו לפי מספר עוסק או ח.פ. מנורמל כשיש לכם. זה המפתח האמין היחיד.
2. גיבוי למזהה חיצוני שמור אם אינטגרציה קודמת כתבה אחד.
3. אם אין התאמה, צרו לקוח חדש - אבל סמנו אותו לבדיקה במקום לסמוך עליו בשקט.
4. לעולם אל תדרסו רשומת לקוח קיימת בפריוריטי בנתונים חיצוניים. הוסיפו, אל תחליפו.

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

לוחות זמנים ריאליים

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

לפני שמתחילים

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

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