המנהל הכספי הראשי מבלה עד 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 דקות). הטוקן מתחדש דרך refresh_token או אימות מחדש. יש לאחסן טוקנים בכספת מאובטחת — אנו מצפינים במסד הנתונים או משתמשים במשתני סביבה. תוחלת החיים של הטוקן קצרה, ולכן חידוש אוטומטי הוא קריטי לפעולה רציפה.
ממשק 1C (DirectBank). חלק מהבנקים תומכים בפרוטוקול DirectBank (החלפה ישירה ללא בנק-לקוח). טכנית, זהו פרוטוקול XML על גבי HTTPS, בפורמט מסמך תואם 1C. אם לחברה כבר יש 1C:Accounting עם DirectBank מוגדר, קל יותר לבנות שילוב Bitrix24 דרך 1C כמתווך ולא ישירות מול הבנק. גישה זו זולה יותר אך מוסיפה עיכוב נוסף ונקודת כשל יחידה.
החלפת קבצים. הגישה הקלאסית — ייצוא בפורמט 1C:Enterprise (.txt עם כותרת 1CClientBankExchange) וייבוא לבנק-לקוח ידנית או דרך ניטור תיקיות אוטומטי. זה לא דורש גישת API ועובד עם כל בנק. עם זאת, התאמה אוטומטית של תשלומים להזמנות בלתי אפשרית — ההתאמה ידנית, מה שמבטל את חיסכון הזמן.
מדוע חשובה הצפנת טוקנים לשילוב?
API בנקאי הוא היקף שילוב קריטי. דרישות:
- טוקנים מאוחסנים מוצפנים (AES-256), מפתח ההצפנה במשתני סביבה, לא בקוד
- בקשות ל-API עוברות רק דרך HTTPS, אימות תעודת SSL הוא חובה
- יומני כל קריאות ה-API עם מיסוך נתונים רגישים (מספר חשבון, סכום — אנו מתעדים; CVV וטוקנים — לעולם לא)
- רשימת IP מותרים בצד הבנק — אפשר רק כתובות IP של השרתים שלנו
- לנקודת קצה של webhook — אימות חתימת בקשה (הבנק חותם על ה-payload עם HMAC-SHA256 באמצעות מפתח סודי)
רשימת בדיקה לשילוב מאובטח
- השתמש רק ב-HTTPS עם אימות תעודה
- הצפן טוקנים עם AES-256
- הגבל כתובות IP בצד הבנק
- חתום על בקשות webhook עם HMAC-SHA256
- אל תתעד נתונים רגישים
ארכיטקטורת יישום ב-Bitrix24
השילוב מיושם כיישום מקומי או כמטפל REST מובנה. סכמה:
Bitrix24 CRM ↓ Webhook / Robot Обработчик (PHP, собственный сервер или серверная часть приложения) ↓ OAuth2 token Банковский API ↓ Response Обновление сущностей CRM через crm.deal.update / crm.invoice.update לתשלומים נכנסים — סכמה הפוכה: הבנק שולח webhook לנקודת הקצה שלנו, שמעדכנת את סטטוס העסקה דרך Bitrix24 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 עם אחריות אבטחה ותקופת החזר של פחות מחצי שנה. כתבו לנו — נעריך את הפרויקט שלכם ללא עלות.