סנכרון קטלוג דו-כיווני עם 1C: הגדרת חילופי נתונים

סנכרון קטלוג דו-כיווני עם 1C

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

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

הגדרת מקורות אמת

השלב הראשון הוא לתעד עבור כל שדה איזו מערכת היא האב:

כיצד נפתרים קונפליקטים במהלך סנכרון

קונפליקט: השדה active_site הוגדר ל-false על ידי מפעיל האתר (לא פורסם), אבל הייצוא הבא מ-1C מכיל active = true. לפי הטבלה למעלה, 1C הוא האב עבור active_1c, אבל active_site נשאר ללא שינוי. תוצאה: active_1c = true, active_site = false → המוצר לא מוצג. מפעיל האתר שומר על שליטה. עבור כל שדה, אנו מגדירים מערכת אב וכלל מיזוג. זה מבטיח שלמות נתונים ומונע אובדן מידע.

סכמת מסד נתונים

CREATE TABLE products (
    id BIGSERIAL PRIMARY KEY,
    onec_guid UUID UNIQUE, -- идентификатор 1С
    sku TEXT, -- Поля из 1С (перезаписываются при каждой синхронизации)
    name_1c TEXT,
    price_1c NUMERIC(12,2),
    stock_1c INTEGER,
    category_guid UUID,
    active_1c BOOLEAN DEFAULT true, -- Поля сайта (не перезаписываются синхронизацией)
    description TEXT,
    meta_title TEXT,
    meta_description TEXT,
    images JSONB,
    active_site BOOLEAN DEFAULT true, -- Мета синхронизации
    last_sync_1c TIMESTAMPTZ,
    sync_hash_1c CHAR(64) -- хеш данных из 1С для детекции изменений
);
-- Итоговый статус: товар активен только если активен и в 1С, и на сайте
CREATE VIEW products_active AS
SELECT * FROM products
WHERE active_1c = true AND active_site = true;

אלגוריתם סנכרון מ-1C לאתר

class OnecToSiteSyncService {
    public function sync(CommerceMLData $data): SyncResult {
        $result = new SyncResult();
        foreach ($data->products as $onecProduct) {
            $syncHash = $this->computeHash($onecProduct);
            $product = Product::firstOrNew(['onec_guid' => $onecProduct->guid]);
            // Пропускаем, если данные не изменились
            if ($product->exists && $product->sync_hash_1c === $syncHash) {
                $result->skipped++;
                continue;
            }
            // Обновляем ТОЛЬКО поля из 1С (не трогаем description, images и т.д.)
            $product->fill([
                'sku' => $onecProduct->sku,
                'name_1c' => $onecProduct->name,
                'price_1c' => $onecProduct->price,
                'stock_1c' => $onecProduct->stock,
                'category_guid'=> $onecProduct->categoryGuid,
                'active_1c' => $onecProduct->active,
                'last_sync_1c' => now(),
                'sync_hash_1c' => $syncHash,
            ]);
            $product->save();
            $result->updated++;
        }
        // Товары, которые 1С больше не выгружает — деактивируем
        $syncedGuids = $data->products->pluck('guid');
        Product::whereNotIn('onec_guid', $syncedGuids)
            ->update(['active_1c' => false]);
        return $result;
    }
}

סנכרון מהאתר ל-1C

האתר שולח ל-1C רק מה שהשתנה באתר וחשוב ל-1C: הזמנות חדשות, החזרות, הודעות תשלום.

class SiteToOnecSyncService {
    public function getUnsyncedOrders(): Collection
    {
        return Order::where('sent_to_1c', false)
            ->where('status', '!=', 'draft')
            ->with(['items.product', 'customer'])
            ->get();
    }
}

למה חשוב לבחור את פורמט ההחלפה הנכון

CommerceML הוא התקן התעשייתי לאינטגרציה עם 1C, אבל REST API נותן יותר שליטה. השוואה:

אנו בוחרים את הגישה למשימה הספציפית. לעסקים קטנים, CommerceML לרוב מספיק; לקטלוגים גדולים עם עומס גבוה, REST API עדיף.

ניטור סנכרון

-- Последние статусы синхронизации
SELECT source,
       COUNT(*) FILTER (WHERE status = 'success') AS success,
       COUNT(*) FILTER (WHERE status = 'error') AS errors,
       MAX(finished_at) AS last_run,
       AVG(EXTRACT(EPOCH FROM (finished_at - started_at))) AS avg_duration_sec
FROM sync_logs
WHERE started_at > NOW() - INTERVAL '7 days'
GROUP BY source;

באיזו תדירות צריך להתרחש סנכרון?

המרווח תלוי בעוצמת השינויים ובעומס. לחנות מקוונת עם 10,000 מוצרים, אופטימלי לעדכן מחירים ומלאי כל 15-30 דקות. לשוק גדול (100,000+ פריטים) — כל 5 דקות בשעות השיא ופחות בתדירות בלילה. אנו תמיד מגדירים לוח זמנים מתכוונן עם יכולת הפעלה ידנית.

טעויות טיפוסיות בהגדרת סנכרון

• חוסר גיבוב נתונים: כל ייצוא דורס את כל השדות גם אם הנתונים לא השתנו. פתרון: שמרו את ה-hash של הסנכרון האחרון והשוו.
• התעלמות מסטטוס פעילות: אם מוצר לא זמין באחת המערכות, הוא עדיין מופיע באתר. השתמשו בלוגיקת AND בין CREATE TABLE products ( id BIGSERIAL PRIMARY KEY, onec_guid UUID UNIQUE, -- идентификатор 1С sku TEXT, -- Поля из 1С (перезаписываются при каждой синхронизации) name_1c TEXT, price_1c NUMERIC(12,2), stock_1c INTEGER, category_guid UUID, active_1c BOOLEAN DEFAULT true, -- Поля сайта (не перезаписываются синхронизацией) description TEXT, meta_title TEXT, meta_description TEXT, images JSONB, active_site BOOLEAN DEFAULT true, -- Мета синхронизации last_sync_1c TIMESTAMPTZ, sync_hash_1c CHAR(64) -- хеш данных из 1С для детекции изменений ); -- Итоговый статус: товар активен только если активен и в 1С, и на сайте CREATE VIEW products_active AS SELECT * FROM products WHERE active_1c = true AND active_site = true; ל-class OnecToSiteSyncService { public function sync(CommerceMLData $data): SyncResult { $result = new SyncResult(); foreach ($data->products as $onecProduct) { $syncHash = $this->computeHash($onecProduct); $product = Product::firstOrNew(['onec_guid' => $onecProduct->guid]); // Пропускаем, если данные не изменились if ($product->exists && $product->sync_hash_1c === $syncHash) { $result->skipped++; continue; } // Обновляем ТОЛЬКО поля из 1С (не трогаем description, images и т.д.) $product->fill([ 'sku' => $onecProduct->sku, 'name_1c' => $onecProduct->name, 'price_1c' => $onecProduct->price, 'stock_1c' => $onecProduct->stock, 'category_guid'=> $onecProduct->categoryGuid, 'active_1c' => $onecProduct->active, 'last_sync_1c' => now(), 'sync_hash_1c' => $syncHash, ]); $product->save(); $result->updated++; } // Товары, которые 1С больше не выгружает — деактивируем $syncedGuids = $data->products->pluck('guid'); Product::whereNotIn('onec_guid', $syncedGuids) ->update(['active_1c' => false]); return $result; } } .
• סדר עיבוד שגוי: ייבוא מ-1C קודם, ואז ייצוא הזמנות — אחרת עלולות להתרחש התנגשויות. שמרו על רצף.

מה כלול בעבודה

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

לוח זמנים

סנכרון קטלוג דו-כיווני עם 1C, כולל בדיקות על תצורה אמיתית: 14–20 ימי עסקים. צרו קשר לביקורת של סכמת הסנכרון הנוכחית שלכם. קבלו ייעוץ על הגדרת החלפת נתונים — אנו נעריך את היקף העבודה ונציע את הפתרון האופטימלי.