פריוריטי היא מערכת ה-ERP הנפוצה ביותר בעסקים ישראליים עם מלאי, ורוב חנויות השופיפיי שאנחנו פוגשים עם פריוריטי מאחוריהן כבר ניסו לחבר את השתיים בדרך כלשהי: אפליקציה, סקריפט של מישהו, או ייצוא-ייבוא ידני בסוף היום. הבעיות שמגיעות אלינו אחר כך חוזרות על עצמן. הנה שבע הנפוצות, ומה עושים במקום.
1. מסנכרנים יתרה במקום זמינות
ב-Priority יש הבדל בין מה שנמצא פיזית במחסן לבין מה שאפשר להבטיח ללקוח. היתרה (PARTBALANCE) כוללת סחורה שכבר שוריינה להזמנות פתוחות. חנות שמושכת את היתרה תמכור מוצר שהובטח ללקוח עסקי אתמול, והצוות יגלה את זה כשיגיע לליקוט.
במקום: מגדירים באפיון מה נחשב זמין: יתרה פחות הזמנות פתוחות, ולפעמים פחות שריונים ומינימום ביטחון. זה חישוב פשוט, אבל הוא חייב להיות החלטה מודעת ולא ברירת מחדל של כלי.
2. סופרים את כל המחסנים
לרוב העסקים יש בפריוריטי גם מחסן פגומים, מחסן תצוגה או מחסן תיקונים. אם החנות סוכמת את כל המחסנים, היא מוכרת סחורה שאף אחד לא מתכוון לשלוח.
במקום: בוחרים אילו מחסנים משתתפים במלאי האונליין. אם יש כמה מחסנים לגיטימיים, ממפים אותם ל-Locations בשופיפיי, כך שגם הליקוט יודע מאיפה יוצאת ההזמנה.
3. מק״ט שונה בכל מערכת
PARTNAME בפריוריטי הוא המפתח. אם בשופיפיי ה-SKU הוקלד ידנית, עם רווח, אות קטנה או סיומת של צבע, כל הזמנה הופכת לניחוש והמלאי מתעדכן על הפריט הלא נכון.
במקום: לפני החיבור עוברים על הקטלוג ומיישרים: מק״ט אחד לכל וריאציה, זהה בשתי המערכות. אם הקטלוג בפריוריטי בנוי מפריט-אב עם מידות וצבעים, מגדירים פעם אחת את חוק ההמרה לוריאציות ולא מתקנים ידנית.
4. מחירון עם מע״מ כפול, או בלי
פריוריטי מנהלת מחירונים לפני מע״מ או כולל מע״מ לפי הגדרה. שופיפיי מציגה מחיר לצרכן. חיבור שלא מכריע איפה מוסיפים את המע״מ מייצר מחיר של 117% או של 85% מהמחיר הנכון, ובדרך כלל מגלים את זה אחרי שכבר נמכרו כמה עשרות פריטים.
במקום: מחליטים מה מחירון החנות, איך מחושב המע״מ, ומה עושים עם עיגולים. ללקוחות עסקיים עם מחירון משלהם, ממפים את המחירון של הלקוח ל-Catalogs של Shopify Plus או למחיר לפי קבוצת לקוחות.
5. סנכרון פעם בשעה
מלאי שמתעדכן כל שעה מספיק כדי שמוצר אחרון יימכר פעמיים בשישים דקות עמוסות. הבעיה מחריפה במבצעים, בדיוק כשהמלאי נמוך.
במקום: הזמנות עוברות מיד דרך Webhooks של שופיפיי, ולא במשיכה מתוזמנת. מלאי ומחירים נמשכים מפריוריטי במרווח קצר, ופריטים שהמלאי שלהם נמוך מקבלים עדיפות. הכלל: ככל שהפריט קרוב יותר לאפס, הוא צריך להתעדכן מהר יותר.
6. ביטולים והחזרות שלא חוזרים
ההזמנה נרשמה בפריוריטי כהזמנת מכר. אחר כך הלקוח ביטל, או החזיר. אם האינטגרציה מטפלת רק בכיוון אחד, ההזמנה נשארת פתוחה בפריוריטי, המלאי לא חוזר, ובסוף החודש מגלים פערים בספירה.
במקום: ביטול בשופיפיי מבטל את ההזמנה בפריוריטי, החזרה מייצרת תעודת החזרה או זיכוי, והמלאי חוזר למחסן הנכון. כל אחד מהתרחישים האלה מוגדר באפיון עם התנהגות ברורה.
7. בלי לוגים והתראות
הטעות שהופכת את כל השאר לגרועות יותר. הזמנה שלא נקלטה בגלל שדה חסר, מחירון שנכשל בגלל תו לא חוקי, או משתמש API שהסיסמה שלו פגה – כל אלה קורים. השאלה היא אם מישהו יודע על זה תוך דקות או כשהלקוח מתקשר.
במקום: כל ריצה נרשמת בלוג, כל כשל מנסה שוב אוטומטית, וכשהבעיה נמשכת נשלחת התראה עם פרטי ההזמנה והסיבה. יש תור, ואפשר לשחזר כל הזמנה.
איך אנחנו בונים את זה
עובדים מול ה-REST API הרשמי של Priority, גם ב-Priority Cloud וגם בהתקנה מקומית, בלי תוכנה שמותקנת אצלכם. האפיון קובע את חוקי הזמינות, המחסנים, המק״טים והמחירונים. הבנייה רצה על שירות ייעודי עם ניטור, ובודקים במקביל על חברת בדיקות לפני שמחברים לחנות החיה.
הפירוט המלא, כולל מה מסתנכרן ולאיזה כיוון: אינטגרציה של Priority לשופיפיי. ולסקירה של כל המערכות ומתי כדאי אפליקציה מהמדף: המדריך המלא לחיבור ERP לשופיפיי.
שאלות נפוצות
באיזו תדירות צריך לסנכרן? הזמנות מיד, דרך Webhooks. מלאי ומחירים במרווח של דקות בודדות, עם עדיפות לפריטים שהמלאי שלהם נמוך.
מה ההבדל בין יתרה לזמינות? היתרה היא מה שבמחסן. הזמינות היא היתרה פחות הזמנות פתוחות והתחייבויות. חנות מציגה זמינות.
אפשר לסנכרן רק חלק מהמחסנים? כן, וכדאי. המחסן המרכזי משתתף, פגומים ותצוגה מוחרגים.
מה קורה בביטול אחרי שההזמנה נרשמה בפריוריטי? האינטגרציה מבטלת או מזכה בפריוריטי ומחזירה את המלאי. אם זה לא קורה, המלאי בחנות נשאר נמוך מהאמת.