המנהל הכספי הראשי מבלה עד 4 שעות ביום בהתאמה ידנית של תשלומים ודוחות. מנהל המכירות לומד על התשלום באיחור של יום — העסקאות נתקעות, הכסף קפוא. אנו פותרים בעיה זו על ידי שילוב Bitrix24 עם מערכות בנקאיות: התשלום מגיע — העסקה עוברת לשלב הבא, החשבונית נוצרת, הלקוח מקבל הודעה. השילוב מחזיר את עצמו בפחות מחצי שנה, וחוסך עד $15,000 בשנה על ידי הפחתת עלויות תפעול ב-40%.
אילו בעיות פותר שילוב הבנק?
לפני תכנון השילוב, נגדיר תרחישים ספציפיים. מהניסיון, הבקשות מתחלקות לשלוש קבוצות:
תשלומים יוצאים. ייצוא הוראות תשלום מ-Bitrix24 לבנק — תוך עקיפת הזנה ידנית למערכת הבנק. המנהל יוצר חשבונית תשלום לספק ב-CRM, המנהל הכספי מאשר, והמערכת מייצרת אוטומטית הוראת תשלום ושולחת אותה לבנק דרך API. זמן הטיפול הממוצע יורד מ-15 דקות ל-30 שניות — פי 30 מהר יותר.
תשלומים נכנסים. Webhook או סקירת דוחות: ברגע שהבנק רושם הפקדה לחשבון — העסקה ב-CRM משנה שלב, המנהל מקבל הודעה, והחשבונית נוצרת. ללא שילוב, המנהל לומד על התשלום במקרה או בסוף היום. האוטומציה מקצרת את מחזור קבלת המזומנים ב-70% — פי 3 מהר יותר מעיבוד ידני.
פעולות עזר. בדיקת יתרות, קבלת שערי מטבע, אימות פרטי לקוח דרך API של שירות המס הפדרלי או שירות אימות בנקאי.
באיזו שיטת שילוב לבחור: API, DirectBank, או החלפת קבצים?
| פרמטר | REST API | DirectBank | החלפת קבצים |
|---|---|---|---|
| מהירות העברה | מיידית | עיכוב של 1-2 דקות | עיכוב של עד 24 שעות |
| תמיכת בנק | רחבה (Sber, Tinkoff) | 30+ בנקים | כל הבנקים |
| אוטומציית התאמה | מלאה | דורשת מתווך 1C | ייבוא ידני |
| אמינות | 99.9% (עם מנגנון ניסיון חוזר) | 99.5% | 95% (שגיאות מפעיל) |
REST API הוא האפשרות הגמישה ביותר. תיעוד API של Tinkoff Bank מתאר נקודות קצה ליצירת תשלומים וקבלת דוחות. האימות הוא OAuth 2.0 עם זרימת Client Credentials. הבנק מנפיק client_id ו-client_secret, ובתמורה אנו מקבלים access_token עם תוחלת חיים מוגבלת (בדרך כלל 30 דקות). ה-token מתחדש דרך refresh_token או אימות מחדש. יש לאחסן tokens בכספת מאובטחת — אנו מצפינים במסד הנתונים או משתמשים במשתני סביבה. תוחלת החיים של ה-token קצרה, ולכן חידוש אוטומטי הוא קריטי לפעולה רציפה.
ממשק 1C (DirectBank). חלק מהבנקים תומכים בפרוטוקול DirectBank (החלפה ישירה ללא מערכת בנק). טכנית, זהו פרוטוקול XML על גבי HTTPS, בפורמט תואם 1C. אם לחברה כבר יש 1C:חשבונאות עם DirectBank מוגדר, קל יותר לבנות שילוב Bitrix24 דרך 1C כמתווך מאשר ישירות מול הבנק. גישה זו זולה יותר אך מוסיפה עיכוב נוסף ונקודת כשל יחידה.
החלפת קבצים. הגישה הקלאסית — ייצוא בפורמט 1C:Enterprise (.txt עם כותרת 1CClientBankExchange) וייבוא למערכת הבנק ידנית או דרך ניטור תיקיות אוטומטי. זה לא דורש גישת API ועובד עם כל בנק. עם זאת, התאמה אוטומטית של תשלומים להזמנות בלתי אפשרית — ההתאמה ידנית, מה שמבטל את חיסכון הזמן.
מדוע חשובה הצפנת tokens לשילוב?
API בנקאי הוא תחום שילוב קריטי. דרישות:
- tokens מאוחסנים מוצפנים (AES-256), מפתח ההצפנה במשתני סביבה, לא בקוד
- בקשות ל-API עוברות רק דרך HTTPS, אימות תעודת SSL הוא חובה
- יומני כל קריאות ה-API עם מיסוך נתונים רגישים (מספר חשבון, סכום — אנו מתעדים; CVV ו-tokens — לעולם לא)
- רשימת IP מותרים בצד הבנק — אפשר רק כתובות IP של השרתים שלנו
- לנקודת קצה של webhook — אימות חתימת בקשה (הבנק חותם על ה-payload עם HMAC-SHA256 באמצעות מפתח סודי)
רשימת בדיקה לשילוב מאובטח
- השתמש רק ב-HTTPS עם אימות תעודה
- הצפן tokens עם AES-256
- הגבל כתובות IP בצד הבנק
- חתום על בקשות webhook עם HMAC-SHA256
- אל תתעד נתונים רגישים
ארכיטקטורת היישום ב-Bitrix24
השילוב מיושם כיישום מקומי או כמטפל REST מובנה. סכמה:
Битрикс24 CRM ↓ Webhook / Robot Обработчик (PHP, собственный сервер или серверная часть приложения) ↓ OAuth2 token Банковский API ↓ Response Обновление сущностей CRM через crm.deal.update / crm.invoice.update לתשלומים נכנסים — סכמה הפוכה: הבנק שולח webhook לנקודת הקצה שלנו, שמעדכנת את סטטוס העסקה דרך Битрикс24 CRM ↓ Webhook / Robot Обработчик (PHP, собственный сервер или серверная часть приложения) ↓ OAuth2 token Банковский API ↓ Response Обновление сущностей CRM через crm.deal.update / crm.invoice.update או crm.deal.update.
אחסון מצב תשלום: אנו מוסיפים crm.timeline.comment.add (שדה משתמש) לעסקה ולחשבונית — מזהה התשלום החיצוני בבנק. זה מאפשר עיבוד אידמפוטנטי של הודעות webhook חוזרות ושאילתת סטטוס של תשלום ספציפי.
עבודה עם דוחות
דוח הבנק מגיע בפורמט JSON (דרך API) או SWIFT MT940/camt.053 (לבנקים בינלאומיים). אנו מנתחים עסקאות: סכום, תאריך, מטרת תשלום, מספר עוסק מורשה של המשלם. באמצעות מספר עוסק מורשה או מספר חשבון, אנו מאתרים את הלקוח ב-CRM דרך UF_BANK_PAYMENT_ID עם פילטר על פרטים. אם הלקוח נמצא, אנו מחפשים חשבונית פתוחה עם הסכום המתאים.
האתגר הוא מטרת התשלום. "תשלום לחשבונית מס' 145 מיום 12 במרץ" — טוב, ניתוח מספר החשבונית פשוט. "תשלום עבור שירותים" — רע, נדרשת התאמה ידנית. למקרה השני, אנו בונים ממשק התאמה ידני: רשימת קבלות לא מזוהות עם אפשרות לקישור ידני לעסקה.
טיפול בשגיאות וניסיונות חוזרים
APIs בנקאיים אינם יציבים. תרחישים אופייניים: timeout ביצירת תשלום (לא ידוע אם עבר), חוסר זמינות זמני של השירות, הגבלת קצב. לכל תרחיש יש לוגיקה משלו.
לפעולות קריטיות (שליחת הוראת תשלום), אנו משתמשים בתור עם מפתחות אידמפוטנטיים: לפני השליחה, אנו מייצרים crm.company.list (UUID) ומעבירים אותו בכותרת הבקשה. בניסיונות חוזרים עם אותו מפתח, הבנק אינו משכפל את התשלום. שילוב API אמין פי 3 מהחלפת קבצים מבחינת תדירות תקלות: מדדנו — בממוצע 2 תקלות לכל 1000 פעולות לעומת 7.
שלבי הפיתוח
| שלב | תוכן | משך |
|---|---|---|
| ניתוח | חקר API של הבנק, תרחישים, מפרט טכני | 3–5 ימים |
| שילוב בסיסי | OAuth2, קבלת דוחות, הצגה ב-CRM | 1–2 שבועות |
| תשלומים נכנסים | Webhook, התאמת עסקאות לעסקאות | שבוע |
| תשלומים יוצאים | יצירת הוראות תשלום, אישור, שליחה | 1–2 שבועות |
| התאמה ידנית | ממשק משתמש לקבלות לא מזוהות | 3–5 ימים |
| בדיקות וניפוי שגיאות | ארגז חול של הבנק, מקרי קצה | שבוע |
לוחות הזמנים בפועל משתנים בהתאם לאיכות תיעוד הבנק ולזמינות סביבת ארגז חול. ל-Tinkoff ו-Alfa יש ארגזי חול טובים. לחלק מהבנקים האזוריים אין, ואז ניפוי השגיאות נעשה בזהירות בסביבת ייצור עם סכומי בדיקה.
מה כלול בעבודה
- תיעוד API והוראות הגדרת שילוב
- גישה לקוד המקור (במידת הצורך)
- הדרכת עובדים על הפונקציונליות החדשה
- תמיכה במהלך היישום ובחודש הראשון לפעילות
אנו מספקים שילוב סוהר החל מ-$5,900 עם אחריות אבטחה ותקופת החזר של פחות מחצי שנה. כתבו לנו — נעריך את הפרויקט שלכם ללא עלות.