שילוב ביטריקס עם קופות רושמות אופליין: פיסקאליזציה וסנכרון
לקוח מבצע הזמנה בחנות המקוונת של ביטריקס, בוחר "מזומן במשלוח." השליח מספק את המוצר, מנפיק קבלה בקופה רושמת ניידת של ATOL או Evotor. הקבלה הפיסקלית מונפקת, אך ההזמנה במערכת נשארת ב"ממתין לתשלום." המחסן לא מוחק פריטים, הנהלת החשבונות לא רואה את התשלום — בעיה מוכרת? אנחנו נתקלים בה באופן קבוע ויודעים איך לפתור אותה. כשלי סנכרון מובילים לכפילויות במלאי, קנסות מרשות המסים ואובדן לקוחות. בשנה האחרונה תיקנו יותר מ-50 מקרים כאלה. שילוב חנות מקוונת עם קופה רושמת אופליין הוא לא רק פיסקאליזציה לפי 54-FZ אלא גם סנכרון מלא של סטטוסי הזמנות ורמות מלאי. מאמר זה מכסה את היישום הטכני של חיבור ביטריקס עם קופה רושמת אופליין באמצעות REST API.
תוכנית פיסקאליזציה לתשלומים
לפי 54-FZ, כל עסקה דורשת קבלה. בביטריקס, מודול salescenter ורכיב bitrix:salescenter.cashbox משתלבים עם קופות מקוונות דרך OFD. עבור קופות אופליין, התוכנית שונה: מכשיר פיזי (ATOL, Evotor, Shtrikh-M) מנפיק את הקבלה, וביטריקס חייבת לקבל אישור.
שני כיווני נתונים:
- ביטריקס ← קופה רושמת: נתוני הזמנה (פריטים, סכומים, מע"מ) להפקת קבלה
- קופה רושמת ← ביטריקס: אישור עם מספר קבלה וסימן פיסקלי
אינטגרציה דרך API של תוכנת הקופה
לרוב הקופות המודרניות יש REST API או webhook. Evotor — Cloud API, ATOL — פרוטוקול משלה. בביטריקס, handler לשינוי סטטוס הזמנה שולח את הנתונים:
AddEventHandler('sale', 'OnSaleStatusOrderChange', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $status = $order->getField('STATUS_ID'); if ($status !== 'DE') { return; } $items = []; foreach ($order->getBasket() as $item) { $items[] = [ 'name' => $item->getField('NAME'), 'quantity' => $item->getQuantity(), 'price' => $item->getPrice(), 'vat' => getVatTag($item->getField('VAT_RATE')), ]; } $evotorApi->sendReceipt($order->getId(), $items, $order->getPrice()); }); קבלת אישור מהקופה הרושמת
הקופה שולחת webhook עם קבלה מוצלחת. נקודת קצה בביטריקס:
$data = json_decode(file_get_contents('php://input'), true); if ($data['event'] === 'receipt.created') { $orderId = $data['external_id']; $fiscalSign = $data['fiscal_document_number']; $order = \Bitrix\Sale\Order::load($orderId); if ($order) { $payment = $order->getPaymentCollection()->current(); $payment->setField('PAID', 'Y'); $payment->setField('EXTERNAL_PAYMENT', $fiscalSign); $order->setField('STATUS_ID', 'F'); $order->save(); } } איך לסנכרן רמות מלאי עם מכירות אופליין?
מכירה בחנות פיזית של מוצר שקיים בהזמנה מקוונת חייבת להפחית מלאי. שתי גישות:
| גישה | תיאור | עיכוב |
|---|---|---|
| דרך 1C | 1C אוספת את כל המכירות ומסנכרנת מלאי לביטריקס בלוח זמנים | 15 דקות עד שעה |
| אינטגרציה ישירה של קופה עם ביטריקס | הקופה קוראת ל-API של ביטריקס בכל מכירה כדי למחוק מלאי | בזמן אמת |
אינטגרציה ישירה מהירה פי 3 ומבטלת את הסיכון למכירה כפולה. אנחנו מיישמים את שתי האפשרויות אבל ממליצים על השנייה. חיסכון טיפוסי בזמן של רואה חשבון — שעתיים ביום בזכות אוטומציה.
למה מיפוי מע"מ קריטי?
שגיאה בשיעור המע"מ בשליחה לקופה היא הפרה של 54-FZ. שיעורים בביטריקס מאוחסנים ב-AddEventHandler('sale', 'OnSaleStatusOrderChange', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); $status = $order->getField('STATUS_ID'); if ($status !== 'DE') { return; } $items = []; foreach ($order->getBasket() as $item) { $items[] = [ 'name' => $item->getField('NAME'), 'quantity' => $item->getQuantity(), 'price' => $item->getPrice(), 'vat' => getVatTag($item->getField('VAT_RATE')), ]; } $evotorApi->sendReceipt($order->getId(), $items, $order->getPrice()); }); . מיפוי לקבלה פיסקלית:
-
$data = json_decode(file_get_contents('php://input'), true); if ($data['event'] === 'receipt.created') { $orderId = $data['external_id']; $fiscalSign = $data['fiscal_document_number']; $order = \Bitrix\Sale\Order::load($orderId); if ($order) { $payment = $order->getPaymentCollection()->current(); $payment->setField('PAID', 'Y'); $payment->setField('EXTERNAL_PAYMENT', $fiscalSign); $order->setField('STATUS_ID', 'F'); $order->save(); } }→ תג 1105 (מע"מ 20%) -
b_catalog_vat→ תג 1104 (מע"מ 10%) -
VAT_RATE = 20→ תג 1106 (מע"מ 0%) -
VAT_RATE = 10→ תג 1107 (מע"מ לא ישים)
אנחנו מטפלים בכל הניואנסים — כולל מע"מ 20/120 — כדי להבטיח שנתונים פיסקליים תואמים לחקיקה. זה מפחית שגיאות פיסקאליזציה ב-95%.
תהליך הגדרה: שלב אחר שלב
- ניתוח — לימוד הגדרות הקופה וביטריקס הנוכחיות, זיהוי אי-תאימות.
- עיצוב — בחירת פרוטוקול (REST או webhook), הגדרת מיפוי שדות.
- יישום — כתיבת event handlers, נקודת קצה ולוגיקת סנכרון.
- בדיקות — בדיקה על קופה לבדיקה עד 100 קבלות, תיקון באגים.
- פריסה — העלאה לסביבת ייצור, הגדרת ניטור.
רשימת בדיקה לאינטגרציה בטוחה
- מיפוי מע"מ אומת עבור כל המוצרים
- בקשת retry הוגדרה בשגיאת שליחה
- תור לקבלות שלא נשלחו יושם
- ביטול קבלה נבדק בהחזרות
- אחראי מקבל הודעה במקרה של כשל
השוואת פרוטוקולי קופות
| פרוטוקול | קופה לדוגמה | מהירות | מורכבות |
|---|---|---|---|
| REST API | Evotor, ATOL | גבוהה | בינונית |
| Webhook | Shtrikh-M, Viki | בינונית | נמוכה |
בחירת הפרוטוקול תלויה בקופה ובתרחיש. אנחנו נבחר את האופטימלי.
מה כלול בהתקנה
אנחנו מכינים:
-
VAT_RATE = 0handler לשליחת נתונים למערכת הקופה - נקודת קצה של webhook לקבלת אישור פיסקאליזציה
- מיפוי שיעורי מע"מ בין ביטריקס לקופה
- עדכון סטטוס תשלום ושדה סימן פיסקלי
- מנגנון סנכרון מלאי
- תיעוד לוגים של כל העסקאות לאבחון
בנוסף:
- בדיקת אינטגרציה על קופה לבדיקה
- תיעוד API ותהליכי עבודה
- תמיכה לאחר השקה
לוח זמנים להתקנה — 2 עד 5 ימים תלוי במורכבות הקופה ובתרחיש. עלות מחושבת באופן אישי. צרו קשר לייעוץ — נבדוק את הפרויקט שלכם תוך יום. הזמינו התקנה מסודרת.
יותר מ-20 אינטגרציות עם קופות אופליין בביטריקס — הניסיון שלנו מבטיח פעולה יציבה.







