איך מחברים את Salesforce למורנינג, ל-iCount, ל-Invoice4U או לפריוריטי כך ש-Opportunity שנסגרה בזכייה מפיקה חשבונית מס: אפשרויות Flow, Apex ושירות ביניים, מכסות ה-API לפי מהדורה, ואיפה נרשם בחזרה מספר ההקצאה.
עיקרי הדברים
- הטריגר הוא השדה IsWon של ה-Opportunity, ש-Salesforce קובעת לפי StageName, ולא שם של שלב.
- הקריאה ל-API של החשבוניות מתבצעת אחרי שהשמירה נרשמה: בנתיב Run Asynchronously ב-Flow או ב-Queueable ב-Apex.
- HTTP Callout ב-Flow נכשל רק בסטטוס 300 ומעלה, ולכן שגיאות של Invoice4U שחוזרות עם 200 דורשות בדיקה מפורשת.
- את מספר ההקצאה מקבלת מערכת החשבוניות; Salesforce שומרת אותו לצד מספר המסמך ושדה סטטוס.
כדי להפיק חשבונית מס כש-Opportunity נסגרת ב-Salesforce, מפעילים את התהליך על המעבר של ה-Opportunity למצב זכייה, קוראים ל-API של מערכת החשבוניות (מורנינג, iCount, Invoice4U או פריוריטי) מחוץ לטרנזקציית השמירה, ורושמים בחזרה על ה-Opportunity את מספר המסמך, מזהה המסמך ומספר ההקצאה. את מספר ההקצאה מקבלת מערכת החשבוניות, לא Salesforce.
Salesforce נפוצה בחברות B2B בישראל, ואין לה חיבור מובנה למערכות החשבוניות הישראליות. בפועל אנשי המכירות סוגרים עסקה ב-Salesforce ומישהו מקליד אותה מחדש במערכת החשבוניות. כאן תמצאו את אפשרויות החיבור ש-Salesforce באמת מציעה, את סדר הפעולות שמונע מסמכי מס כפולים, ומה משתנה בין מערכת חשבוניות אחת לאחרת. אם אתם עוד בוחרים CRM, ההשוואה נמצאת במאמר HubSpot מול Salesforce.
מה צריך להפעיל את הפקת החשבונית ב-Salesforce?
הטריגר הנכון הוא השדה IsWon של ה-Opportunity שהופך ל-true, ולא שם של שלב מסוים. לפי תיעוד האובייקטים של Salesforce, IsWon ו-IsClosed הם שדות בוליאניים שנקבעים לפי StageName: אפשר לסנן לפיהם, אבל אי אפשר לעדכן אותם ישירות. תנאי על IsWon ממשיך לעבוד גם כשמנהל המערכת משנה את השם של שלב "Closed Won" או מוסיף שלב זכייה נוסף.
עוד שני שדות חשובים לפני שסכום כלשהו יוצא מ-Salesforce. AccountId מצביע על הלקוח, ושם בדרך כלל שמור הח"פ או הת"ז בשדה מותאם. ו-Amount, ב-Opportunity עם מוצרים, הוא סכום שורות המוצרים - עדכון שמנסה לשנות אותו פשוט לא מתבצע, בלי הודעת שגיאה. לכן את שורות החשבונית צריך לבנות ממוצרי ה-Opportunity, ולא מסכום כולל אחד.
באיזו אפשרות חיבור של Salesforce כדאי לבחור?
הבחירה תלויה בשאלה איפה יישבו לוגיקת הניסיונות החוזרים והפרטים המזהים. יש ארבע דרכים מעשיות לקרוא ל-API של מערכת חשבוניות ישראלית:
| אפשרות | איך זה רץ | מתי זה מתאים | שימו לב |
|---|---|---|---|
| Flow מבוסס רשומה עם HTTP Callout | נתיב "Run Asynchronously" רץ אחרי שהשמירה של ה-Opportunity נרשמה, וקורא ל-API דרך Named Credential | מסמך אחד לעסקה, JSON פשוט, מנהל מערכת מתחזק | הפעולה לא תומכת בכותרות בקשה; רק סטטוס 300 ומעלה מגיע לנתיב השגיאה |
| קריאה מ-Apex (Queueable) | הקוד קורא ל-callout:Your_Named_Credential/... ומטפל בתשובה | מיפוי שורות, פענוח שגיאות מותאם, כמה מסמכים | עד 100 קריאות לטרנזקציה, 120 שניות זמן המתנה מצטבר, אין קריאה כשיש DML ממתין |
| שירות ביניים שמאזין ל-Change Data Capture | שירות חיצוני מקבל אירועי שינוי של Opportunity וקורא ל-API של החשבוניות | לוגיקת החשבוניות כבר יושבת מחוץ ל-Salesforce | Change Data Capture זמין רק במהדורות Enterprise, Performance, Unlimited ו-Developer |
| שירות ביניים שדוגם את ה-REST API | משימה מתוזמנת שולפת Opportunities שנסגרו בזכייה | נפח נמוך, או מהדורה בלי Change Data Capture | כל שליפה וכל כתיבה חוזרת נספרות במכסת ה-API היומית |
המסלול של Flow הוא הקל ביותר. בהודעת הגרסה שהציגה את הנתיב האסינכרוני, Salesforce מתארת אותו כדרך לקרוא לשירות חיצוני אחרי שהרשומה נשמרה, ומציינת שהנתיב עלול להתעכב כשמשאבי המערכת לא זמינים. לחשבונית זה מקובל, כי היא ממילא לא אמורה לעכב את השמירה של המשתמש. Apex נותן שליטה מלאה, והמגבלות בטבלה לקוחות מתיעוד ה-callout של Salesforce: זמן המתנה ברירת מחדל של 10 שניות לקריאה, שאפשר להגדיל עד 120,000 מילישניות.
סדר הפעולות, שלב אחר שלב
- לזהות את הזכייה. Flow מבוסס רשומה (אחרי שמירה, "Is Changed" על
IsWon) או מאזין ל-Change Data Capture מזהה שה-Opportunity נסגרה בזכייה. - לסמן כממתין. להגדיר שדה סטטוס מותאם, למשל
Invoice_Status__c = Pending, כדי שטריגר שני לא יתחיל מסמך שני. - לבנות את המסמך מה-Account (שם, ח"פ, מייל) וממוצרי ה-Opportunity (שם, כמות, מחיר), כשהטיפול במע"מ מוגדר לכל מוצר.
- לקרוא ל-API של החשבוניות מחוץ לטרנזקציית השמירה, ולשלוח את מזהה ה-Opportunity כמזהה הייחודי שלכם.
- לקרוא את התוצאה, לא רק את קוד הסטטוס. לבדוק בגוף התשובה אם יש שגיאות לפני שמתייחסים לקריאה כהצלחה.
- לכתוב בחזרה על ה-Opportunity את מספר המסמך, מזהה המסמך ומספר ההקצאה, ולעדכן את הסטטוס ל-
Issuedאו ל-Failedיחד עם טקסט השגיאה.
כשהכתיבה החוזרת מגיעה משירות ביניים, זו בקשת PATCH למשאב sObject Rows של ה-REST API עבור אותה Opportunity (/sobjects/Opportunity/{id}), והיא נספרת במכסת בקשות ה-API הנכנסות של הארגון.
איפה נכנס מספר ההקצאה?
החלק הזה הוא תיאור טכני, לא ייעוץ מס. במודל חשבוניות ישראל, חשבונית מס שעומדת בתנאים שנקבעו בחוק נושאת מספר הקצאה שמנפיקה רשות המסים. בחיבור ל-Salesforce מערכת החשבוניות מבקשת את המספר כחלק מהפקת המסמך. התפקיד של Salesforce הוא לשמור את מה שחזר, ולזהות מתי הוא לא חזר.
Invoice4U, לדוגמה, מחזירה על המסמך את AllocationNumber ואת AllocationMessage, ו-FetchAllocationNumber מבקשת מספר למסמך קיים. אילו חשבוניות צריכות מספר קובעת רשות המסים, והכלל השתנה במהלך 2026, ולכן הוא שייך להגדרות ולא לתנאי ב-Flow או לקבוע ב-Apex. הצד ההנדסי, כולל מה עושים כששירות רשות המסים איטי, מפורט במדריך ה-API למספרי הקצאה. אילו מסמכים העסק שלכם חייב להפיק, זו שאלה לרואה החשבון.
מה משתנה בין מערכות החשבוניות הישראליות?
הצד של Salesforce נשאר זהה. מה שמשתנה הוא האימות והדרך שבה חוזרות שגיאות:
- Invoice4U מחזירה שגיאות עסקיות בתוך תשובה עם סטטוס 200, במערך
d.Errors. HTTP Callout ב-Flow מתייחס רק לסטטוס 300 ומעלה כשגיאה, ולכן בלי בדיקה מפורשת שלErrorsקריאה שנכשלה נראית כהצלחה.CreateDocumentWithIdentifierValidationעםApiIdentifierשמכיל את מזהה ה-Opportunity דוחה ניסיון חוזר במקום להפיק מסמך שני. הפרטים במדריך ה-API של Invoice4U. - iCount בגרסת v3 הנוכחית מקבלת טוקן בכותרת
Authorization. פעולת ה-Flow לא מקבלת כותרות בקשה, ולכן את הכותרת צריך להגדיר ב-Named Credential. - מורנינג (חשבונית ירוקה) מנפיקה טוקנים קצרי חיים מתוך פרטי API קבועים, ואותם צריך לשמור ולחדש. אם ההחלפה הזו לא מתאימה לאפשרויות האימות של Named Credential, החידוש עובר ל-Apex או לשירות ביניים. ראו אוטומציה למורנינג דרך ה-API.
- פריוריטי היא בדרך כלל ה-ERP ולא כלי חשבוניות נפרד, והגישה אליה היא דרך ממשק REST/OData. כל התקנה מותאמת אישית, כך ש-Opportunity שנסגרה הופכת בדרך כלל להזמנה או לחשבונית בפריוריטי, ורשימת השדות מגיעה מסביבת הבדיקות של הלקוח עצמו.
מה משתבש בחיבור בין Salesforce למערכת חשבוניות
- חשבוניות כפולות מניסיונות חוזרים. timeout לא אומר ששום דבר לא הופק. תמיד שלחו את מזהה ה-Opportunity כמזהה חיצוני, ובדקו אם כבר קיים מסמך לפני ניסיון חוזר.
- Opportunity שנפתחה מחדש. אם עסקה שנסגרה בזכייה חוזרת לשלב קודם ונסגרת שוב, הטריגר רץ פעמיים. שדה הסטטוס (ממתין או הופק) הוא מה שעוצר את המסמך השני.
- קריאה אחרי DML. ב-Apex אי אפשר לבצע callout כשיש DML ממתין באותה טרנזקציה, ולכן הקריאה שייכת ל-Queueable או לנתיב אסינכרוני ב-Flow.
- חריגה ממכסת ה-API. המכסות של Salesforce נספרות לכל הארגון על פני 24 שעות, לא לכל משתמש: 15,000 קריאות ב-Developer Edition, ו-100,000 ועוד קריאות לכל רישיון ב-Enterprise Edition. עקבו אחריהן דרך המשאב
/limitsאו כותרת התשובהSforce-Limit-Info.
Professional Edition מופיעה בטבלת המכסות של Salesforce רק "with API access enabled", ולכן כדאי לוודא שיש גישת API במהדורה של הלקוח לפני שמתכננים מסלול עם שירות ביניים.
מקורות
שאלות נפוצות
האם Salesforce יכולה להפיק חשבונית מס ישראלית בעצמה?
לא באופן מובנה. ל-Salesforce אין חיבור מובנה למורנינג, ל-iCount, ל-Invoice4U או לפריוריטי, והיא לא מבקשת מספרי הקצאה מרשות המסים. המבנה המקובל משאיר את הפקת המסמך למערכת החשבוניות, מפעיל אותה כשה-Opportunity נסגרת בזכייה, ורושם בחזרה ב-Salesforce את מספר המסמך ואת מספר ההקצאה.
אפשר לחבר את Salesforce ל-API של חשבוניות בלי קוד?
לרוב כן. Flow מבוסס רשומה עם נתיב Run Asynchronously ופעולת HTTP Callout יכול לקרוא ל-API של JSON דרך Named Credential. המגבלות אמיתיות: הפעולה לא מקבלת כותרות בקשה, ורק סטטוס 300 ומעלה מגיע לנתיב השגיאה, ולכן שגיאות שחוזרות עם סטטוס 200 דורשות בדיקה מפורשת בתוך ה-Flow.
איזה שדה ב-Salesforce צריך להפעיל את החשבונית?
השדה IsWon של ה-Opportunity. Salesforce קובעת אותו לפי StageName ולא מאפשרת לעדכן אותו ישירות, ולכן תנאי על IsWon ממשיך לעבוד גם כשמשנים שם של שלב זכייה או מוסיפים שלב כזה. שלבו אותו עם שדה סטטוס חשבונית מותאם, כדי שעסקה שנפתחת מחדש ונסגרת שוב לא תפיק מסמך מס שני.
האם החיבור צורך את מכסת ה-API של Salesforce?
הקריאות הנכנסות כן. Salesforce סופרת בקשות REST, SOAP ו-Bulk API לארגון על פני 24 שעות מתגלגלות, לכל הארגון ולא לכל משתמש. ב-Enterprise Edition המכסה מתחילה ב-100,000 ועוד קריאות לכל רישיון. שירות ביניים ששולף עסקאות שנסגרו וכותב בחזרה תוצאות מוציא קריאות על שני הכיוונים. את הניצול בודקים במשאב ה-limits של ה-REST API.
איפה לשמור את מספר ההקצאה ב-Salesforce?
על ה-Opportunity, בשדה מותאם לצד מספר החשבונית ומזהה המסמך במערכת החשבוניות, ולידם שדה סטטוס ושדה שגיאה. המספר מגיע מהתשובה של מערכת החשבוניות. אם הוא חסר, ה-Opportunity צריכה להראות את זה, ולא להיראות כאילו החשבונית הופקה כשהמסמך בעצם לא שלם.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.