מדוע החלפת צדדים ב‑1С Битрикс יוצרת כפילויות ואי-התאמות
החלפת צדדים בין 1С לאתר כמעט אף פעם אינה ייצוא דו-כיווני פשוט. המדריך במערכת החשבונאית ומסד הנתונים של האתר חיים לפי כללים שונים: ב‑1С רשומה משתנה בדיעבד, ואילו באתר היא כבר מקושרת להזמנות, לחשבוניות ולאזור האישי.
ברגע שכללי ההתאמה אינם מוגדרים במפורש, התיקון הראשון של פרטי זיהוי במערכת אחת יוצר כרטיס חדש במערכת השנייה.
הסיבה הנפוצה ביותר לכפילויות צדדים היא מפתח התאמה חסר. אם צומת ההחלפה מחפש רשומה לפי שם, אז «ООО Ромашка», «Ромашка ООО» ו‑«ООО "Ромашка"» הופכים לשלוש חברות שונות עם היסטוריות הזמנות שונות.
אמין יותר לקשר רשומות לפי INN יחד עם KPP, ולשמור את השם, הכתובת ופרטי הקשר כשדות הניתנים לכתיבה מחדש, ולא כמזהה.
מקור תקלות שני הוא הקונפליקט «מי הראשי». כל עוד לא הוגדר מקור אמת, ההחלפה מתבצעת בשני הכיוונים והפרטים מוחקים זה את זה: מנהל תיקן איש קשר ב‑1С-Битрикс, ואילו ייצוא נוסף מהמערכת החשבונאית החזיר את הערך הישן.
מכאן גם אי-ההתאמה במדריכים — חלק מהכרטיסים התעדכנו, חלק נשארו כשהיו, ואף אחד לא יכול לאשר איזו גרסה נכונה.
הזנה כפולה של נתונים מופיעה כתוצאה מכך. מנהלים מפסיקים לסמוך על ההחלפה האוטומטית ופותחים כרטיס צד ידנית בצד שבו הוא חסר — כך המסדים מתרחקים זה מזה מהר יותר ובלתי הפיך. להלן נפרט כיצד הדבר נסגר: מפתח התאמה, כללי עדיפות לשדות, טיפול באי-התאמות ויומן החלפה.
תוצאה של הגדרה: מדריכים נקיים ופחות עבודה ידנית
לאחר ההגדרה, ההחלפה מתבצעת בשני הכיוונים: צד שנוצר במערכת החשבונאית מופיע ב‑1С-Битрикс יחד עם הפרטים, אנשי הקשר והשיוך לעסקה, ותיקונים בכרטיס מהממשק מוחזרים בחזרה. רשומות מותאמות לפי מפתח — מספר מס או מזהה חיצוני, לכן לקוח אחד לא הופך לשלושה כפילים אחרי כל ייצוא.
מדריך אחיד מפחית פעולות ידניות שגוזלות בדרך כלל זמן ממנהלים ומרואי חשבון: השוואה בין שני מסדים, חיפוש אי-התאמות, הזנה חוזרת.
אנו מקבעים בעלים לכל שדה — חלק מהתכונות מתעדכנות רק מהמערכת החשבונאית, חלקן רק מממשק האתר — והסנכרון האוטומטי של צדדים מחלק אותן ללא קונפליקטים, לפי לוח זמנים או לפי אירוע. יומן ההחלפה שומר מה ומתי הועבר: אם רשומה לא עברה, רואים באיזה שלב.
עדכניות הנתונים על לקוחות מפסיקה להיות תלויה במי שנכנס לאחרונה למסד. בכרטיס העסקה אותם פרטים כמו במערכת החשבונאית — המנהל לא מברר אותם בטלפון ולא ממתין לייצוא ממחלקת החשבונאות, וזמני סגירת העסקאות הופכים לצפויים: ההשהיה של «עכשיו נשלח את הנתונים הנכונים» נעלמת מהתהליך.
אנו בודקים את התוצאה בתרחישים אמיתיים: יוצרים צד בכל צד, משנים פרטים, בודקים כיצד פועלים עדיפויות השדות וההחלפה החוזרת. ההגדרה נחשבת להסתיימה כאשר לאחר ריצת בקרה אי-ההתאמות במדריכים אפסיות ונשארות כך ללא התערבות ידנית.
מצבי החלפת צדדים: חד-פעמי, תקופתי, מבוסס אירועים
שלושה מצבים מכסים משימות שונות, והבחירה ביניהם נקבעת לפי מידת הקריטיות של פיגור המדריך אחרי המערכת החשבונאית. ייבוא חד-פעמי של צדדים — זוהי טעינה ראשונית: ריצה אחת בעת הקמת האתר או לאחר החלפת מערכת חשבונאית, לאחר מכן המדריך מתקיים באופן עצמאי.
החלפה תקופתית — משימה שלוקחת שינויים ומעדכנת כרטיסי שותפים במרווחים קבועים, מבלי ליצור עומס שיא על המסד.
ייצוא מבוסס אירועים בנוי אחרת: 1С מעבירה צד ברגע הרישום, לכן לקוח חדש מופיע באזור האישי כמעט מיד, ולא לאחר מרווח המשימה. המחיר לכך — גישה חיצונית למסד והגנה מפני העברה חוזרת אם התשובה לא הגיעה. לכן בפועל משלבים בין מצבי סנכרון המדריכים, ולא בוחרים באחד.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| ייבוא חד-פעמי | מילוי ראשוני של המדריך, מעבר לאחר החלפת מערכת חשבונאית | אינו רואה תיקונים לאחר ההרצה, יש ליזום חזרה ידנית |
| החלפה תקופתית | זרימת עסקאות קטנה, פיגור לתקופת המשימה מקובל | ההשהיה שווה למרווח ההרצה, במדריכים גדולים גדל משך המעבר |
| ייצוא מבוסס אירועים | אזורים אישיים והזמנות שבהם חשובה עדכניות מיידית | דורש גישה ברשת למסד וסינון כפילויות בעת שליחה חוזרת |
תרשים העבודה בדרך כלל כזה: ייבוא חד-פעמי ממלא את המדריך, ייצוא מבוסס אירועים מוסר צדדים חדשים, והחלפה תקופתית משלימה את כל מה שלא עבר באירוע. איזה סט מצבים נדרש במקרה שלכם — תלוי בזרימת המסמכים ובכך היכן בדיוק מותרת אי-התאמה.
סדר העבודות: מביקורת מדריכים ועד מסירת נהלים
החלפת צדדים נשברת לא בשלב ההגדרה, אלא בנתונים: כפילויות עם כתיב שונה, פרטים ריקים, כרטיסים שנוצרו ידנית בשתי מערכות בו-זמנית. לכן אנו מתחילים בבדיקת המדריכים, ולא בייצוא. סדר העבודות זהה להחלפה חד-כיוונית ודו-כיוונית — רק סט הכללים משתנה.
- ביקורת מדריכים. אנו מפיקים חתך מ‑1С ומהאתר: כמה רשומות, היכן כפילויות, אילו פרטים לא מולאו, כיצד מתייחסים תאגידים ויחידות נפרדות. בפלט — מפת אי-התאמות ורשימת נתונים שאסור להעביר אוטומטית.
- כללי התאמת פרטים. אנו מסכימים לפי איזה סימן מקשרים רשומות: מזהה מערכת המקור, מספר מס, צירוף שדות. מקבעים מערכת אב, סדר פתרון קונפליקטים ומה לעשות עם צד שקיים רק בצד אחד.
- הגדרת החלפה. אנו קובעים כיוון והרכב שדות: פרטים, כתובות, אנשי קשר, שיוך לקבוצות. מגדירים לוח זמנים, יומן החלפה והתראות על שגיאות — תקלה נראית מיד, ולא בבדיקה כעבור חודש.
- בדיקה בסביבת בדיקות. העתק של מסד העבודה, הרצה של החלפה מלאה וחלקית, תרחיש נפרד על נתונים «מלוכלכים» וכפילויות. מודדים את זמן המעבר והתנהגות בעת ניתוק קשר.
- קבלת האינטגרציה. רשימת תיוג: השוואת מספר רשומות, השוואה מדגמית של פרטים, הפעלה חוזרת ללא יצירת כפילויות, חזרה תקינה של ריצה כושלת.
- מסירת נוהל החלפה. תיאור כללי התאמה, אחראי על המדריך, הוראות להפעלה מחדש ולפתרון קונפליקטים, סדר ביצוע שינויים בתרשים.
לאחר המסירה ההחלפה מתבצעת לפי לוח זמנים: צדדים חדשים מופיעים בשתי המערכות, אי-ההתאמות מתרכזות ביומן, ושינויי תרשים עוברים דרך סביבת בדיקות, ולא ישירות במסד העבודה.
מה נשאר אצלכם: כללי התאמה, הגדרות, תיעוד
לאחר ההפעלה, החלפת צדדים חיה לא בהתכתבות ולא בראש של המהנדס, אלא בארטיפקטים שנמצאים אצלכם וזמינים לצוות ללא פנייה אלינו. להלן — רשימה של מה שמועבר בסיום העבודות ונשאר כלי עבודה לתמיכה.
- מפת קשרים: אילו אובייקטים מותאמים בין המערכת החשבונאית לאתר, כיוון ההחלפה עבור כל אחד וטריגרים להפעלה — אירוע, לוח זמנים, הפעלה ידנית.
- כללי התאמת פרטים: לפי אילו שדות מחפשים התאמה (INN/UNP, קוד צד, מזהה פנימי), כיצד מטפלים בכפילויות, בערכים ריקים ומשתנים, אילו שדות חובה ליצירת רשומה.
- הגדרות סינון ובחירה: אילו סוגים וקבוצות של צדדים נכללים בהחלפה, אילו נשארים רק במערכת החשבונאית, כיצד מוחרגות רשומות פנימיות ובדיקה.
- הפרדת גישה למדריכים: תפקידי עובדים בצד האתר, מי מתקן כרטיס צד, מי מפעיל החלפה ידנית והיכן מתועדות פעולות אלו.
- נוהל אי-התאמות והוראות לעובדים: מה לעשות אם צד לא נוצר, התעדכן רק במערכת אחת או ההחלפה נתקעה — לאן להסתכל ולמי להעביר את המשימה.
- יומן החלפה: היכן לראות סטטיסטיקת הפעלות, שגיאות וזמן עיבוד, כדי להבדיל בין תקלת אינטגרציה לשגיאת נתונים.
מקרה בוחן: כיצד הסרנו כפילויות בין המערכת החשבונאית לאתר
הלקוח — ספק סיטונאי: מדריך הצדדים נמצא ב‑1С, הקטלוג והאזור האישי — ב‑1С-Битрикс. לא היה החלפה בין המערכות: הנתונים הועברו בקובץ שהוכן ידנית, וההתאמה נעשתה לפי שם הארגון כמחרוזת.
כל שגיאת הקלדה או שינוי של השם המשפטי יצרו רשומה חדשה — באתר הצטברו כפילויות המקושרות למשתמשים והזמנות שונים.
מה שינינו
הגדרנו החלפה לפי לוח זמנים: ההתאמה מתבצעת לפי מספר מס ומפתח חיצוני, ולא לפי שם. המדריך באתר הפך לנגזר מהמערכת החשבונאית — צדדים חדשים מופיעים מעצמם, פרטים ואנשי קשר מתעדכנים תוך 15 דקות, ואי-התאמות מגיעות ליומן ההחלפה עם ציון מה בדיוק לא תאם.
לפני ההפעלה איחדנו היסטוריה: פירקנו כפילויות שהצטברו, הדבקנו הזמנות וחשבוניות מקושרות, וקבענו מפת התאמה של רשומות ישנות לחדשות.
מדדים לפני ואחרי
- שיעור הרשומות הכפולות: מ‑18% ל‑0.4% — היתרה דורשת החלטה ידנית עבור פרטים חסרים;
- הכנת ייצוא: 3–4 שעות בשבוע ידנית → 0, ההחלפה מתבצעת ברקע;
- תיקונים ידניים של צדדים: כ‑40 בשבוע → 2–3 בחודש, ורק למקרים שנויים במחלוקת;
- זמן הטמעת ההחלפה: 3 שבועות, מתוכם שבוע — להשוואת נתונים היסטוריים.
מה לעשות אם הנתונים כבר הוזנו בשתי מערכות באופן שונה?
כאשר שתי המערכות כבר מלאות, התאמה לפי שם נותנת זוגות שגויים: צד אחד נוצר כ«Ромашка», אחר — «ООО Ромашка, Минск», ולצדם «Ромашка ТД» — זה כבר תאגיד אחר.
לכן אנו מתחילים לא בהחלפה, אלא במפקד: מייצאים את שני המדריכים, מנרמלים שמות ומתאימים ישויות לפי סימנים מוחלטים — מספר מס, ואז לפי צירוף «שם + טלפון + כתובת».
| סוג אי-התאמה | כיצד מזהים | פתרון |
|---|---|---|
| כפילויות בתוך מסד אחד | קיבוץ לפי מספר ושם | מיזוג לכרטיס אחד |
| פרטים שונים בזוג | השוואה לפי שדות, יומן אי-התאמות | הערך נלקח לפי המערכת המובילה של השדה |
| רשומה קיימת רק בצד אחד | התאמה מלאה של מדריכים | הזוג נוצר, הקשר נרשם |
| כרטיסי בדיקה וריקים | סינון: אין פרטים ועסקאות | אינם נכללים בהחלפה |
המערכת המובילה נבחרת לא עבור הכרטיס כולו, אלא לפי כל שדה: פרטים, שם לפי מסמכים וחוזים — מהמערכת החשבונאית; אנשי קשר, סגמנט ומקור הפנייה — מהאתר. ערך שנוי במחלוקת אינו נמחק בשקט: אי-ההתאמה מגיעה ליומן, שבו רואים מה נכתב מחדש ועל איזה בסיס.
מקרים בודדים שבהם האוטומציה לא בטוחה, מטפל בהם מפעיל: רשומות נתפרות ידנית, והקשר נשמר כהתאמה יציבה, שאותה ההחלפה רק תשתמש בהמשך. לאחר מכן מתבצעת השוואה חד-פעמית — מעבר אחד לפי כללי המערכת המובילה, תוך שמירת היסטוריית שינויים, לכן כל שלב ניתן לחזרה מבלי לאבד נתונים בשני המסדים.
ספקות טכניים נפוצים לפני תחילת העבודות
לפני תחילת החלפת צדדים, השירותים הטכניים של הלקוח בודקים לא «האם האינטגרציה עובדת», אלא כיצד היא מתנהגת בתקלות ומה יהיה איתה בעוד שנה. להלן — תשובות קצרות למה שבדרך כלל עולה באישור.
האם ניתן לסנכרן לא את כל הצדדים, אלא רק חלק?
כן, כלל הבחירה מוגדר בצד המקור: קבוצה, סימן, פרט נוסף. רשומות מחוץ לכלל לא נכנסות לתור בכלל, לכן נפח ההעברה נשאר צפוי. הריצה הראשונה מוגבלת בנוסף לפי תאריך שינוי — היסטוריה של שנים קודמות לא מיוצאת.
מה יקרה אם אחת המערכות אינה זמינה?
שינויים לא הולכים לאיבוד: הם נשארים בתור וחוזרים לפי לוח זמנים, עד שהצד המקבל יאשר קבלה. החזרה אינה יוצרת כפילויות — רשומות מותאמות לפי מפתח חיצוני, ואי-התאמות נאספות לדוח לבדיקה.
כיצד ההחלפה משפיעה על העומס?
מועברות רק רשומות שהשתנו, במנות, ולא כל המדריך כולו. עומס השיא עובר לחלון הלילה, במהלך היום ההחלפה אינה מפריעה למנהלים לעבוד עם כרטיסים.
האם ניתן לחזור שינויים אם הכלל יתברר כשגוי?
כן: הכלל מושבת בלי לנתק את הקשר בין המערכות. לפני ריצה המונית אנו מצלמים את המדריך, כדי להחזיר ערכים קודמים של פרטים, והיומן מראה איזו רשומה ומתי השתנתה.
נדון במשימה: נחזור עם תוכנית עבודה והערכה
כדי להעריך החלפת צדדים בין 1С לאתר, אין צורך במפרט מלא — די בנתוני פתיחה שמהם ניכרים ההיקף והסיכונים. שלחו אותם בצורה חופשית, ואנו נחזור עם תוכנית עבודה, הרכב התאמות ולוחות זמנים לפי שלבים.
מה עוזר לחשב מהר יותר:
- איזו תצורת 1С פועלת אצלכם ועד כמה היא מותאמת: סטנדרטית או עם תיקונים שאסור לאבד בהחלפה.
- מה נחשב למקור אמת עבור הצד: 1С כותבת לאתר, האתר מחזיר נתונים בחזרה, או שההחלפה דו-כיוונית עם כללי עדיפות.
- היקפים: כמה צדדים יש כרגע, כמה מתווספים בחודש, באיזו תדירות משתנים פרטים וחוזים.
- כיצד מקשרים רשומות בין המסדים — לפי INN, UNP או קוד חיצוני — ומה לעשות עם כפילויות וכרטיסים ללא פרטים.
- הרכב ההחלפה: רק כרטיס הצד או גם חוזים, אנשי קשר, כתובות ושיוך לחשבוניות ולהזמנות.
- גישות: סביבת בדיקות של 1С, העתק מסד או המבנה שלו, גישה לניהול האתר וקשר של המומחה שלכם ל‑1С.
השיחה הראשונה — 30–40 דקות ענייניות: מנתחים את התרשים, נקודות כשל ומי אחראי לנתונים בכל קטע. בסיומה נשלח תוכנית עבודה לפי שלבים, הערכת לוחות זמנים וסיכונים, וכן סדר התחלה: תחילה החלפה בכיוון אחד על רשימה מוגבלת של צדדים, אחר כך הרכב מלא ונוהל החלפה. תארו את המשימה — נחזור עם הערכה ותוכנית.