אינטגרציה של OrangeData עם Bitrix: היכן נקרע הקבלה
אינטגרציה של OrangeData בחנות מקוונת על Bitrix נשברת לרוב לא בשלב החיבור, אלא במפגש שבין לוגיקת העסק של התשלום לבין הפיסקליזציה. החנות חיה את חייה שלה: סל קניות, הנחות, תשלומים חלקיים, החזרים, ואילו הקופה דורשת סכום אחד מדויק וסימן חישוב אחד לקבלה.
ברגע שנוצר פער בין העולמות הללו, ההזמנה עוברת לסטטוס "שולם", והקבלה או שאינה נרשמת, או שנרשמת בסכום שגוי.
הכשל הטיפוסי הראשון — פער בסכומים. Bitrix מחשבת את הסכום הכולל תוך התחשבות בהנחות, במשלוח ובעיגול, ואילו אל OrangeData נשלחת פריטיות שנאספה ממקור אחר. אם סכום הקבלה אינו תואם לתשלום שהתקבל בפועל ולו באגורה אחת, הפיסקליזציה אינה עוברת, והתשלום כבר חויב.
השני — סטטוסים תקועים של קבלות: הבקשה נשלחה, התשובה לא פוענחה, וההזמנה נותרת באי-ודאות, בעוד הלקוח ממתין למסמך סוגר.
כאב נפרד — תשלום חוזר והחזרים. בניסיון תשלום חוזר נוצרת קבלה שנייה לאותה הזמנה, ובקופה מופיע כפילות. בעת החזר יש להפיק קבלה עם סימן החזר הכנסה וסכום נכון, אחרת הפער מול הזיכרון הפיסקלי מצטבר וצף כבר בבדיקת ההתאמות. נבחן כיצד זה נסגר ברמת החלפת הסטטוסים ועיבוד תשובות הקופה.
מה נותנת פיסקליזציה תקינה של החנות
פיסקליזציה תקינה היא לא "כפתור להנפקת קבלה", אלא ההבדל בין חנות שבה הנהלת החשבונות מאמתת את ההכנסות בפועל, לבין חנות שבה כל תקלה בקופה מטופלת ידנית.
האינטגרציה של OrangeData עם 1С-Битрикс בנויה על מודל אירועי: ביצוע הזמנה, תשלום, החזר ותיקון יוזמים קבלה, וסטטוס הפיסקליזציה מוחזר להזמנה וליומן ההחלפה.
מה משתנה במספרים
- שיעור הקבלות המוצלחות ללא התערבות ידנית. בהגדרה תקינה של התור וניסיונות חוזרים, הקבלה נשלחת בניסיון הראשון-שני, ולא אחרי שהמנהל הבחין בהזמנה "תקועה". נשארים מקרים בודדים — אותם מטפלים נקודתית.
- זמן התגובה לתקלה. שגיאת פיסקליזציה נראית ביומן ברגע התרחשותה, ולא כעבור יום בעת האימות. זה מקצר את החלון שבו ההזמנה נחשבת למשולמת אך לא הונפקה.
- סוג הכשלים שנעלמים. נעלמות הקבלות ה"אבודות" בעת ניתוק התקשורת עם ОФД, הכפילויות בשליחה חוזרת, אי-ההתאמות בהחזרים — אותם תרחישים שבהם הקבלה או לא הונפקה, או הונפקה פעמיים.
- התערבות ידנית. החזרים, החזרים חלקיים ותיקונים מפסיקים להיות פעולה נפרדת של "להתקשר ולבקש מהנהלת החשבונות" — הם עוברים באותו זרם שבו עוברות המכירות.
OrangeData כאן היא פיסקליזציה בענן: הקופה אינה מחוברת לעמדת עבודה מסוימת, והקבלות נוצרות לפי נתוני ההזמנה. עבור חנות על 1С-Битрикс זה מסיר את התלות בחיבור פיזי של הקופה ומפשט את העבודה עם מספר נקודות.
התוצאה — פיסקליזציה צפויה: קבלות נשלחות אוטומטית, תקלות נראות מיד, והנהלת החשבונות מקבלת אימות ללא הרכבה ידנית. בהמשך נבחן כיצד זה מוגדר עבור חנות מסוימת.
דרכי חיבור: ענן, קופה, שירות מתווך
דרך החיבור קובעת היכן פיזית נוצרת הקבלה וכיצד נתוני המכירה מגיעים אל OrangeData. מכך תלויים מהירות ההפעלה, דרישות החומרה בנקודה, ואילו תרחישי החזרות ותיקונים בכלל זמינים. להלן שלוש סכמות עבודה, שביניהן באמת בוחרים בעת אינטגרציה עם 1С-Битрикс.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| קופה בענן | חנות אינטרנטית ללא נקודה פיזית, משלוח, איסוף עצמי; נדרש התחלה מהירה ללא רכישת ציוד | הקבלה תלויה בקישוריות לשירות: בעת אי-זמינות נדרשת תור של קבלות מושהות ושליחה חוזרת |
| קופה פיזית | נקודת קמעונאות שבה כבר מותקן מכשיר פיסקלי; המכירות מתבצעות גם אופליין וגם דרך האתר | דורשת דרייבר וסוכן מקומי בצומת הקופה, קשה יותר לעדכן באופן מרוכז את כלל הנקודות |
| שירות מתווך | מספר קופות, נקודות או ישויות משפטיות; נדרשת לוגיקה אחידה של קבלות, החזרות והתאמות | מתווספת חוליה נוספת שיש לנטר ולתחזק בתצורה עמידה בכשלים |
כיצד לבחור בהתאם למשימה
קופה בענן מכסה את רוב החנויות האינטרנטיות: הקבלה נשלחת לשירות מיד לאחר ביצוע ההזמנה, וההגדרה מצטמצמת לפרטי הארגון ולמערכת המיסוי.
הדבר המרכזי שיש להביא בחשבון — טיפול בקבלות מושהות: אם השירות אינו זמין, ההזמנה לא צריכה "להיתקע" ללא פיסקליזציה, וההחזרה בגינה מחויבת לעבור באופן תקין.
קופה פיזית מוצדקת כאשר המכירות מתבצעות גם אופליין והמכשיר כבר פועל. כאן חשוב לסנכרן את הפריטים ושיעורי המע"מ בין הקטלוג של Битрикс לתוכנת הקופה, אחרת אי-ההתאמות יצופו דווקא בהחזרות.
שירות מתווך נלקח כאשר יש כמה נקודות או ישויות משפטיות ונדרשת נקודת בקרה אחידה: הוא אוסף אירועים מהאתר ומהקופות, מכניס אותם לתור ומעביר אל OrangeData עם ניסיונות חוזרים. זה מסיר עומס מ-Битрикс ומספק פאנל אחד להתאמת קבלות, אך מוסיף חוליה שיש להחזיק תחת ניטור.
בפועל את הסכמה בוחרים לא לפי "אופנתיות", אלא לפי מספר הנקודות, קיום מכירות אופליין ודרישות לעמידה בכשלים. אנו מנתחים את הנתונים הללו ובוחרים אפשרות שבה החזרות ותיקונים עוברים ללא תיקונים ידניים.
סדר היישום: מביקורת ועד מסירה
את היישום מתחילים בביקורת מכירות: בודקים אילו תרחישים כבר עובדים ב-1С-Битрикс — הזמנות קמעונאיות, תשלום מראש, משלוחים חלקיים, אספקה — והיכן בדיוק צריך להיווצר הקבלה הפיסקלית.
בשלב זה מזהים את הנקודות שבהן התקשורת עם שירות הקופה עלולה להישבר: שינוי סטטוס הזמנה, ביטול פריט, שינוי סכום לאחר ביצוע ההזמנה. בלי ביקורת כזו כל הגדרה הופכת לניחושים.
לאחר מכן משרטטים תרשים זרימה: איזה אובייקט ב-Битрикс יוזם את הקבלה, איזה נתונים נשלחים לשירות הקופה, מה חוזר חזרה ואיך התוצאה נשמרת בהזמנה. תרשים מוסכם חוסך שבועות — הוא מראה היכן נדרש פיקוח ידני והיכן התהליך מתנהל אוטומטית.
- ביקורת מכירות והפיסקליזציה הנוכחית — מנתחים תרחישים, שיעורי מע"מ, מערכות מיסוי, מוצאים אי-התאמות בין ההזמנה לקבלה.
- תרשים זרימת נתונים — מתארים את השרשרת "הזמנה → קבלה → סטטוס → החזר", מתאמים עם הנהלת החשבונות ובעל התהליך.
- הגדרת התקשורת — מחברים את שירות הקופה, מגדירים העברת פריטים, הנחות, אמצעי תשלום וסימן נושא החישוב.
- בדיקת החזרים — עוברים בנפרד על החזר מלא וחלקי, החזר לפי קבלה ובלעדיה, מוודאים שהסכומים והפריטים תואמים.
- פעולות בדיקה — מריצים תרחישים אמיתיים על קונטור בדיקה: תשלום, ביטול, שליחה חוזרת, ניתוק תקשורת ושחזור.
- מסירה והדרכה — מוסרים תיעוד, מראים לעובדים כיצד לקרוא סטטוסים של קבלות ומה לעשות בעת שגיאה.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בדוח על עבודות. פעולות בדיקה מבצעים על עותק של נתוני ייצור — כך תופסים תרחישים נדירים שאינם נראים בהזמנות סינתטיות. לאחר המסירה נשארת אצל הלקוח תכנית עבודה ברורה ותקנון פעולות מובן בעת תקלה.
מה נשאר אצל הלקוח לאחר סיום העבודה
אינטגרציה של OrangeData היא לא "הגדרנו ושכחנו". פרטי ההתחברות, לוגיקת הפיסקליזציה של הקבלות וטיפול בהחזרים חיים בקונפיגורציית ההחלפה, ובלי תיעוד כל שינוי בקופה, במוצר או בשיעור המס הופך להשבתה. לכן כל פרויקט אנחנו סוגרים בחבילת ארטיפקטים שנשארת אצלכם ואינה תלויה בנו.
- קונפיגורציות החלפה — פרופילי חיבור פעילים ל-OrangeData: פרטי נקודת המכירה, תוכניות מיסוי, שיעורים, סימני פריט החישוב ואופן התשלום, קישור למחסנים ולקופות.
- תרשימי זרימת נתונים — כיצד הזמנה מהאתר או מ-1С הופכת לקבלה: היכן נוצרת הסל, באיזה רגע נשלחת הבקשה לפיסקליזציה, כיצד מעובדת התגובה ומה קורה במקרה של סירוב.
- נהלי החזרים — סדר החזר מלא וחלקי, ביטול קבלת תיקון, עבודה עם תשלום מראש ותשלום לאחר מעשה, התנהגות המערכת בעת ניתוק הקשר עם ОФД.
- הוראות להנהלת חשבונות — כיצד לבדוק קבלה שהופקה, למצוא אי-התאמה, לבצע החזר ידני ואילו נתונים נדרשים להתאמה מול ОФД.
- הוראות לתמיכה — אבחון תקלות אופייניות: הקבלה לא נשלחה, הוכפלה, נתקעה בסטטוס המתנה; היכן לצפות בלוגים של ההחלפה וכיצד להפעיל מחדש את התור באופן בטוח.
- מפת אינטגרציה — נקודות המגע עם 1С, האתר וניהול המלאי: אילו אירועים מפעילים פיסקליזציה ואילו חולפים על פניהם.
- יומן שינויים — מה ומתי תוקן בקונפיגורציה, לשם איזו מטרה וכיצד לבצע שחזור.
בנפרד אנחנו מתעדים את גבולות האחריות: מה האינטגרציה מכסה ומה נשאר בצד של תוכנת הקופה ו-ОФД. זה מסיר את רוב המצבים השנויים במחלוקת בעת התאמות.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: כיצד סולקו קבלות תקועות בחנות
חנות על 1С-Битрикс עם אינטגרציה של OrangeData התלוננה על קבלות "תקועות": הלקוח ביצע תשלום, אך המסמך הפיסקלי לא נסגר. הבעיה צצה בשעות עומס — בעת 40-60 הזמנות בו-זמנית התור לרישום קבלות עלה על גדותיו, וחלק מהבקשות נפלו עקב timeout.
המפעיל נודע על כך מהנהלת החשבונות כעבור יום, שלח ידנית קבלות מחדש והצליב סכומים — הטיפול גזל 3-4 שעות בשבוע, וחלק מהמכירות נותרו כלל ללא עקבות פיסקליות.
מה היה לפני
שיעור הקבלות שעברו ללא התערבות ידנית עמד על 82-85%. השאר — סירובים עקב timeout, כפילויות בשליחה חוזרת וקבלות "תקועות" בסטטוס ביניים. זמן התגובה לאירוע — מכמה שעות ועד יממה: נודע בדיעבד, כאשר הפער צף בדוח.
מה שינו
פירקו את הזרימה לשלבים והוסיפו אידמפוטנטיות: כל קבלה קיבלה מזהה ייחודי, ושליחה חוזרת בעת תקלה לא יצרה כפילות. התור הועבר לתהליך נפרד עם retries והשהיה אקספוננציאלית — כאשר השער אינו זמין, הבקשה לא אבדה אלא חזרה לעבודה.
הוגדר ניטור סטטוסים: ברגע שקבלה נתקעה מעבר לזמן בקרה, המערכת הרימה התראה וחזרה על הפעולה אוטומטית. החזרות ותיקונים קושרו לקבלה המקורית, כדי לא להרבות מסמכים מיותרים.
מה נהיה
שיעור הקבלות המוצלחות ללא התערבות ידנית עלה ל-99,6%. זמן התגובה לתקלה הצטמצם מיממה לדקות — ההתראה מגיעה מיד, והחזרה בדרך כלל סוגרת את העניין ללא מפעיל. סוג הסירוב "קבלה תקועה" בוטל כתופעה: אין עוד צורך בטיפול ידני בתור, והנהלת החשבונות מקבלת הצלבה ללא פערים.
במה שונה אינטגרציית OrangeData מחיבור ישיר
חיבור ישיר משמעו שכל קופה, כל נקודה וכל תרחיש מכירה מתקשרים עם מערכת הנה"ח ישירות — בערוץ משל עצמם, עם כללי התאמת פריטים משלהם והגדרות פיסקליזציה משלהם. כל עוד יש נקודה אחת, זה עובד.
ברגע שמופיעה קופה שנייה, חנות אינטרנטית או מסחר נייד, מתחיל חוסר סנכרון: במקום אחד הקבלה נשלחה פעמיים, במקום אחר לא נשלחה כלל, וההתאמה הופכת לניתוח ידני של לוגים עבור כל קופה בנפרד.
אינטגרציית OrangeData מסירה את הריבוי הזה: כל הפעולות הפיסקליות עוברות דרך שירות אחיד, ומערכת הנה"ח והאתר עובדים עם ממשק אחד במקום סט של חיבורים הטרוגניים.
עבור הלקוח המשמעות היא�הוספת נקודה חדשה היא הגדרה, ולא פרויקט נפרד, והלוגיקה של קבלות, החזרות ושיעורי מע"מ מתוארת במקום אחד ומיושמת באופן זהה בכל הערוצים.
ההבדל מתגלה בהחזרות ובתיקונים. בחיבור ישיר, החזרה לפי קבלה שהונפקה בקופה אחרת או בתרחיש אחר מחייבת לעיתים קרובות פעולה ידנית ותשומת לב של המפעיל. דרך OrangeData ההחזרה מקושרת לקבלה המקורית לפי מזהה, והפעולה עוברת באותו מסלול שבו עברה המכירה — ללא תלות היכן הונפקה הקבלה במקור.
יש גם צד שני למטבע: שירות אחיד הוא חוליה נוספת בשרשרת, ומוטלות עליו אותן דרישות לעמידות בכשלים כמו על הקופה. לכן בפרויקט אנחנו מגדירים מראש תור לשליחות חוזרות: אם הקשר עם השירות אבד, הקבלה אינה הולכת לאיבוד, אלא נשלחת לאחר השחזור, והפער נרשם ביומן ומטופל לפני סגירת המשמרת.
הבחירה בין הגישות מצטמצמת למספר ערוצי המכירה ולדרישות להתאמה. קופה אחת עם תרחיש אחד — חיבור ישיר פשוט וזול יותר לתחזוקה. מספר נקודות, חנות אינטרנטית, מרקטפלייסים או החזרות סדירות — אינטגרציית OrangeData נותנת נקודת בקרה אחידה והתאמה צפויה.
אנחנו בדרך כלל מחשבים את שתי האפשרויות בשלב ההערכה ומראים היכן בדיוק המסלול הישיר יתחיל ליצור פערים.
ספקות טכניים נפוצים
אינטגרציה עם פיסקליזציה היא אותו חלק במעגל שבו טעויות נראות לא בלוגים, אלא בדיווחים ובתביעות של לקוחות. להלן הספקות הטכניים שעולים לרוב ביותר בהתחלה ובחודשי ההפעלה הראשונים, וכיצד אנו סוגרים אותם.
כיצד בנויים החזרים ותיקוני קבלות?
החזר הוא קבלה נפרדת עם סימן חישוב "החזרת הכנסה", שמפנה למסמך המקורי. אנו שומרים במסד הנתונים את הקישור "הזמנה — קבלה — פריטים", ולכן החזר עבור פריט מסוים או עבור כל הסל נוצר אוטומטית, ללא הזנה ידנית של סכומים. החזר חלקי והחזר עבור מספר הזמנות בו-זמנית מעובדים בנפרד, כדי שבדיווחים לא יתערבבו עילות שונות.
מהיכן מגיעים כפילויות של קבלות וכיצד אתם מונעים אותן?
כפילות מופיעה כאשר בקשה חוזרת נשלחת לאחר פסק זמן, והקבלה הראשונה כבר נרשמה. אנו מקצים לכל פעולה מזהה ייחודי ובודקים את הסטטוס לפני השליחה — רישום חוזר לפי אותו מזהה אינו עובר. אם בכל זאת קבלה נשלחה פעמיים, התאמה לפי יומן הפעולות מגלה את הפער ומפעילה תיקון.
מה קורה בעת תקלת תקשורת עם הקופה?
פעולות שלא הצליחו להירשם נכנסות לתור תוך שמירה על כל נתוני ההזמנה. עם שחזור התקשורת התור מעובד לפי הסדר, והפערים מותאמים מול יומן הקופה. עבור תרחישים קריטיים אנו מגדירים התראות לאחראי — התקלה נראית לפני שהתור מצטבר.
האם ניתן לחבר מספר קופות ונקודות?
כן. כל קופה ונקודת מכירה מקבלת קבוצת פרטי חשבון משלה, וניתוב הקבלות מתבצע לפי חטיבה או מחסן. הדבר מאפשר לנהל חשבונאות נפרדת, בלי לערבב הכנסות, ולהוסיף נקודות חדשות בלי לבנות מחדש את הלוגיקה.
מה יקרה לאחר עדכון הפלטפורמה או המודול?
עדכונים נבדקים על עותק: בודקים רישום, החזרים, עבודת התור והתאמה. שינויים ב-API של הפיסקליזציה נעקבים בנפרד, כדי שעדכון הפלטפורמה לא ישבור את החילוף. חזרה לאחור — באמצעות גיבוי של התצורה ומסד הנתונים.
תארו את הסכימה שלכם — מספר קופות, נקודות, תרחישי החזרים — ונחזור עם הערכה ותוכנית אינטגרציה.
בואו נדון במשימת הפיסקליזציה שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה על קווי המתאר של הפיסקליזציה שלכם. תארו את המשימה בצורה חופשית — בהמשך נבהיר את הפרטים בעצמנו.
- אילו קופות ודגמי רושמים פיסקליים כבר בשימוש או מתוכננים: קופה בענן, מסוף חכם, מכשיר פיזי בנקודה.
- כיצד מתבצעות המכירות כעת: דרך 1С-Битрикс, Битрикс24, 1С:Управление торговлей או בכמה מערכות בו-זמנית, והיכן בדיוק צריכה להיות הפיסקליזציה.
- אילו תרחישים צריך לכסות: חישוב מלא, תשלום מקדמה, תשלום חלקי, תשלום בתשלומים, קבלות תיקון.
- כיצד בנויות ההחזרות: מלאות וחלקיות, החזרה לפי הקבלה המקורית, החזרה בתשלום בכמה אמצעים, החזרות עבור תקופות קודמות.
- אילו מערכות מיסוי מיושמות והאם נדרשת העברת נומנקלטורה, תגיות של נושא החישוב וסימני סוכנות בקבלה.
- האם יש הרשאות לגישה לצורך אינטגרציה: חשבון OrangeData, חשבון 1С, סביבת בדיקה שבה אפשר להריץ קבלות ללא סיכון למכירות בסביבת הייצור.
- אילו דרישות אמינות קיימות: מה צריך לקרות עם הקבלה אם הקופה או הערוץ אינם זמינים, ובאיזו מהירות המכירות צריכות להתאושש.
לפי הנתונים האלה אנחנו מרכיבים תרשים של זרימות הקבלות, מזהים נקודות כשל והיקף ההתאמות ב-1С-Битрикс וב-Битрикс24. לאחר מכן אתם מקבלים הערכה לפי שלבים, תוכנית עבודה עם סדר ההטמעה ורשימה של מה שצריך להכין מצדכם.
הצעד הבא — ניתוח קצר של המשימה: אתם שולחים תיאור והרשאות גישה לסביבת הבדיקה, ואנחנו חוזרים עם הערכה ותוכנית עבודה.