חשבונית ירוקה ממאנדיי: איך מפיקים חשבונית מס אוטומטית כשסוגרים עסקה

כרטיס שעובר לעמודת סטטוס "סגור" ב-monday CRM הוא בדרך כלל הרגע שבו עסק צריך להוציא חשבונית ירוקה ממאנדיי, ולא לחכות שמישהו יזכור לפתוח את מורנינג ולהקליד את הפרטים בשנית. ברוב המקרים הפער הזה נסגר באמצעות Make או n8n: תרחיש אחד שקורא את האייטם מהלוח, בודק מה צריך לקרות, ומדבר עם ה-API של מורנינג כדי שהחשבונית תצא בלי שאף אחד פותח טאב נוסף. החלק המעניין הוא לא יצירת המסמך עצמה, אלא ההחלטה שהתרחיש צריך לקבל לפני כן: האם מותר להפיק את המסמך ישר, או שחוקי המע"מ מחייבים לעצור רגע ולבקש מספר מרשות המסים קודם.

ברוב המקרים התרחיש לא בודק את כל הלוח בפולינג, הוא מאזין לעמודת הסטטוס דרך Webhook native של monday. לפי תיעוד ה-API הרשמי, הרשמת Webhook כזו מאומתת בבדיקת אתגר: monday שולחת טוקן אקראי בבקשת POST ראשונה אל ה-endpoint, וההרשמה מאושרת רק אם אותו endpoint מחזיר בדיוק את אותו טוקן בתשובה. גם כדאי לדעת מה קורה כש-Make או n8n לא זמינים לרגע: אם ה-endpoint לא מגיב בהצלחה, monday שולחת את הבקשה שוב אחת לדקה למשך 30 דקות, ולא מעבר לזה, כך שתקלה ברשת שנמשכת יותר מחצי שעה כבר לא תיתפס לבד.

רוב התקלות בתהליך הזה לא קשורות לחיבור הטכני בין monday למורנינג. הן קורות כי התרחיש מפיק מסמך מכל אייטם שנסגר, בלי לבדוק קודם כמה שווה העסקה ולמי היא יוצאת.

חמישה שדות שחייבים להגיע למורנינג לפני שמפיקים מסמך

כדי שמורנינג תפיק מסמך תקין, המיפוי מהלוח צריך לכלול חמישה פרטים קבועים, בלי קשר לשיטת החיבור שבוחרים:

• מספר עוסק מורשה או ת"ז של הלקוח, כי זה מה שקובע אם בכלל צריך מספר הקצאה.
• סכום העסקה לפני מע"מ וסכום המע"מ בנפרד, לא רק סכום כולל אחד.
• פירוט הפריטים או השירות שנמכר, שורה נפרדת לכל רכיב בעסקה.
• אמצעי התשלום, כי מסמך מסוג חשבונית מס/קבלה דורש גם מערך תשלום ולא רק סכום.
• מספר ההקצאה עצמו, כשהעסקה עוברת את הסף, לפני שליחת הבקשה הסופית ליצירת המסמך.

מתי חובה מספר הקצאה, ומתי אפשר בלי?

רשות המסים מנפיקה מספרי הקצאה לחשבוניות מס שיוצאות ללקוחות הרשומים כעוסק מורשה, והמספר הזה הוא תנאי לכך שהלקוח יוכל לנכות מע"מ תשומות על העסקה. המודל הזה רץ מכוח חוק ההתייעלות הכלכלית (תיקוני חקיקה), התשפ"ג-2023, והופעל החל מ-1.1.2024. התקרה ירדה בשלבים: 20,000 ₪ לפני מע"מ בשנת 2025, 10,000 ₪ מ-1 בינואר 2026, ו-5,000 ₪ מ-1 ביוני 2026. המשמעות היא שכרגע, כל חשבונית מס שיוצאת מ-monday ללקוח עוסק מורשה בסכום של 5,000 ₪ ומעלה לפני מע"מ, חייבת לשאת מספר הקצאה כדי שהצד השני יוכל לנכות את המע"מ שלו. עסקה מתחת לסכום הזה, או ללקוח שהוא צרכן פרטי ולא עוסק מורשה, לא עוברת דרך השלב הזה בכלל.

הבקשה עצמה ניתנת ללא עלות, ולפי רשות המסים חייבת לכלול ארבעה פרטים קבועים: מספר העוסק המורשה של הלקוח, מספר החשבונית, סכום החשבונית לפני מע"מ וסכום המע"מ בנפרד. אלה בדיוק ארבעה מתוך חמשת השדות שהתרחיש צריך למפות מהכרטיס, מה שאומר שהמיפוי לא שרירותי, הוא מועתק ישירות מהטופס הרשמי.

ההשלכה המעשית על התרחיש היא שהבדיקה לא יכולה להסתכל רק על הסכום בעמודה. היא צריכה לבדוק גם את סוג הלקוח בכרטיס, כי בקשת מספר הקצאה ללקוח פרטי פשוט תידחה על ידי המערכת.

שלוש דרכים לחבר את הלוח ל-API של מורנינג

יש שלוש דרכים סבירות לבנות את החיבור, וההבדל האמיתי ביניהן הוא כמה שליטה יש על מה שנשלח בכל קריאה:

הקונקטור הקהילתי של מורנינג ב-Make חושף 15 מודולים קבועים: Add Document, Add Client, Search Documents, Update Client, Get All Documents ועוד, כולל Make an API Call לקריאות מותאמות אישית. כדי להשתמש בו צריך מסלול Best ומעלה במורנינג, כי רק שם נפתחת האפשרות ליצור מפתח API בכלל. קונקטור אחד של מורנינג ב-Make, נכון לכתיבת שורות אלה, רץ בלמעלה מ-2,000 תרחישים שונים, מה שאומר שזו דרך מוכרת ולא ניסיונית.

הבעיה של המודול המוכן היא שהוא לא תמיד חושף שדה למספר הקצאה בתוך קריאת יצירת המסמך, כי הוא נבנה לתרחיש הכללי ולא לרפורמת החשבוניות הספציפית. שם הפתרון הוא מודול Make an API Call בתוך Make, או HTTP Request node רגיל ב-n8n, ששניהם מדברים ישירות מול https://api.greeninvoice.co.il/api/v1 עם אותו אימות OAuth 2.0: מחליפים את מפתח ה-API בטוקן שתקף לשעה, ואז שולחים בקשת POST ל-documents עם כל השדות כולל מספר ההקצאה שהתקבל בשלב הקודם. זה אותו עיקרון שמופיע בחיבור בין מאנדיי לפריוריטי: כש-ERP חיצוני לא חושף את כל מה שצריך דרך הקונקטור המוכן, הפתרון הוא לרדת שלב אחד ולדבר ישר מול ה-API.

ב-n8n אין עדיין node ייעודי למורנינג, אז ההגדרה הכי נקייה היא Generic Credential מסוג HTTP Header Auth, עם שלב נפרד בתחילת התרחיש שמחליף את מפתח ה-API בטוקן ושומר אותו למשך שעה, לפני שממשיכים לקריאת ה-POST עצמה. כי הטוקן פג אחרי שעה, תרחיש שרץ כמה פעמים ביום צריך גם בדיקה פשוטה אם הטוקן הקיים עדיין בתוקף, ורק אם לא, לבקש טוקן חדש, במקום לפנות לשרת האימות בכל הרצה בלי צורך.

מבנה הבקשה: מה שולחים למורנינג כשסוגרים עסקה

ברמת העיקרון, כך נראית בקשה ליצירת מסמך מסוג חשבונית מס/קבלה, עם כל השדות שצריך למפות מהכרטיס ב-monday:

{
  "type": "invoiceReceipt",
  "client": {
    "name": "שם הלקוח מהכרטיס",
    "taxId": "ח.פ או ת.ז של הלקוח",
    "emails": ["billing@client.co.il"]
  },
  "income": [
    {
      "description": "תיאור הפריט מהלוח",
      "quantity": 1,
      "price": 5900,
      "currency": "ILS",
      "vatType": "INCLUDED"
    }
  ],
  "payment": [
    { "type": "CREDIT_CARD", "price": 5900 }
  ],
  "remarks": "מספר הקצאה: 123456789"
}

זה מבנה עקרוני, לא ציטוט מדויק של הסכימה הרשמית, אבל כל שדה בו תואם למשהו שכבר קיים בכרטיס: שם הלקוח, ח"פ, סכום, אמצעי תשלום ומספר ההקצאה כשהוא נדרש. התפקיד של התרחיש הוא רק למפות עמודה לעמודה.

איך הקובץ חוזר ללוח ונשלח ללקוח

אחרי שהבקשה נשלחת, מורנינג מפעילה אירוע Webhook מסוג document created שמחזיר קישור PDF ומספר מסמך. התרחיש כותב את שני אלה חזרה לעמודות בכרטיס, באותה שיטה שמתוארת בחיבור וואטסאפ למאנדיי: עמודת סטטוס מתעדכנת ל"חשבונית הופקה", ועמודת קובץ מקבלת את הקישור. משם, אותו תרחיש או תרחיש נפרד שולח את הקישור בהודעת וואטסאפ ללקוח, בלי שמישהו בצוות פותח את מורנינג בעצמו.

הדפוס הזה חוזר בכל פעם שעסק עובד עם CRM ישראלי שמתחבר לחשבשבת או למורנינג: ההקלדה הכפולה היא לא רק בזבוז זמן, היא נקודת כשל שבה פרטים משתנים בין המערכות. ההחלטה איפה לעצור ולבדוק תנאי, לעומת איפה בטוח להריץ אוטומטית, היא בדיוק השאלה שחוזרת בכל אוטומציית CRM שנוגעת בכסף: לא כל שלב שווה לאוטומט בלי תנאי עצירה.

השילוב הזה פותר יפה את החיבור בין הסגירה בפייפליין להפקת החשבונית, אבל הוא עדיין מתייחס למאנדיי כ-CRM ולחשבונית ירוקה ככלי הנהלת חשבונות נפרדים, ברגע שעולה צורך במלאי, הזמנות רכש או דוחות כספיים מאוחדים, השאלה כבר לא "איך מחברים שני כלים" אלא איזה סוג תוכנה לניהול עסק מתאים לשלב הבא, הנהלת חשבונות מורחבת או ERP מלא. שווה למפות את זה מראש כדי לא לגלות באמצע השנה שהאינטגרציה הקטנה הזו הופכת לפתרון מדבק שצריך לפרק.

הבדיקה הכי זולה שאפשר להוסיף לתרחיש הזה היא לא טכנית, היא חשבונאית: לסמן באיזה לוחות נוצרות עסקאות מעל 5,000 ₪ לעוסקים מורשים, ולוודא שהתרחיש שבודק אותם עובר דרך בקשת מספר ההקצאה לפני שהוא נוגע במורנינג בכלל. כדאי גם לבדוק מה קורה כשהסכום עצמו משתנה אחרי סגירת העסקה, למשל כשמוסיפים שורה או נותנים הנחה, כי אז הבדיקה מול הסף צריכה לרוץ מחדש ולא להסתמך על ערך שנשמר פעם אחת בתחילת התהליך. זה ההבדל בין אוטומציה שחוסכת הקלדה, לבין אוטומציה ששומרת גם על זכות הניכוי של הלקוח.

סער

עודכן 8 באוקטובר 2026

מייסד Spike · monday Certified Partner

סער הוא המייסד של Spike. אנחנו בונים את שכבת התפעול של עסקים ישראליים — monday CRM, אוטומציות וסוכני וואטסאפ מבוססי AI — ואת הכלים שמריצים אותה.