הגדרת סנכרון בין 1C ל-Magento 2: קטלוג, מלאי, הזמנות

אינטגרציה של 1С ו-Magento 2: היכן ההחלפה נשברת

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

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

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

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

קטגוריה נפרדת של תקלות — אי-התאמה של מפתחות. יחידות מידה, שיעורי מס, מחסנים וקבלנים מתוארים באופן שונה ב-1С וב-Magento 2, וההחלפה מדלגת בשקט על מה שלא הצליחה להתאים. השגיאה לא צפה מיד: היא מצטברת בלוגים, עד שהפער נעשה מורגש בהכנסות.

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

מה נותן חיבור ההחלפה: השפעה לפי צמתים

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

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

מלאי: תור אירועים ותדירות החלפה

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

הזמנות: זרימה חוזרת ללא אובדן

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

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

שלבי הגדרת חילופי נתונים בין 1С ל-Magento 2

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

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

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

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

במה שונה סנכרון מלאי מסנכרון הזמנות?

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

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

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

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

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

מקרה בוחן: כיצד החלפת נתונים הפסיקה לאבד הזמנות ומחירים

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

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

מה שינו

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

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

מדדים לפני ואחרי

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

Magento 2 ו-1С נשארים מקושרים דרך שכבת ביניים שניתן להפעיל מחדש מבלי לעצור את חלון הראווה.

ספקות בנוגע לתאימות, הרשאות גישה ונסיגה

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

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

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

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

לאחר המסירה תקבלו לידיכם:

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

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

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

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

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

Magento 2 רגיש לאיכות ספרי העזר: אם ב-1С יש כפילויות או שדות חובה ריקים, הסנכרון ייתקע עליהם, ולא על הקוד. לכן הסקר הופרד לשלב נפרד — הוא מסיר את הסיכונים העיקריים בלוחות הזמנים.