הגדרת הרשמת מוכרים עבור 1C-Bitrix Marketplace

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

אנחנו פותרים את הבעיה הזו: אנו מגדירים רישום מוכרים ב-1C-Bitrix כך שתהליך איסוף נתוני הישות המשפטית, האימות וההטמעה (Onboarding) מתנהל בצורה חלקה. הטמעה מוגדרת כהלכה מקצרת את זמן השקת המוכר בפלטפורמה ב-30% ומעלה את שיעור ההמרה של הרישום ב-25%. קבלו ייעוץ—נעריך את הפרויקט שלכם תוך יום אחד.

כיצד פועל רישום מוכרים ב-Bitrix

המוכר במערכת הוא b_user בקבוצה מיוחדת (לדוגמה, 'מוכרים', b_user_group). אנו מאחסנים נתוני ישות משפטית נוספים בשדות UF של המשתמש (b_user_field) או ב-HL-block נפרד המקושר דרך UF_USER_ID. גישה זו מאפשרת הרחבה גמישה של הפרופיל ללא שינויי ליבה. כל השדות ממוקדים (indexed)—בדיקת ע"מ מתבצעת תוך אלפיות שניות.

שדות מפתח בטופס רישום המוכר:

• סוג ישות (בע"מ/עוסק מורשה/יחיד)
• שם מלא של הארגון
• ע"מ, ח.פ. (לישויות משפטיות), מספר רישום/מספר עוסק מורשה
• כתובת משפטית
• איש קשר, טלפון, דוא"ל
• פרטי בנק
• קישור למסמכים (תקנון, אישור רישום)—העלאה דרך CFile

מודל סטטוסים: רשום → ממתין למסמכים → בבדיקה → פעיל | נדחה. הסטטוס נשמר בשדה UF של המשתמש. בכל מעבר, נשלח דוא"ל אוטומטי דרך CEvent::Send() לפי תבנית אירוע של Bitrix—מנגנון סטנדרטי המתואר בתיעוד Bitrix. ללוגיקה מורכבת יותר, אנו משתמשים בסוכנים (agents) ואירועים—לדוגמה, מעבר אוטומטי ל-under_review לאחר העלאת מסמכים.

למה להפוך את תהליך ההטמעה לאוטומטי?

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

השוואת גישות:

כיצד ליישם אימות צד שכנגד דרך DADATA או FNS

אימות צד שכנגד הוא שלב מפתח. טעות נפוצה היא היעדר בדיקת ע"מ. אם מוכר מזין ע"מ שגוי, בדיקת המסמכים מתעכבת, ו-30% מהבקשות נושרות. אנו מיישמים אימות דרך FNS API תוך 2 שניות. לשם כך, אנו יוצרים handler PHP חיצוני הנקרא מסוכן או אירוע. התוצאה נשמרת בשדה UF UF_CONTRAGENT_STATUS. אם הסטטוס הוא 'לא נמצא', המוכר רואה שגיאה ויכול לתקן את הנתונים.

דוגמת יישום דרך DADATA:

// Вызов API DADATA для проверки ИНН
$url = 'https://suggestions.dadata.ru/suggestions/api/4_1/rs/findById/party';
$data = ['query' => $inn];
$options = [
    'http' => [
        'header' => "Content-Type: application/json\r\nAuthorization: Token $api_key\r\n",
        'method' => 'POST',
        'content' => json_encode($data)
    ]
];
$context = stream_context_create($options);
$result = file_get_contents($url, false, $context);

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

מה אם אימות הצד שכנגד נכשל?

אם ה-API מחזיר שגיאה או שהנתונים לא נמצאו, המוכר מקבל הודעה לבדוק את הע"מ. המנהל יכול לאשר את הנתונים ידנית דרך ממשק הניהול. למקרים מורכבים (לדוגמה, אי-התאמה בכתובת), אנו מוסיפים אפשרות להעלאת אישור סרוק. כל הפעולות מתועדות ב-// Вызов API DADATA для проверки ИНН $url = 'https://suggestions.dadata.ru/suggestions/api/4_1/rs/findById/party'; $data = ['query' => $inn]; $options = [ 'http' => [ 'header' => "Content-Type: application/json\r\nAuthorization: Token $api_key\r\n", 'method' => 'POST', 'content' => json_encode($data) ] ]; $context = stream_context_create($options); $result = file_get_contents($url, false, $context); לצורך ביקורת.

איך אנחנו עושים את זה (הוכחת מומחיות)

בפרויקט אחד עם למעלה מ-200 מוכרים בחודש, אוטמטנו את בדיקת המסמכים דרך FNS API. הבדיקה הידנית ירדה מ-8 שעות בשבוע ל-30 דקות (הפחתה של פי 16), וזמן הרישום קוצר מיומיים ל-10 דקות בממוצע. אנו משתמשים בסקריפט PHP מותאם אישית הנקרא דרך סוכן כל 5 דקות לבדיקת מעברי סטטוס. התוצאה: הפעלת מוכרים מהירה ב-30% ועלייה של 25% בהשלמת הרישום.

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

• הכנת מפרט טכני עם מודל סטטוסים ודיאגרמות אינטגרציה
• פיתוח טופס רישום מותאם אישית עם שדות מורחבים
• הגדרת מודל סטטוסים ודוא"ל מונעי אירועים
• אינטגרציה עם שירותי אימות צד שכנגד (DADATA, FNS API)
• יצירת ממשק ניהול לניהול בקשות
• הטמעה: שיבוץ אוטומטי לקבוצה, יצירת אזור אישי, דוא"ל קבלת פנים
• תיעוד (תיאורי סכמות, הוראות למנהלים)
• הדרכת עובדים לשימוש במערכת
• תמיכה לאחר ההשקה (שבועיים בחינם)

שלבי מודל הסטטוסים וזמני עיבוד

לוחות זמנים משוערים

הגדרה בסיסית (טופס + מודל סטטוסים + התראות) אורכת 1 עד 2 שבועות. אם נדרשת אינטגרציה עם DADATA או FNS API, זה אורך 3 עד 4 שבועות. לוחות הזמנים מותאמים לאחר ניתוח הדרישות שלכם. הזמינו ייעוץ—נבחר את הפתרון האופטימלי.

טעויות נפוצות בהגדרה:

• קישור שגוי של ה-HL-block למשתמש (שכחת b_event_log)
• חוסר אינדקסים בשדות ע"מ/מספר רישום—מאט את האימות
• מודלי סטטוסים ארוכים מדי (יותר מ-5 סטטוסים מבלבלים את המנהלים)
• התעלמות מתבניות אירועים—דוא"ל לא נשלח

הניסיון שלנו עוזר להימנע מבעיות אלו—השקנו למעלה מ-50 שווקים (Marketplaces) על Bitrix, עם ניסיון של 10+ שנים בתחום, ואנו מציעים אחריות ל-6 חודשים. קבלו ייעוץ—נעריך את הפרויקט שלכם תוך יום אחד. אנו מספקים פתרון סוהר (turnkey) תוך 3–4 שבועות בלבד. כתבו לנו כדי להתחיל.