סנכרון מכירות, מלאי ומחירים בין POS ל-ERP
מ-POS ל-ERP: מכירות, מלאי ומחירים מסונכרנים
מכירות והחזרות נרשמות מכל חנות, שינויי מלאי ומחירים נשלחים חזרה, וסכומי סוף היום מותאמים בהתחשבנות.
Blueprint
גללו הצידה כדי לראות את כל השרטוט.
מ-POS ל-ERP: כל מכירה נרשמת פעם אחת
מכירות זורמות מהקופות ל-ERP כאירועים, ומחירים ומלאי זורמים חזרה. חנות שמנותקת ממשיכה למכור ומשלימה פערים. רישום שנכשל מנוסה שוב, ואז מועבר לאדם.
- זרימה ראשית
- אסינכרונית
- מסלול חריגים
8 שלבים
הזרימה, שלב אחרי שלב
- ממסופי POS לשרת POS של החנות או בענן: מכירות, החזרות וביטולים (זרימה ראשית).
- משרת POS של החנות או בענן לשכבת אינטגרציה: אירועי מכירות וסיכומי סוף יום, דרך תור אירועים, דרך REST/JSON (אסינכרונית).
- משכבת אינטגרציה לERP: מכירות ותנועות מלאי נרשמו, דרך OData · REST/JSON (זרימה ראשית).
- מERP לשכבת אינטגרציה: מחירים, מבצעים ונתוני פריטים, דרך API או ייצוא קובץ, דרך REST/JSON (זרימה ראשית).
- משכבת אינטגרציה לשרת POS של החנות או בענן: עדכוני מחיר ומלאי, דרך REST/JSON (זרימה ראשית).
- משכבת אינטגרציה לתור ניסיונות חוזרים: הרישום נכשל (מסלול חריגים).
- מתור ניסיונות חוזרים לשכבת אינטגרציה: נוסה שוב (מסלול חריגים).
- מתור ניסיונות חוזרים לצוות תפעול החנויות: עדיין נכשל: התראה עם הפרטים (מסלול חריגים).
סקירה
זו הזרימה בין הקופות בחנויות שלכם לבין ה-ERP שמאחוריהן. מכירות, החזרות וביטולים עולים ל-ERP. מחירים, מבצעים, נתוני פריטים ומלאי יורדים חזרה. כשהשניים מתרחקים זה מזה, החנויות מוכרות במחיר שגוי, נתוני המלאי מפסיקים להיות מהימנים, והכספים מבלים את סוף החודש בהתאמות.
תכנית הייחוס שולחת כל עסקת חנות כאירוע דרך שכבת אינטגרציה עם תור. השכבה ממפה כל אירוע למסמכי המכירות והמלאי של ה-ERP ורושמת אותו בדיוק פעם אחת. בכיוון ההפוך, שינויים ב-ERP נשלחים לחנויות שזקוקות להם, כך שכל קופה עובדת מאותם נתונים.
חנויות מאבדות חיבור, והתכנון מצפה לכך. שרת החנות או ענן ה-POS ממשיך למכור ומשלים פערים כשהקו חוזר. רישום שנכשל עובר ניסיון חוזר, ורישום שממשיך להיכשל מועבר לאדם עם הפרטים, במקום להיעלם.
איך הזרימה עובדת
מוכרים בקופה
כל מכירה, החזרה וביטול נרשמים במסוף הקופה עם מזהה ייחודי, החנות, הקופה והשעה.
מחזיקים בחנות
שרת החנות או ענן ה-POS אוסף את העסקאות ושולח אותן כאירועים, ומחזיק אותן בבטחה בזמן שהחנות מנותקת.
רושמים ב-ERP
שכבת האינטגרציה ממפה כל אירוע לתנועות מכירה ומלאי ורושמת אותו ב-ERP, ומוודאת את המזהה שלו כדי ששום דבר לא יירשם פעמיים.
שולחים מחירים ופריטים
נתוני פריטים, מחירים ומבצעים מתפרסמים מה-ERP כשהם משתנים, עם התאריך והחנויות שכל שינוי חל עליהן.
מעדכנים כל חנות
השכבה מעבירה כל שינוי לחנויות שהוא חל עליהן, ורושמת אילו חנויות אישרו אותו.
כשמשהו נכשל
רישום נכשל
תקלות זמניות חוזרות בניסיון חוזר בהמתנות גדלות. רישום שעדיין נכשל עובר לתור הודעות כשל, וצוות תפעול החנויות מקבל התראה עם העסקה והשגיאה.
חנות עוברת למצב לא מקוון
החנות ממשיכה לסחור על הנתונים המקומיים שלה. העסקאות מוחזקות ונשלחות לפי הסדר כשהחיבור חוזר, וחנות ששותקת זמן רב מדי מפעילה התראה.
עסקה מגיעה פעמיים
כל עסקה נושאת מזהה ייחודי. השכבה מזהה חזרה ומתעלמת ממנה, כך ששליחה חוזרת לאחר הפסקה לעולם אינה מכפילה מכירה.
הסכומים בחנות וב-ERP שונים
סכומי סוף היום מכל חנות מושווים למה שה-ERP קיבל. פער פותח סקירה שבה מפורטות העסקאות החסרות או העודפות.
תקנים ומערכות
- נתונים ואנליטיקה
- Apache Kafka
- מערכות ERP
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- אינטגרציה
- REST
- Webhooks
- RabbitMQ
שאלות ותשובות
האם לרשום מכירות בזמן אמת או בקבוצות?
בדרך כלל כאירועים קרובים לזמן אמת, כי אז נתוני המלאי והמכירות מעודכנים במהלך היום. ב-ERP או ברישיונות מסוימים רישומים תכופים יקרים, ולכן השכבה יכולה גם לקבץ אירועים לסיכומים לפי חנות ותקופה. אנחנו בוחרים איתכם לפי אילו החלטות זקוקות לנתונים עדכניים ומה ה-ERP מטפל בו היטב.
איך מותאמים סכומי סוף היום?
כל חנות שולחת את סכומי סוף היום שלה לפי אמצעי תשלום ומחלקה. השכבה משווה אותם לעסקאות שה-ERP קיבל עבור אותה חנות ואותו יום. אם הם תואמים, היום נסגר. אם לא, הסקירה מפרטת את העסקאות החסרות או העודפות, כך שהצוות שלכם יכול לתקן את הסיבה במקום לרשום התאמה.
אפשר לתזמן מבצעים ושינויי מחיר מראש?
כן. כל שינוי מחיר או מבצע נשלח עם התאריך והחנויות שהוא חל עליהן, מראש, כך שהקופות מתחלפות ברגע הנכון בלי שאיש בחנות יפעל לכך. השכבה רושמת אילו חנויות אישרו את השינוי, ומסמנת את אלה שלא.
איך פורסים את זה על חנויות רבות?
מתחילים בפיילוט בכמה חנויות ומשווים את הסכומים שלהן לתהליך הנוכחי בכל יום. כשהסכומים תואמים, פורסים בקבוצות, בקצב שצוות תפעול החנויות שלכם יכול לתמוך בו. התהליך הישן נשאר זמין לכל חנות עד שהזרימה החדשה שלה מוכחת.
עם אילו מערכות POS ו-ERP זה עובד?
התכנון עובד עם כל POS שיכול לייצא עסקאות דרך API, אירועים או קבצים, ועם מערכות ERP כגון SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central ו-Odoo. אנחנו מאשרים את הממשקים של ה-POS וה-ERP הספציפיים שלכם בתחילת העבודה. אזכור מוצר אינו מעיד על שותפות עם הספק שלו.
מי מטפל ברישומים שנכשלו אחרי העלייה לאוויר?
זה מוסכם לפני העלייה לאוויר. בדרך כלל צוות תפעול החנויות או הכספים שלכם מטפל בשגיאות עסקיות, כמו פריט לא מוכר, מתוך רשימת סקירה, והצוות הטכני מטפל בתקלות בזרימה עצמה. אנחנו יכולים לספק את התמיכה הטכנית הזו במסגרת הסכם מתמשך, כשספר ההפעלה משותף עם הצוות שלכם.
מתחילים בשיחה, לא בחוזה.
ספרו לנו מה אתם צריכים לבנות, לחבר או לאבטח. ארכיטקט עובר על זה איתכם, ואז ממליץ מאיפה להתחיל.
מה קורה עכשיו
תיאום מועד
הצוות שלנו שולח לכם דוא״ל לתיאום מועד למפגש.
מפגש ייעוץ מקדים
מפגש ייעוץ מקדים מקוון ללא עלות של 30 דקות: אנחנו עוברים איתכם על המטרות, המערכות והמגבלות שלכם.
סקירת מוכנות
במסגרת סקירת מוכנות ללא עלות בת 48 שעות, מהנדס ראשי בודק את הפרויקט שלכם מול הגדרת המוכנות בת שש הנקודות וממליץ על המסלול המתאים.
בחירת המסלול
פרויקטים עם היקף מוכן מקבלים הצעה מחייבת בתוך 3–5 ימי עסקים. פרויקטים בשלב הרעיון מתחילים ב-Blueprint Studio. מערכת חיה שנכשלת, אינה מתועדת או זקוקה לאינטגרציה מתחילה באבחון של 1–2 שבועות. ל-Blueprint Studio ולאבחון יש שכר טרחה קבוע, הנקוב בהצעה.