· 4 דקות קריאה
בעידן ה-AI, קוד פתוח הפסיק להיות עמדה אידאולוגית — והפך ליתרון הנדסי
אני בונה כרגע את שכבת הלוקליזציה הישראלית של ERPNext — מספרי הקצאה מול רשות המסים, ניכוי מס במקור, דיווחי PCN874 ומס״ב. כמו כל מי שמפתח או מטמיע תוכנה היום, חלק גדול מהעבודה הזו נעשה לצד סוכני AI.
תוך כדי עבודה נתקלתי בהבדל דרמטי. הוא לא אידאולוגי, אלא תפעולי לחלוטין: כשמערכת ה-ERP היא בקוד פתוח, ה-AI מבין מה המערכת באמת עושה — ולא רק מה היא מציגה על המסך.
האתגר האמיתי בהטמעה: עלות השינוי
כתבתי כאן בעבר שהתכונה הכי חשובה במערכת ERP היא עלות השינוי. זו אותה נקודה, מזווית אחרת.
כשמכניסים ERP לארגון, החלק שבאמת צורך זמן וכסף אינו הפיצ׳רים שמגיעים "Out of the box", אלא ההתאמה (Customization) לתהליכי העבודה האמיתיים של העסק. איך נראית הזמנת רכש, מה קורה כשמגיעה סחורה חלקית, ואיזה שדה חייב להיות מלא לפני הפקת חשבונית.
היום כולנו נעזרים ב-AI כדי להאיץ את הפיתוח וההתאמות. אבל מול מערכת סגורה, ה-AI רואה רק את השכבה העליונה — המסכים והתיעוד הציבורי. הוא מנחש, מנסה ומקווה שלא תקפוץ שגיאה. הבעיה היא ש"לא קפצה שגיאה" ממש לא אומר שהלוגיקה העסקית נכונה.
המקרה של ניכוי במקור: כשה-AI שכנע אותי לטעות
זה נשמע מופשט, אז הנה מקרה אמיתי מהעבודה על ניכוי במקור.
ל-ERPNext יש מנוע מובנה לחישוב ניכוי מס במקור. כשניסיתי להבין איך להתאים אותו לדין הישראלי, התייעצתי עם שני מודלי AI שונים במקביל:
- מודל אחד הציע לעקוף את המנוע המובנה ולכתוב לוגיקה ייעודית.
- מודל שני טען בנחישות שזו טעות: "למערכת יש מנוע מובנה. לכתוב לוגיקה עוקפת זו שגיאה הנדסית שתמנע מכם לשדרג את המערכת בעתיד".
הטיעון השני נשמע לי הגיוני, מקצועי ומשכנע מאוד. קיבלתי אותו והחלטתי להסתמך על המנוע המובנה.
בפועל, הרצתי תשלום שסגר חשבונית ספק. התשלום נשמר בהצלחה, המסך נראה תקין לחלוטין ולא קפצה שום שגיאה. מבחינת המסך והמערכת — הכול עבר בשלום.
רק צלילה ישירה לקוד המקור (tax_withholding_entry.py) חשפה את הפער: המנוע המובנה סוכם סכומים רק עבור מסמכים מסוג Sales Order ו-Purchase Order. חשבונית ספק (Purchase Invoice) פשוט לא מופיעה ברשימה הזו (hooks.py). כשתשלום סוגר חשבונית ספק, המנוע מחשב סכום חייב במס של אפס — ויוצא בלי לבצע ניכוי ובלי להתריע.
וזה לב העניין: זה לא באג. ERPNext מנכה מס על ההזמנה או על המקדמה — המודל שעבורו המערכת נבנתה. החוק הישראלי מנכה ברגע התשלום. ההנחה הזו לא הופיעה בשום מסך ולא הייתה כתובה בשום תיעוד. היא התחבאה בתוך תנאי if בודד בקוד.
הקוד הוכיח שהמודל הראשון צדק, ואני טעיתי.
Sales Order ו-Purchase Order בלבד.זה היתרון האמיתי: קוד פתוח לא הופך את ה-AI ל"חכם יותר" — הוא נותן לו ולנו מקור אמת יחיד לאמת מולו טיעונים משכנעים. קוד פתוח לא עזר לי לתקן מהר יותר, אלא שבלי הקוד — לא הייתי יודע בכלל שיש מה לתקן.
איפה זה לא קסם
- קוד פתוח לא הופך פיתוח לנטול שגיאות: עדיין חייבים בדיקות אוטומטיות (Automated Tests) שרצות על כל התהליך.
- גישה לקוד היא לא היתר לדרוס אותו: התאמות עושים בשכבה נפרדת (Custom Apps) דרך נקודות התממשקות (Hooks), ולא על הליבה עצמה — כדי לא לשבור שדרוגים.
- זה לא מחליף שותף עסקי: קוד פתוח מוריד את הסיכון של תלות בספק, אך לא מבטל את הצורך במישהו שמבין איך העסק שלכם עובד.
השאלה שאתם חייבים לשאול לפני שחותמים
בפעם הבאה שספק ERP סגור מנסה למכור לכם את "יכולות ה-AI" של המערכת שלו, תשאלו אותו שאלה אחת פשוטה:
"האם ל-AI שלכם יש גישה מלאה לקוד המקור האמיתי, או שהוא פשוט קורא את מדריך המשתמש?"
שאלות נפוצות
מה היתרון הפרקטי של קוד פתוח עבורי כלקוח קצה?
היתרון מתורגם לשני דברים קריטיים: אמינות ומהירות. כשהמטמיעים והמפתחים משתמשים ב-AI שמסוגל לקרוא ולבחון את הקוד האמיתי, הם לא מבזבזים זמן על ניסוי וטעייה. התוצאה היא פיתוחים מותאמים אישית שעובדים נכון, אינטגרציות יציבות שלא נשברות בעדכונים, וזמן הגעה לשוק (Time to Market) מהיר משמעותית בהשוואה למערכות סגורות.
האם כל מערכת ERP בענן נהנית מהיתרון הזה?
לא. ענן הוא מודל האחסון, לא מודל הרישוי. רוב מערכות ה-ERP בענן הן קופסאות שחורות סגורות, והעובדה שמערכת מתארחת בענן לא אומרת דבר על השאלה אם אפשר לקרוא את הקוד שרץ בה. אלה שני דברים נפרדים לגמרי.
פורסם ב-22/08/2026 מאת נאור לפיד, ServOS. הפוסט מתאר ניסיון אישי ומקצועי ואינו ייעוץ משפטי או מיסויי; שמות מסחריים שייכים לבעליהם.