הגדרת מודול חנות המקוונת של 1C-Bitrix
תארו לעצמכם: החנות הושקה, ההזמנות הראשונות מגיעות, אבל התשלומים לא מאושרים אוטומטית, הסטטוסים לא משתנים, וההזמנות לא מיוצאות ל-1C. התרחיש הטיפוסי—הגדרה שגויה של מודול sale. אנו מגדירים את 1C-Bitrix כבר למעלה מ-7 שנים, השלמנו למעלה מ-50 פרויקטים, ואנחנו מכירים כל מהמורה. לאחרונה, לקוח איבד 3 ימים בניסיון להבין מדוע הודעות לא הגיעו—התברר שה-callback עבור YooKassa לא הוגדר. הגישה שלנו מבטיחה פעולה תקינה של הקופה הרושמת, סנכרון עם 1C, ולוגיסטיקה שקופה.
מדוע רצף ההגדרה הוא קריטי
מודול sale הוא ליבת הלוגיקה המסחרית. יש להגדיר אותו בקפדנות לפי הסדר: מאפייני הזמנה → סטטוסים → מערכות תשלום → שירותי משלוח → מטבעות ומסים → הודעות. כל בלוק עוקב תלוי בקודמו. דילוג על שלב מוביל לשגיאות נסתרות. לדוגמה, אם מתחילים עם מערכות תשלום לפני מאפייני ההזמנה, ייתכן שהשדות הנדרשים (כמו אימייל) לא יועברו לשער התשלום. ויש ליצור סטטוסי הזמנה לפני הגדרת הודעות callback—אחרת המערכת לא תוכל לשנות את הסטטוס לאחר התשלום. שמירה על הרצף ממזערת עבודות חוזרות בעת ההשקה.
מאפייני הזמנה וסטטוסים
מאפייני הזמנה (sale.property) הם השדות שהקונה ממלא בעת ביצוע ההזמנה: שם, טלפון, אימייל, כתובת, הערה. קבוצת המאפיינים מוגדרת עבור כל סוג משלם (יחיד, חברה). עבור חברות, הוסיפו ח.פ., קוד מס, שם חברה, כתובת חוקית. אל תשכחו לסמן שדות חובה—אם טלפון או אימייל לא מולאו, הקונה לא יוכל להשלים את ההזמנה.
סטטוסי הזמנה מגדירים את מחזור החיים: "חדשה" → "שולמה" → "בטיפול" → "נשלחה" → "נמסרה" → "הושלמה". לכל סטטוס יש קוד אותיות והוא מקושר לאירועי דוא"ל—כשהסטטוס משתנה, הקונה מקבל הודעת דוא"ל. תכננו את הסטטוסים לפני ההשקה. הוספת סטטוס חדש לחנות פעילה שוברת דוחות וסנכרון 1C אם המיפוי מקודד בצורה נוקשה.
מערכות תשלום
מערכת תשלום ב-Bitrix היא handler המחובר לסוג משלם ולאתר. ההגדרה מתבצעת בשלושה שלבים:
- יצירה — עברו ל"חנות" → "מערכות תשלום" → "הוסף". בחרו handler: YooKassa, CloudPayments, העברה בנקאית, או מזומן.
- מיפוי שדות — ה-handler מבקש סכום, מספר הזמנה, אימייל. שדות אלה ממופים למאפייני ההזמנה.
- כתובת Callback — הכתובת לאישור תשלום משער התשלום. עבור YooKassa:
handler. זה מוגדר בחשבון שער התשלום.
עבור YooKassa, ספקו /bitrix/tools/sale_ps_result.php ומפתח סודי, בחרו מצב (בדיקה/חי), הגדירו אמצעי תשלום (כרטיס, SBP, ארנקים אלקטרוניים). ה-callback משנה אוטומטית את סטטוס התשלום. ה-handler של YooKassa מוגדר פי שניים מהר יותר משל CloudPayments בזכות ה-handler המובנה שלו.
| Handler | אישור אוטומטי | סוג משלם | שגיאה נפוצה |
|---|---|---|---|
| YooKassa | כן (callback) | יחיד | Callback לא מוגדר—ההזמנה לא עוברת ל"שולמה" |
| CloudPayments | כן (callback) | יחיד | פרמטר חובה shopId חסר |
| העברה בנקאית | לא (ידני/1C) | חברה | חשבונית נוצרת עם פרטים שגויים |
| מזומן | לא (ידני) | יחיד | אין קבלה במערכת |
שירותי משלוח
שלושה סוגי handlers למשלוח ב-Bitrix:
- עלות קבועה — איסוף עצמי (חינם), שליח (קבוע).
- חישוב אוטומטי — CDEK, Boxberry, דואר רוסי. המודול מ-Marketplace שולח שאילתה ל-API ומחזיר עלות וזמן משלוח. נדרשים מפתחות API, עיר מוצא, ומידות ברירת מחדל. לדוגמה, אינטגרציית CDEK מתמודדת עם עד 5000 הזמנות בחודש ללא בעיות.
- Handler מותאם אישית — מחלקת PHP עם לוגיקה מותאמת. כאשר התעריפים תלויים באזור, משקל, מידות לפי כללים לא סטנדרטיים.
| משלוח | שיטת חישוב | זמן הגדרה | מגבלות |
|---|---|---|---|
| איסוף עצמי | תלוי בהיקף | 15 דקות | כתובת אחת בלבד |
| שליח | תלוי בהיקף | 30 דקות | עיר בלבד |
| CDEK | API (אוטומטי) | 2-3 שעות | נדרש חוזה עם CDEK |
| Boxberry | API (אוטומטי) | 2-3 שעות | נדרש מפתח API |
מטבעות, מסים, הודעות
מטבעות — מודול InvoiceId. המטבע הבסיסי מאחסן מחירים, וההמרה מתבצעת אוטומטית בעת התצוגה.
מע"מ — שיעור (20%, 10%, 0%, ללא מע"מ) מקושר למוצרים. בעת ביצוע ההזמנה, המע"מ מחושב ומועבר לקבלה הפיסקלית—נדרש לפי 54-FZ. הגדרות מע"מ שגויות עלולות להוביל לקנסות משמעותיים.
הודעות דוא"ל — תבניות לאירועי דוא"ל (הזמנה חדשה, שינוי סטטוס, תשלום). ערכו תחת "הגדרות" → "אירועי דוא"ל". מאקרו כמו currency, #ORDER_ID#, #PRICE# מחליפים נתונים.
שגיאות בהגדרת #ORDER_USER# לא מופיעות מיד: callback חסר מוביל להזמנות שלא שולמו, מע"מ חסר בקבלה מעורר חקירות מס, סטטוסים שגויים שוברים סנכרון 1C. כדי להימנע מכך, הפקידו את ההגדרה בידי אנשי מקצוע. אנו מבטיחים שכל המודולים פועלים כראוי.
כיצד להימנע מטעויות אופייניות?
שלוש שגיאות עיקריות בהגדרת מודול החנות המקוונת:
- לא הוגדר callback עבור שער התשלום — תשלומים לא מאושרים.
- סטטוסי הזמנה לא ממופים לקודי CommerceML — סנכרון 1C נשבר.
- מידות מוצר לא מוגדרות לחישוב משלוח אוטומטי — עלות לא מחושבת.
כל הבעיות הללו מתגלות במהלך בדיקות אם עוקבים אחרי רשימת בדיקה. אנו מכינים רשימת בדיקה כזו עבור כל פרויקט.
הגדרת מודול מלאה במפתח אחד
אנו מספקים:
- הגדרה של כל בלוקי
sale(מאפיינים, סטטוסים, מערכות תשלום, משלוח, מסים, הודעות). - אינטגרציה עם 1C (CommerceML) — מיפוי ספריות, סטטוסים, מחסנים.
- חיבור קופה רושמת מקוונת (54-FZ) עם בדיקת פיסקליזציה.
- הדרכה לצוות שלך בניהול הזמנות ודוחות.
- תיעוד הגדרות ומדריך מנהל.
- תמיכה לאחר השקה למשך 30 יום.
צרו קשר לייעוץ אישי והערכת פרויקט. הזמינו הגדרת מודול חנות מקוונת והשיקו מכירות ללא בעיות נסתרות.
להבנה מעמיקה יותר של הארכיטקטורה, אנו ממליצים לעיין בתיעוד הרשמי (מדריך המפתחים של 1C-Bitrix) ובערך בוויקיפדיה על הפלטפורמה.