מההוצאה הראשונה לחריגה ברורה: בניית מערכת תקציב עם Lovable

1התוצר שתבנו: מסך ניהולי שאפשר לבדוק

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

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

2דרישות מקדימות

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

3שלב 1: הגדירו תכולה ותנאי קבלה לפני הבנייה

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

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

עברו על התוכנית וחפשו הנחות שלא ביקשתם: האם נוספו אישורים? האם נבחר מטבע? האם מנהל מחלקה יכול לערוך תקציב? סגרו את ההחלטות לפני היישום. לפי התיעוד שסופק, Build mode מיועד ליישום ולבדיקת התוצאה; עברו אליו רק לאחר שהיקף השינוי ברור.

4שלב 2: בנו מודל נתונים בלי ערבוב בין תכנון לביצוע

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

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

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

5שלב 3: הגדירו שמירה וטענו נתוני דמה

החליטו כיצד הנתונים יישמרו לפני בניית הטפסים. התיעוד שסופק על חיבור Supabase מתאר גם את ה־backend המובנה של Lovable ואת יכולות מסד הנתונים וההזדהות שלו. לצורך התרגיל בקשו להשתמש בתשתית המובנית, ללא חיבור חיצוני. אם נדרשים אישור הפעלה או החלטת עלות בסביבתכם, בדקו אותם לפני ההמשך; המדריך אינו מניח שימוש ללא עלות.

צרו במחלקת דמה סעיף הדרכות עם תקציב של 10,000 יחידות מטבע. הוסיפו הוצאות של 4,000 ושל 3,000, עם מזהי מסמך DEMO-A ו־DEMO-B. צרו גם סעיף תוכנות עם תקציב של 5,000 וללא הוצאות. שייכו את הכול לחודש הבדיקה שבחרתם. לאחר השמירה רעננו את המסך וודאו שהרשומות נשארו.

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

6שלב 4: בנו טופס הוצאות שמונע שגיאות מוגדרות

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

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

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

7שלב 5: הגדירו נוסחאות ושמות שאינם משתמעים לשתי פנים

• ביצוע: סכום ההוצאות שנשמרו עבור רשומת התקציב.
• יתרה תקציבית: תקציב מתוכנן פחות ביצוע; ערך שלילי מציין חריגה.
• סכום חריגה: ביצוע פחות תקציב, אם התוצאה חיובית; אחרת אפס.
• שיעור ניצול: ביצוע חלקי תקציב, כפול 100, רק כאשר התקציב גדול מאפס.
• תקציב אפס: הציגו שיעור ניצול כ״לא ניתן לחישוב״; אם קיימת הוצאה, סמנו ״הוצאה ללא תקציב״.

בנתוני הדמה של סעיף ההדרכות, הביצוע הצפוי הוא 7,000, היתרה 3,000 ושיעור הניצול 70%. לאחר הוספת הוצאה נוספת של 4,000 עם המזהה DEMO-C, הביצוע צריך להיות 11,000, היתרה מינוס 1,000, החריגה 1,000 ושיעור הניצול 110%. אלה תוצאות הבדיקה שעליהן תתבססו, ולא הערכות.

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

8שלב 6: הפכו את ההשוואה לתצוגת חריגות לבירור

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

הציגו בנפרד יתרה כוללת וסכום החריגות בסעיפים. בתרחיש הדמה, לאחר ההוצאה הנוספת, התקציב הכולל הוא 15,000 והביצוע 11,000: קיימת יתרה כוללת של 4,000, אך סעיף ההדרכות עדיין חורג ב־1,000. אל תאפשרו ליתרה בסעיף אחר להעלים את החריגה מהתצוגה.

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

9שלב 7: בדקו הרשאות צפייה בחשבונות דמה נפרדים

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

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

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

10שלב 8: הריצו תרחישי קבלה ותעדו תוצאות

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

• ללא הוצאות: הביצוע אפס והיתרה שווה לתקציב.
• הוצאות הדמה: מתקבלים הסכומים ושיעורי הניצול שהוגדרו בשלב החישובים.
• כפילות: שליחה חוזרת של DEMO-A, לרבות עם רווחים מסביבו, נדחית בלי לשנות את הביצוע.
• שליחה כפולה: לחיצה חוזרת ושמירה חוזרת אינן יוצרות רשומה נוספת.
• תקציב אפס עם הוצאה: מוצגת חריגה ללא חלוקה באפס.
• סינון: סיכומי המסך מתאימים לרשומות שבתחום הסינון.
• הרשאות: מנהלי מחלקה אינם רואים נתונים או סכומים של מחלקה אחרת.

11טעויות נפוצות שכדאי לעצור בזמן

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

12צ'קליסט לפני ההדגמה

• גבולות האב־טיפוס וסימון נתוני הדמה ברורים.
• רשומות התקציב ייחודיות וההוצאות מקושרות לתקציב מתאים.
• הנתונים נשמרים לאחר רענון.
• החישובים תואמים לתוצאות הבדיקה הידניות.
• כפילויות וקלט לא תקין נדחים בלי לשנות סכומים.
• חריגה בסעיף נשארת גלויה גם כשיש יתרה כוללת.
• הרשאות הצפייה נבדקו בחשבונות נפרדים ותועדו פערים.
• אין חיבור למערכת פיננסית ואין נתוני אמת.

13כאן עוצרים: מאב־טיפוס שימושי למערכת ארגונית

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

רוצים לבחון את התהליך מול צורכי המחלקות והכספים? אפשר לפנות ל־Operator AI לייעוץ AI להגדרת התכולה ותנאי הקבלה, או לסדנה מעשית שבה הצוות יבנה ויבדוק אב־טיפוס ב־Lovable על נתוני דמה. המטרה היא לבחון תוצר ניהולי ברור, לזהות פערים ולהחליט על ההמשך לפני מעבר לנתוני אמת.