אוטומציה עם פריוריטי (Priority) - עבודה מול ה-API להזמנות, מלאי ודוחות

למה פריוריטי היא מקרה מיוחד

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

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

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

מה פריוריטי חושפת החוצה

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

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

איך הממשק בנוי

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

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

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

המלכודת הראשונה: שמות

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

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

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

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

עבודה עם הזמנות

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

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

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

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

מלאי

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

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

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

דוחות ושליפות

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

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

מה שכדאי לסגור לפני שמתחילים

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

מה אנחנו רואים בפרויקטים אמיתיים

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

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