אינטגרציה עם 1C:Enterprise: החלפת מוצרים, הזמנות ומלאי
יום שני בבוקר. המנהל פותח את האתר ורואה שהפריט שנמכר ביום שישי עדיין מופיע כ"במלאי". שלושה לקוחות כבר שילמו על מוצר שלא קיים. אנחנו נתקלים בכאב הזה באופן קבוע: חוסר הסנכרון בין 1C לחנות המקוונת פוגע בהכנסות ובמוניטין. אנחנו פותרים את הבעיה מקצה לקצה — הגדרת החלפה כך שמערכת החשבונאות והחנות יתעדכנו באופן סינכרוני, ללא אובדן נתונים, ועם הבטחות עקביות.
1C היא מערכת החשבונאות של רוב החברות הרוסיות. האתר הוא חזית החנות. הם חייבים לדבר באותה שפה ולעשות זאת באופן קבוע, אמין, וללא אובדן נתונים. הניסיון שלנו: למעלה מ-50 אינטגרציות מוצלחות עבור לקוחות עם קטלוגים מ-500 עד 200,000 פריטים.
למה CommerceML הסטנדרטי לא תמיד מספיק?
CommerceML הוא פרוטוקול החלפה סטנדרטי הנתמך על ידי 1C:Trade Management, 1C:Integrated Automation, ותצורות נוספות. WooCommerce, Shopify, ומערכות CMS אחרות כוללות תוספים ל-CommerceML (למשל, "1C-Bitrix" למוצריהם, תוספים נפרדים ל-WordPress). הזרימה: 1C יוזם החלפה → שולח ארכיון ZIP עם XML לנקודת הקצה של האתר → האתר מנתח ומעדכן את הקטלוג.
פורמט CommerceML הוא XML עם סכמה משלו: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. קטגוריות, מוצרים, מאפיינים, תמונות, מחירים, מלאי. הקושי העיקרי: היררכיית המאפיינים ב-1C ותכונות המוצר באתר לא תמיד תואמות אחד לאחד. נדרש מיפוי. להבנה מעמיקה של הפרוטוקול, אנו ממליצים על תיעוד בוויקיפדיה — ויקיפדיה: CommerceML.
כיצד אנו מתגברים על מגבלות CommerceML
עבור תצורות 1C לא סטנדרטיות או כאשר CommerceML אינו מתאים — אנו כותבים שירות HTTP ב-1C (מובנה מאז גרסה 8.3) ומתקשרים באמצעות REST JSON. זה נותן שליטה מלאה על מבנה הנתונים ותדירות הסנכרון, אך דורש פיתוח על ידי מתכנת 1C.
למשימות ארגוניות עם מספר מערכות חשבונאות — Message Broker (RabbitMQ, Apache Kafka) כמתווך. 1C מפרסם אירועים לתור, האתר נרשם ומעבד אותם. אספקה מובטחת, חציצה כאשר צד אחד אינו זמין.
מה אנו מסנכרנים וכיצד
קטלוג (מוצרים, קטגוריות, מאפיינים). החלק הגדול ביותר. ייצוא מלא בריצה הראשונה, עדכוני דלתא לאחר מכן. בעת ייבוא CommerceML: ניתוח XML באמצעות PHP SimpleXML או XMLReader (עבור קבצים גדולים — רק XMLReader, אחרת מגבלת זיכרון). התאמת מוצרים לפי GUID מ-1C, אותו אנו מאחסנים בשדה נפרד במסד הנתונים. אם מוצר נמחק ב-1C, אנו מסתירים אותו באתר, לא מוחקים (היסטוריית הזמנות עשויה להפנות אליו).
מלאי ומחירים. זהו ПакетПредложений נפרד ב-CommerceML, מתעדכן בתדירות גבוהה יותר מהקטלוג. קריטי לעשות זאת אטומית: לא לעדכן מלאי אחד אחד, אלא בטרנזקציה. אחרת, במהלך העדכון, המשתמש עלול לראות מצב לא עקבי. תדירות: פעם בשעה למצב רגוע, פעם בכל 5–15 דקות למסחר פעיל.
הזמנות. החלפה דו-כיוונית. אתר → 1C: הזמנה חדשה נשלחת עם פריטים, כמויות, מחירים, פרטי קשר של הלקוח. 1C → אתר: סטטוס הזמנה (שולם, נארז, נשלח, נמסר). להעברת הזמנות — או אותו CommerceML (בלוק Документы) או קריאת REST ישירה כאשר נוצרת הזמנה באתר.
אילו בעיות טיפוסיות אנו פותרים?
מוצרים כפולים. מפעיל 1C יצר פריט עם שגיאת כתיב ב-SKU, ואז תיקן אותה. באתר — שני פריטים. פתרון: התאמה לפי GUID מ-1C (לא לפי SKU), GUID הוא בלתי משתנה.
קירילית ב-XML וקידודים. 1C עובדת היסטורית עם Windows-1251. קובץ CommerceML עשוי להגיע ב-CP1251, PHP מצפה ל-UTF-8. mb_convert_encoding() או iconv() בשורות הראשונות של המנתח — חובה.
פסקי זמן בייצוא גדול. קטלוג של 100,000 פריטים הוא 50–200MB XML. זמן הביצוע המוגדר כברירת מחדל של PHP של 30 שניות אינו מספיק. פתרון: פקודת CLI (Laravel Artisan או Symfony Console) המופעלת דרך cron, ללא פסק זמן HTTP. או עיבוד במנות באמצעות XMLReader עם התחייבויות חלקיות למסד הנתונים.
תמונות. 1C יכול לשלוח תמונות כ-Base64 בתוך XML (מנפח את הקובץ פי 1.3) או כקישורי קבצים. האפשרות השנייה עדיפה. הורדה אסינכרונית, המרה ל-WebP, הצבה בספריית המדיה.
מקרה: חנות מקוונת לחלקי רכב, 85,000 פריטים. סנכרון דרך CommerceML כל 30 דקות. בעיה: ייצוא מלא ארך 18 דקות, וכתוצאה מכך ייצוא חדש התחיל בזמן שהישן עדיין פעל. פתרון: נעילה באמצעות Redis (SET nx ex), ייצוא דלתא (רק פריטים ששונו בשעתיים האחרונות באמצעות פילטר ב-1C), עיבוד דרך תור עם 20 עובדים מקבילים. זמן סנכרון: 18 דקות → 2.5 דקות, ללא התנגשויות.
השוואת שיטות אינטגרציה
| שיטה | מהירות סנכרון | גמישות תצורה | עוצמת משאבים |
|---|---|---|---|
| CommerceML | גבוהה (XML בינארי) | נמוכה (סכמה קבועה) | נמוכה (כמעט לא משפיע על השרת) |
| REST API ישירות | בינונית (JSON) | גבוהה (כל מודל) | בינונית (דורש שני שרתי HTTP) |
| Message Broker (RabbitMQ/Kafka) | גבוהה מאוד (אסינכרוני) | בינונית (ארכיטקטורה מונעת אירועים) | גבוהה (דורש אשכול Broker) |
CommerceML בתרחישים טיפוסיים מהיר פי 2-3 מ-REST לסנכרון קטלוג בשל אריזה בינארית של XML ופורמט קומפקטי. עם זאת, אם נדרשת לוגיקת החלפה מותאמת אישית, REST מספק גמישות מלאה.
תהליך ולוח זמנים
ביקורת תצורת 1C (גרסה, סוג תצורה, יכולות ייצוא) → עיצוב מיפוי נתונים → פיתוח מקלט באתר ושולח ב-1C → בדיקה על נתונים אמיתיים → הגדרת לוח זמנים → ניטור החלפות ראשונות.
השתתפות מתכנת 1C בצד הלקוח היא חובה, או שאנו מגייסים מומחה מהימן.
| תרחיש | לוח זמנים | | CommerceML, קטלוג + מלאי, WooCommerce | 2–4 שבועות | | החלפת הזמנות דו-כיוונית | +2–3 שבועות | | תצורת 1C מותאמת אישית, REST API | 4–8 שבועות | | ארגוני: מספר מסדי נתונים של 1C, אוטובוס נתונים | 2–4 חודשים |
מה כלול בתוצאה (תוצרים)
- תיעוד: סכמת מיפוי, פורמטי נתונים, לוגיקת טיפול בשגיאות.
- לוח זמנים מוגדר לסנכרון עם לוגי ביצוע.
- גישה לניטור (Grafana/ELK — בתיאום).
- הדרכה למנהלים: כיצד להפעיל החלפה ידנית, כיצד לקרוא לוגים.
- תמיכה לאחר השקה — 2 שבועות (תיקון תקלות).
קבלו ייעוץ
נעריך את הפרויקט שלכם תוך יום עסקים אחד — שלחו לנו דוא"ל או השתמשו בצ'אט. עלות האינטגרציה מחושבת באופן אישי לפי מורכבות הפרויקט. עם ניסיון של למעלה מ-7 שנים באינטגרציות 1C, אנו מבטיחים סנכרון יציב ללא הפתעות.