מורנינג / חשבונית ירוקה ואוטומציה - הפקת חשבונית לכל לקוח חדש
מורנינג, שנקראה קודם חשבונית ירוקה, היא אחת המערכות הישראליות הכי נוחות לחיבור. הממשק מודרני, יש סביבת בדיקות, והתהליך הבסיסי עולה לאוויר תוך ימים. מה שכן מסבך הוא לא הטכניקה אלא הכללים שמסביב - ואת אלה כדאי להכיר לפני שמפעילים.
למה זו נקודת הכניסה הנפוצה ביותר
מבין כל התהליכים שעסקים ישראליים מבקשים לייעל, הפקת חשבונית היא הנפוץ ביותר. הסיבה פשוטה: זו פעולה חוזרת, יש לה כללים ברורים, היא נעשית היום ידנית פעמים רבות בחודש, וטעות בה עולה כסף וזמן. זה בדיוק הפרופיל של תהליך שמתאים לאוטומציה.
מורנינג - השם החדש של מה שרוב העסקים עדיין מכירים כחשבונית ירוקה - היא גם המערכת הנוחה ביותר לחיבור מבין המערכות הישראליות שאנחנו עובדים איתן. יש ממשק מודרני, יש תיעוד, ויש סביבת בדיקות. זה שילוב לא מובן מאליו בשוק המקומי.
איך הממשק עובד
העבודה מול המערכת היא בסגנון REST, מה שאומר שכל כלי אוטומציה מודרני יכול לדבר איתה בלי מתווך. אתם מפיקים מתוך הגדרות החשבון זוג מפתחות - מזהה וסוד - ושומרים אותם במקום מאובטח בכלי האוטומציה, לא בגיליון ולא בהודעה.
מבנה ההזדהות הוא דו שלבי, וזה פרט שחשוב להבין כי הוא מקור לתקלות. המפתחות עצמם לא נשלחים בכל בקשה. במקום זה מתחלפים בהם פעם אחת ומקבלים אישור זמני, וכל שאר הפעולות משתמשות באישור הזה. האישור פג אחרי זמן קצר יחסית.
המשמעות המעשית: תהליך שמפיק אישור פעם אחת ומנסה להשתמש בו למחרת ייכשל. תהליך תקין מבקש אישור טרי בתחילת כל ריצה, או שומר אותו לזמן קצר ומחדש כשצריך. זו התקלה מספר אחת שאנחנו רואים אצל מי שבנה לבד, והיא מתבטאת באוטומציה שעבדה שבוע ואז הפסיקה בלי סיבה נראית לעין.
מה אפשר לעשות דרך הממשק
| תחום | פעולות נפוצות | לאיזה תהליך זה משרת |
|---|---|---|
| לקוחות | יצירה, חיפוש, עדכון פרטים | פתיחת כרטיס אוטומטית ללקוח חדש מה-CRM |
| מסמכים | הפקה, שליפה, שליחה במייל | חשבונית או קבלה שנוצרת עם סגירת עסקה |
| תשלומים | רישום תקבול, קישור למסמך | התאמה בין תשלום שנקלט לחשבונית פתוחה |
| שליפות | חיפוש מסמכים לפי תקופה וסטטוס | דוח יומי, בקרה, התאמות מול מערכת אחרת |
שימו לב שסוגי המסמכים במערכת מזוהים בקודים מספריים - חשבונית מס, חשבונית מס קבלה, קבלה, זיכוי, הצעת מחיר וכן הלאה. את הרשימה המדויקת יש לקחת מהתיעוד ולא מהזיכרון, כי בחירה בסוג הלא נכון מייצרת מסמך תקין לחלוטין מבחינת המערכת ושגוי לחלוטין מבחינה חשבונאית. זו טעות שקטה במיוחד.
התהליך שרוב העסקים בונים
התרחיש הנפוץ ביותר הוא שרשרת קצרה שמתחילה בסגירת עסקה ומסתיימת בחשבונית אצל הלקוח. כך הוא נראה כשהוא בנוי נכון.
- 1עסקה מסומנת כסגורה במערכת המקור - CRM, טופס, חנות מקוונת או מערכת תשלומים.
- 2האוטומציה בודקת שיש את כל מה שנדרש: שם מלא, מספר עוסק או תעודת זהות, כתובת מייל תקינה, סכום ותיאור. אם חסר משהו, נפתחת משימה ולא מופק מסמך.
- 3מחפשים את הלקוח במורנינג לפי מזהה יציב. אם אינו קיים, נוצר כרטיס חדש.
- 4מופק המסמך בסוג הנכון, עם השורות והסכומים.
- 5המסמך נשלח ללקוח, ומספר המסמך והקישור אליו נרשמים חזרה במערכת המקור.
- 6כשל בכל אחד מהשלבים מייצר התראה לאדם, ולא נעלם בשקט.
שלב שתיים הוא זה שמפריד בין אוטומציה שעובדת לאוטומציה שמייצרת עבודה. עסקים שמדלגים עליו מגלים אחרי חודש שיש להם עשרות חשבוניות ללקוחות בלי מספר עוסק או עם כתובת מייל שגויה, וכל אחת מהן דורשת זיכוי והפקה מחדש.
באוטומציה של חשבוניות, אימות לפני ההפקה שווה יותר מכל שאר התהליך. מסמך שלא הופק אפשר לתקן בעריכה. מסמך שהופק דורש זיכוי.
מספר הקצאה - מה שחייבים לדעת
רשות המסים הנהיגה דרישה שלפיה חשבונית מעל סכום מסוים מחייבת קבלת מספר אישור מקוון מהרשות כדי שהלקוח יוכל לנכות בגינה מס תשומות. הסף יורד בהדרגה לאורך השנים, כלומר עסקאות שהיו מתחתיו אשתקד עשויות להיות מעליו השנה. את הסף המדויק שתקף כרגע יש לוודא, ולא להסתמך על מה שנכון היה כשהתהליך נבנה.
מבחינת אוטומציה יש לזה שלוש השלכות מעשיות. ראשית, ההפקה תלויה בשירות חיצוני שאינו בשליטתכם ואינו זמין תמיד. שנית, נדרשת הרשאה מסודרת מול הרשות שמישהו בעסק צריך להסדיר, וזה לא שלב טכני. שלישית, וזה החשוב: תהליך שמניח שהפקה תמיד מצליחה יישבר, וצריך שיהיה לו מסלול ברור לכישלון.
המבנה שאנחנו בונים במקרה כזה: אם ההפקה נכשלה, המסמך לא נשלח ללקוח, נפתחת משימה עם הסיבה, והמערכת מנסה שוב מספר פעמים לאורך היום. עסק שלא בנה את זה מגלה את התקלה כשלקוח מתקשר לשאול איפה החשבונית.
מלכודות שחוזרות בכל פרויקט
- כפילות לקוחות. חיפוש לפי שם מייצר כרטיס חדש לכל שינוי כתיב. יש לזהות לפי מזהה יציב, ולשמור את מזהה הלקוח שהמערכת החזירה במערכת המקור.
- עיגול מע״מ. חישוב מהסכום כולל מע״מ לעומת חישוב מהסכום לפני מע״מ יכול לייצר הפרש של אגורות בין המערכות. מחליטים על שיטה אחת וקובעים אותה בכל מקום.
- כפילות מסמכים. תהליך שרץ פעמיים בגלל ניסיון חוזר יפיק שתי חשבוניות. חייבים מנגנון שמזהה שהעסקה כבר טופלה, לפני ההפקה.
- עסקאות פטורות ולקוחות בחו״ל. שיעור מע״מ שונה הוא לא מקרה קצה נדיר אלא כלל שצריך להיות בתהליך מהיום הראשון.
- סביבה שגויה. מפתחות של בדיקות בייצור, או ההפך. שווה לוודא זאת בכל עלייה לאוויר.
- קצב בקשות. ייבוא היסטורי של אלפי מסמכים אינו זהה להפקה שוטפת, וצריך להריץ אותו במנות ובקצב מבוקר.
מה עם מערכת הנהלת החשבונות
מורנינג היא מערכת להפקת מסמכים, והיא לא מחליפה את הנהלת החשבונות אצל רואה החשבון. השאלה איך המסמכים מגיעים לשם היא חלק מהפרויקט ולא נספח שלו.
אצל עסקים שעובדים מול חשבשבת, המבנה שאנחנו ממליצים עליו הוא הפרדה: המסמך מופק במורנינג, והרישום החשבונאי מועבר לחשבשבת בקליטה מרוכזת. זה נשמע כמו עקיפה והוא בעצם חלוקת תפקידים נכונה - כל מערכת עושה את מה שהיא טובה בו. שווה לסגור את המבנה הזה מול מנהלת החשבונות לפני שבונים, ולא אחרי.
כמה זה עולה
| היקף | מה כלול | טווח |
|---|---|---|
| תהליך בסיסי | לקוח חדש, חשבונית, שליחה, רישום חזרה | ₪6,000-10,000 |
| תהליך מלא | כולל תשלומים, זיכויים, חריגים והתראות | ₪12,000-20,000 |
| חיבור להנהלת חשבונות | קליטה מרוכזת ודוח השוואה | תוספת של ₪6,000-15,000 |
לזה מתווספת עלות שוטפת צנועה של הכלי שהתהליך רץ עליו והניטור, בדרך כלל כמה מאות שקלים בחודש. אם אתם מפיקים עשר חשבוניות בחודש, החישוב לא מסתדר וכדאי להמשיך ידנית. אם אתם מפיקים מאתיים, הוא מסתדר מהר.
איזה מסמך להפיק, ומתי
זו הנקודה שבה אוטומציה של חשבוניות נשברת אצל עסקים בישראל, והיא כמעט תמיד לא טכנית אלא חשבונאית. המערכת יכולה להפיק כל מסמך, אבל רק אתם ורואה החשבון שלכם יודעים איזה מסמך נכון לכל מצב. שווה לסגור את זה לפני שכותבים שורת קוד אחת.
| המצב | המסמך הנכון | מה קורה בפועל |
|---|---|---|
| הלקוח שילם במעמד ההזמנה | חשבונית מס קבלה | מסמך אחד שסוגר הכול |
| הזמנה עכשיו, תשלום בהמשך | חשבונית מס, ואז קבלה | שני מסמכים בשני מועדים |
| רוצים לתת הצעה בלבד | הצעת מחיר | לא נספר כהכנסה |
| הלקוח שילם מראש על שירות עתידי | חשבונית עסקה, ואז חשבונית מס | עיתוי ההכרה בהכנסה משתנה |
| צריך לבטל מסמך שהופק | חשבונית זיכוי | אין מחיקה, רק זיכוי |
השורה האחרונה חשובה במיוחד לאוטומציה. מסמך שהופק לא נמחק, ולכן באג שמפיק מאה חשבוניות שגויות מייצר מאה חשבוניות זיכוי ושיחה לא נעימה עם רואה החשבון. זו הסיבה שאנחנו תמיד מריצים את השלב הזה במצב בדיקה מול סביבת דמו לפני שמחברים לחשבון האמיתי.
מלכודות מע"מ שחוזרות שוב ושוב
- לקוח תושב חוץ: עסקאות מסוימות פטורות או בשיעור אפס, והמערכת חייבת לדעת לזהות את זה לפי סוג הלקוח ולא לפי ניחוש.
- אילת: אזור סחר חופשי עם כללים משלו. עסק שמוכר לשם ולא הגדיר את זה מפיק מסמכים שגויים בלי לדעת.
- עסק פטור מול עוסק מורשה: משנה לגמרי איזה מסמך מותר להפיק ומה מותר לגבות.
- שינוי שיעור המע"מ: קרה בישראל ויקרה שוב. אם השיעור מקודד קשיח בתהליך במקום להגיע מהמערכת, כל המסמכים ישתבשו ביום השינוי.
הנקודה האחרונה היא זו שתופסת עסקים לא מוכנים. הכלל שלנו פשוט: שיעור המע"מ אף פעם לא נכתב בתוך התהליך, הוא תמיד מגיע מספק החשבוניות עצמו, שמתעדכן ממילא.
מה לבנות ומה להשאיר ידני
לא כל מסמך שווה אוטומציה. החלוקה שעובדת ברוב העסקים היא לפי כמות וודאות: מה שחוזר הרבה ויש לו כללים ברורים רץ לבד, ומה שנדיר או דורש שיקול דעת נשאר אצל אדם עם כל המידע מוכן לידו.
- 1רץ לבד: חיובים חוזרים, הזמנות מהאתר, מנויים חודשיים. אותו מבנה בכל פעם, אפס הפתעות.
- 2רץ לבד עם התראה: עסקאות בסכום גבוה. המסמך מופק, אבל נשלחת התראה כדי שמישהו יראה אותה באותו יום.
- 3תור אישור: לקוחות חדשים, מטבע זר, כל מה שלא תואם לתבנית מוכרת. אדם מאשר בלחיצה.
- 4ידני לחלוטין: זיכויים, הסדרי תשלום חריגים, כל דבר שמערב משא ומתן.
החלוקה הזו נשמעת שמרנית, והיא כזו בכוונה. בעסק ממוצע היא עדיין מעבירה שמונים עד תשעים אחוז מהמסמכים לריצה אוטומטית, ומשאירה את העשירייה שדורשת מחשבה לבן אדם. זה בדיוק היחס שאנחנו מחפשים.
השורה התחתונה
מורנינג היא אחת המערכות הישראליות שהכי כדאי לבנות עליהן אוטומציה, והחלק הטכני בה הוא הקל. מה שקובע את איכות התוצאה הוא האימות שלפני ההפקה, הטיפול בכישלונות, והחשיבה על מה שקורה כשמשהו יוצא שגוי.
אם אתם בוחרים עכשיו מערכת להפקת חשבוניות ואוטומציה חשובה לכם, זו נקודה ששווה לשקול בבחירה. ההפרש בקלות החיבור בין מערכת פתוחה למערכת סגורה גדול בהרבה מההפרש בדמי המנוי.
שאלות שחוזרות
- האם הממשק זמין בכל חבילה של מורנינג?
- הגישה לממשק תלויה במסלול, ולכן זו הבדיקה הראשונה שכדאי לעשות מול התמיכה לפני שמתכננים פרויקט. במסלולים שכוללים אותה מפיקים מפתחות מתוך אזור ההגדרות של החשבון, ומשם ההקמה קצרה. אם המסלול שלכם לא כולל, שדרוג קטן זול בהרבה מכל פתרון עוקף.
- אפשר לבדוק בלי להפיק חשבוניות אמיתיות?
- כן, ויש סביבת בדיקות נפרדת עם מפתחות משלה. זה יתרון משמעותי של המערכת ואנחנו משתמשים בו תמיד. חשוב לוודא לפני עלייה לאוויר שהמערכת מצביעה על הסביבה הנכונה - פרויקט שהפיק מסמכים בסביבת בדיקות במקום בייצור מגלה את זה רק כשמישהו מחפש את החשבונית ולא מוצא.
- מה זה מספר הקצאה ולמה זה חשוב לאוטומציה?
- זו דרישה של רשות המסים שלפיה חשבונית מעל סכום מסוים מחייבת קבלת מספר אישור מקוון מהרשות כדי שתהיה ניתנת לניכוי אצל המקבל. הסכום יורד בהדרגה לאורך השנים, ולכן צריך לוודא מהו הסף העדכני. המשמעות לאוטומציה היא שהפקה עלולה להיכשל מסיבה שאינה קשורה אליכם, וצריך לטפל בזה במקום להתעלם.
- מה קורה אם האוטומציה הפיקה חשבונית שגויה?
- מסמך חשבונאי שהופק לא נמחק. מבטלים אותו במסמך זיכוי ומפיקים חדש. לכן אנחנו מציבים את ההפקה כשלב האחרון בתהליך ואחרי כל האימותים, ובחודש הראשון לרוב מוסיפים אישור אנושי. אחרי שרואים יציבות על מקרים אמיתיים, מסירים אותו.
- כמה זמן לוקח לחבר את זה?
- התהליך הבסיסי - לקוח חדש נכנס, נוצר כרטיס, מופקת חשבונית ונשלחת - הוא לרוב ימים ספורים. מה שמאריך הוא כל מה שסביב: טיפול במקרים חריגים, החלטה מה קורה כשחסרים פרטים, וסנכרון חזרה למערכת שממנה הגיעה העסקה. ההפרש בין שלושה ימים לשלושה שבועות הוא כמעט תמיד מספר החריגים.
- האם המערכת יכולה להודיע לנו כשמתקבל תשלום?
- קיימת אפשרות להגדיר קבלת עדכונים על אירועים בחשבון, וזמינותה המדויקת תלויה במסלול ובהגדרות - כדאי לבדוק מול התמיכה. בפועל אנחנו לרוב משלבים: מקבלים עדכון כשאפשר, ומריצים במקביל בדיקה מחזורית קצרה כרשת ביטחון, כדי שתשלום שהודעתו לא הגיעה לא ייעלם.
- אפשר לבדוק את החיבור בלי להפיק מסמכים אמיתיים?
- כן, וזה חובה. לספקי החשבוניות המרכזיים יש סביבת בדיקה נפרדת, או לכל הפחות אפשרות להפיק טיוטות. אנחנו מריצים שם מחזור מלא כולל מקרי קצה, ורק כשהכול נקי מחברים למפתח של החשבון האמיתי.
- מה קורה אם ספק החשבוניות לא זמין בדיוק כשנסגרה עסקה?
- המערכת לא מוותרת ולא מפיקה פעמיים. הבקשה נכנסת לתור עם מזהה ייחודי, מנסה שוב לפי לוח זמנים, ואם היא נכשלת שוב יוצאת התראה. המזהה הייחודי הוא מה שמונע מהניסיון החוזר לייצר מסמך כפול.