אין היום חיבור מובנה בין monday לחשבונית ירוקה (Morning), ולכן מחברים ביניהן דרך כלי אוטומציה כמו Make, שמדבר עם ה-API של Morning. בפועל זה עובד ככה: שינוי סטטוס בלוח ב-monday, למשל ל"שולם", מפעיל תרחיש שמפיק את המסמך ב-Morning, ומספר המסמך וקישור ל-PDF נכתבים בחזרה באותה שורה. אפשר גם לעבוד בכיוון ההפוך, כך שכל מסמך או תשלום שנוצר ב-Morning מתעדכן לבד ב-monday.
את התהליך הכללי של חשבוניות אוטומטיות, כולל ההשוואה בין Morning, iCount ו-EZcount, מניעת הפקה כפולה ושאלות המס, כבר כתבתי במאמר על חשבוניות וקבלות אוטומטיות. כאן אני מתמקד בצד של monday: איך בונים את הלוח, איזה טריגר לבחור, איך נראה התרחיש, ואיפה זה נשבר.
יש אפליקציה מוכנה שמחברת monday ל-Morning?
בדקתי את זה באוקטובר 2026. בעמוד האינטגרציות של Morning מופיעים חיבורים ל-WooCommerce, Wix, Shopify, Priority, חשבשבת ועוד, וגם לכמה מערכות CRM, אבל monday לא ברשימה. במרקטפלייס של monday לא מצאתי אפליקציה רשמית של Morning.
ל-monday CRM יש כלי מובנה בשם Quotes & Invoices, שמפיק הצעות מחיר וחשבוניות מתוך הלוחות. לא מצאתי בתיעוד שלו התייחסות לדרישות של רשות המסים בישראל, כמו מספר הקצאה, ו-monday עצמה כותבת שחיבור למערכות חיצוניות עוד בפיתוח. לכן, אם Morning היא תוכנת החשבוניות שלכם, המסמך צריך להיות מופק בה.
מה שנשאר הן שלוש דרכים:
| הדרך | מה זה אומר | מתי אני בוחר בה |
|---|---|---|
| Make עם האפליקציה של Morning | מודולים מוכנים כמו יצירת מסמך ויצירת לקוח | כשרוצים לבנות מהר ומוכנים לבדוק אפליקציה שלא Make מתחזקת |
| Make עם מודול HTTP מול ה-API | בקשת טוקן, ואז יצירת מסמך בקריאה ישירה | כשרוצים שליטה מלאה ולא תלות בצד שלישי |
| קוד משלכם או שרת ביניים | Webhook מ-monday לשרת שקורא ל-API | כשיש מפתח בבית ותהליך מורכב במיוחד |
ב-Make יש כמה אפליקציות של Morning, וכולן מסומנות כאפליקציות קהילתיות. כלומר Make לא מתחזקת אותן, והתמיכה היא של המפתח שבנה אותן (נכון לאוקטובר 2026). זה לא פוסל אותן, אבל בתהליך כספי אני רוצה לדעת מי אחראי כשמשהו משתנה. את הבנייה ב-HTTP, כולל קודי המסמכים והשדות, פירטתי במדריך חשבונית ירוקה ו-Make דרך ה-API.
מה צריך ב-Morning לפני שמתחילים?
- מסלול שכולל API. לפי עמוד המחירים של Morning, אוטומציות דרך API, אינטגרציות ו-Webhooks כלולים ממסלול Best ומעלה, ולא במסלול Basic (נכון לאוקטובר 2026).
- מפתח API. יוצרים אותו בהגדרות, תחת כלי מפתחים. מקבלים מזהה וסוד, ומחליפים אותם בטוקן גישה שתקף לשעה.
- כתובת עדכנית. Morning שינתה ביוני 2026 את כתובת הבסיס של ה-API ואת מבנה בקשת הטוקן, והכתובות הישנות נחסמו. אם יש לכם חיבור ישן שהפסיק לעבוד, זו הסיבה הראשונה שכדאי לבדוק.
- סביבת בדיקות. ל-Morning יש sandbox נפרד. אני בונה ובודק שם, ורק אחר כך מחליף לחשבון האמיתי.
איך לבנות את הלוח ב-monday לחשבוניות?
רוב הבעיות שאני רואה בחיבורים כאלה מתחילות בלוח ולא בתרחיש. אלה העמודות שאני מוסיף ללוח העסקאות:
- לקוח. שם הלקוח כפי שצריך להופיע על המסמך. שם הפריט ב-monday הוא בדרך כלל שם העסקה ("אתר חדש, שלב 2"), ולא תמיד שם הלקוח.
- ח"פ או ת"ז. עמודת טקסט ולא עמודת מספר, כדי שאפסים בהתחלה לא ייעלמו.
- מייל. עמודת מייל. Morning שולחת את המסמך לכתובות שמועברות בשדה המיילים של הלקוח.
- סכום. עמודת מספרים, וליד הכותרת שלה כתוב במפורש אם הסכום כולל מע"מ או לא.
- מע"מ. עמודת סטטוס עם שלוש אפשרויות: "כולל מע"מ", "לפני מע"מ", "פטור".
- סוג מסמך. עמודת סטטוס: חשבונית מס, חשבונית מס קבלה, קבלה, ובעמותות גם קבלה על תרומה.
- אמצעי תשלום ותאריך תשלום. צריך אותם כשהמסמך כולל קבלה.
- מספר מסמך וקישור ל-PDF. שתי עמודות ריקות שהתרחיש ממלא.
- סטטוס הפקה. "ממתין", "הופק", "שגיאה".
אם הלקוחות יושבים בלוח נפרד ומחוברים לעסקה בעמודת Connect boards, התרחיש צריך לקרוא גם את הפריט בלוח הלקוחות. עמודת Mirror שמציגה את המייל בלוח העסקאות נוחה לעין, אבל ב-Make קל יותר לשלוף את הנתון ישר מהפריט המקורי. על בניית הלוחות עצמם, לקוחות מול עסקאות, כתבתי בעמוד על מערכת CRM לניהול לקוחות.
איזה טריגר לבחור: סטטוס "שולם" או קישור תשלום?
יש שתי נקודות התחלה טובות, ולפעמים משתמשים בשתיהן.
סטטוס ב-monday. מישהו מסמן "שולם" אחרי שראה העברה בבנק, או "לחיוב" כשצריך להוציא חשבונית מס לפני התשלום. ה-API של monday תומך ב-webhook שנשלח רק כשעמודת סטטוס מסוימת מקבלת ערך מסוים, וגם האפליקציה של monday ב-Make יודעת להאזין לשינויים בלוח. זה הטריגר הכי פשוט, והוא מתאים לעסק שבו מישהו ממילא מעדכן את הלוח. בסוכנות הנסיעות שעבדתי איתה הצעת המחיר יוצאת בדיוק ככה, משינוי סטטוס אחד, והעיקרון זהה גם לחשבונית.
קישור תשלום של Morning. ב-API יש פעולה שיוצרת טופס תשלום ומחזירה קישור לשלוח ללקוח. כשהלקוח משלם, Morning מפיקה את המסמך לבד. לבקשה אפשר לצרף שדה custom, למשל את מזהה הפריט ב-monday, וכתובת notifyUrl שמקבלת הודעה כשהתשלום עבר והמסמך נוצר. כך התרחיש יודע בדיוק איזו שורה לעדכן. זה מתאים לעסק שגובה מראש: הלוח שולח קישור, והחשבונית והעדכון קורים בלי שאף אחד נוגע.
איך נראה התרחיש ב-Make, צעד אחר צעד?
זה המבנה שאני בונה כשהטריגר הוא סטטוס:
- טריגר מ-monday: עמודת "סטטוס תשלום" השתנתה.
- מסנן: הסטטוס הוא "שולם", ועמודת מספר המסמך ריקה. הבדיקה השנייה היא מה שמונע חשבונית כפולה, ופירטתי עליה במאמר על חשבוניות אוטומטיות.
- קריאת הפריט המלא מ-monday, ואם צריך גם את פריט הלקוח מהלוח המחובר.
- אם עובדים ב-HTTP: בקשת טוקן מ-Morning.
- יצירת המסמך: סוג המסמך (305 לחשבונית מס, 320 לחשבונית מס קבלה, 400 לקבלה), שפה, מטבע, פרטי הלקוח, שורות הכנסה, ובמסמך שכולל קבלה גם שורת תשלום.
- כתיבה בחזרה ל-monday: מספר המסמך, הקישור ל-PDF שחוזר בתשובה, וסטטוס "הופק".
- נתיב שגיאה: אם Morning החזירה שגיאה, הסטטוס משתנה ל"שגיאה בהפקה" ונשלחת התראה למי שאחראי.
אם זה התרחיש הראשון שלכם ב-Make, כדאי להתחיל מתרחיש ראשון פשוט יותר ולחזור לזה אחר כך. תהליך כספי הוא לא המקום ללמוד את הכלי.
איך מחזירים מסמכים ותשלומים מ-Morning ל-monday?
לא כל מסמך יוצא מהלוח. מישהו מפיק קבלה ידנית על תשלום בביט, או שלקוח משלם בדף מכירה. כדי ש-monday תדע על זה, מגדירים ב-Morning webhook, תחת כלי מפתחים ואז Webhooks. בוחרים את האירועים, למשל מסמך שנוצר (document/created) או תשלום שהתקבל (payment/received), ומדביקים את הכתובת של תרחיש ב-Make.
התרחיש מקבל את ההודעה, מחפש ב-monday את הלקוח או העסקה לפי מייל או ח"פ, ומעדכן את השורה. אם לא נמצאה התאמה, הוא יוצר פריט בקבוצה "לבדיקה" במקום לנחש.
שני דברים מהתיעוד של Morning ששווה להכיר. אפשר להגדיר ל-webhook סוד, ואז כל הודעה מגיעה עם חתימה שמאפשרת לוודא שהיא באמת מ-Morning. ואחרי 15 משלוחים שנכשלו, ה-webhook הופך ללא פעיל ומפסיק לשלוח. לכן כדאי לבדוק מדי פעם שהוא עדיין פעיל, במיוחד אחרי שתרחיש היה כבוי.
מה בדרך כלל משתבש?
- מע"מ כפול. בכל שורת הכנסה ב-Morning יש שדה שאומר אם המחיר כולל מע"מ, לפני מע"מ, או פטור. אם ב-monday הסכום כולל מע"מ והשדה נשאר על ברירת המחדל, Morning תוסיף מע"מ מעל הסכום, והלקוח יקבל חשבונית גבוהה ממה שסיכמתם. אני ממפה את השדה ישירות מעמודת המע"מ בלוח.
- שם עסקה במקום שם לקוח. כשממפים את שם הפריט לשם הלקוח, החשבונית יוצאת על שם "אתר חדש, שלב 2". עמודת לקוח נפרדת פותרת את זה.
- שורות פריטים. אם יש לכם כמה שירותים בעסקה, מחזיקים אותם כתתי-פריטים (subitems), וב-Make אוספים אותם למערך של שורות הכנסה. אם שולחים רק את הסכום הכולל, המסמך יוצא עם שורה אחת וכללית.
- ח"פ שנחתך. עמודת מספר מוחקת אפס בהתחלה. מספר מזהה תמיד נשמר כטקסט.
- לולאה. התרחיש כותב בחזרה לאותו לוח, והכתיבה עצמה משנה עמודות. אם הטריגר מאזין לכל שינוי בלוח, הוא יכול להפעיל את עצמו שוב. מאזינים רק לעמודת הסטטוס, ומשאירים את בדיקת מספר המסמך במסנן.
- מכסה. אם ה-webhook או הפעולות בצד של monday נבנים כאוטומציות או אינטגרציות מתוך monday, הם צורכים פעולות מהמכסה החודשית. בלוח עם הרבה עסקאות זה מצטבר, והסברתי מה נספר ואיך חוסכים במאמר על אוטומציות במאנדיי.
שאלות נפוצות
יש ל-Morning אינטגרציה רשמית עם monday?
נכון לאוקטובר 2026, לא מצאתי כזו. monday לא מופיעה בעמוד האינטגרציות של Morning, ולא מצאתי אפליקציה של Morning במרקטפלייס של monday. מחברים דרך Make או דרך ה-API.
אפשר להשתמש ב-Zapier במקום Make?
אפשר לחבר כל כלי שיודע לשלוח בקשות HTTP ל-API של Morning. אני בונה את זה ב-Make, כי קל בו לעבוד עם מערכים של שורות פריטים ולבנות נתיב שגיאה מסודר.
איזה מסלול של Morning צריך?
לפי עמוד המחירים של Morning, גישה ל-API ול-Webhooks כלולה ממסלול Best ומעלה (נכון לאוקטובר 2026). כדאי לוודא מולם לפני שמתחילים לבנות.
אפשר להפיק גם הצעת מחיר או חשבון עסקה מתוך monday?
כן. ה-API של Morning תומך בכמה סוגי מסמכים, ביניהם הצעת מחיר וחשבון עסקה. מוסיפים אותם לעמודת סוג המסמך, והתרחיש שולח את הקוד המתאים.
מה קורה אם המסמך הופק עם טעות?
מסמך מס לא מוחקים. מבטלים או מפיקים חשבונית זיכוי, לפי מה ש-Morning מאפשרת ולפי מה שרואה החשבון שלכם אומר. בגלל זה אני בודק כל תרחיש כזה קודם בסביבת הבדיקות של Morning.
אם אתם עובדים עם monday ו-Morning ורוצים שהחשבוניות ייצאו מהלוח, כתבו לי ונבדוק איך הלוח שלכם בנוי.
עודכן לאחרונה: אוקטובר 2026
