Last updated on ספטמבר 9th, 2026 at 06:31 pm
העיקרון המרכזי: מי המקור האמיתי לכל סוג מידע
השאלה שהכי כדאי לענות עליה לפני שמתחילים לבנות אינטגרציה בין מערכת Vibe Coding לבק-אופיס היא לא "איך מסנכרנים", אלא "מי המקור האמיתי". לכל סוג נתון צריך להיות מקום אחד שבו הוא נכון באמת, וכל מקום אחר רק מציג או מעדכן אותו, לא מחזיק גרסה עצמאית משלו. כשמפרים את העיקרון הזה, שני המקומות מתחילים "לחשוב" אחרת על אותו נתון, וזה בדיוק הרגע שבו מתחילות תקלות שקשה לאתר.
מה תמיד צריך להישאר בבק-אופיס
יש קטגוריות מידע שצריכות להישאר תחת ניהול Linet ולא להיות מנוהלות באופן עצמאי במערכת שלכם:
- מלאי בפועל, הכמות האמיתית הזמינה למכירה
- מסמכים חשבונאיים, חשבוניות, קבלות, תעודות משלוח, לרבות המספור הרשמי שלהם
- נתוני הנהלת חשבונות, כל מה שקשור לדיווח ולרשויות המס
המערכת שלכם יכולה להציג את המידע הזה ללקוח, אבל לא ליצור גרסה מקבילה משלו. חשבונית, למשל, חייבת להיווצר דרך Linet ולקבל ממנה מספר רשמי, לא להיווצר במערכת שלכם ולהישלח אחר כך "להתעדכן" שם.
מה כדאי לנהל במערכת ה-Vibe Coding עצמה
לעומת זאת, יש נתונים שדווקא עדיף שיישארו אצלכם ולא יעמיסו על הבק-אופיס:
- מצב הסל וההזמנה בתהליך, לפני שהיא הופכת לעסקה סגורה
- העדפות תצוגה וחוויית משתמש, כמו שפה, מטבע תצוגה או פילטרים שנבחרו
- הסכמות שיווקיות, כמו רישום לניוזלטר, שלרוב לא רלוונטיות לניהול הכספי של העסק
- תוכן קטלוג עשיר, תמונות, תיאורים שיווקיים ותגיות, גם אם המחיר והכמות עצמם מגיעים מ-Linet
הרעיון הוא לחלק תפקידים: Linet מנהלת את מה שחייב להיות מדויק ורשמי, והמערכת שלכם מנהלת את מה שקשור לחוויית המשתמש ולא צריך לעבור דרך מערכת הנהלת חשבונות.
סנכרון דו-כיווני מול חד-כיווני
לא כל נתון זז באותו כיוון. מלאי, לדוגמה, הוא בדרך כלל דו-כיווני במובן הזה: המערכת שלכם שואלת את המצב הנוכחי, ואז שולחת עדכון כשמתבצעת מכירה. לעומת זאת, מספר חשבונית או מספר תעודת משלוח הם חד-כיווניים באופיים, הם נוצרים אצל Linet ורק זורמים אליכם, לעולם לא הפוך. כשמתכננים את הארכיטקטורה, כדאי לסמן מראש לכל סוג נתון לאיזה כיוון הוא זז, כדי לא לנסות בטעות "לעדכן" משהו שאמור להיות קבוע.
הסכנה בניהול כפול של אותו מידע
הטעות הנפוצה ביותר היא ניסיון לשמור עותק מקומי "לשם נוחות" של נתון שכבר מנוהל ב-Linet, כמו מלאי או פרטי לקוח, ולעדכן את שתי הגרסאות בנפרד. בהתחלה זה עובד, אבל בכל תקלת רשת, כל קריאת API שנכשלה בשקט, שני המקומות מתחילים להיפרד. הפתרון הנכון הוא תמיד לשאול את Linet ברגע האמת, ולא לסמוך על עותק שנשמר קודם, גם אם זה אומר קריאת API נוספת.
| סוג מידע | איפה המקור האמיתי | כיוון הסנכרון |
|---|---|---|
| מלאי בפועל | Linet | דו-כיווני |
| מסמכים חשבונאיים | Linet | חד-כיווני, מ-Linet אליכם |
| פרטי לקוח בסיסיים | Linet | דו-כיווני |
| סל קניות פעיל | מערכת Vibe Coding | לא רלוונטי, פנימי |
| תוכן שיווקי וקטלוג | מערכת Vibe Coding | לא רלוונטי, פנימי |
| הסכמות שיווקיות | מערכת Vibe Coding | לא רלוונטי, פנימי |
שאלות נפוצות
למה לא פשוט לשמור עותק של המלאי אצלי כדי לחסוך קריאות API?
כי עותק מקומי תמיד עלול להתיישן. ברגע שיש הזמנה נוספת שלא עברה דרככם, למשל מכירה בקופה הפיזית, העותק שלכם כבר לא משקף את המציאות.
האם אפשר לתת למערכת ה-Vibe Coding ליצור מספרי חשבונית משלה?
לא מומלץ. מספור חשבוניות חייב לצאת ממערכת אחת רציפה כדי לעמוד בדרישות החשבונאיות, ולכן זה תפקיד של Linet ולא של מערכת חיצונית.
מה קורה עם נתוני לקוח שהוזנו גם באתר וגם ב-Linet בנפרד?
זה בדיוק המצב שרוצים למנוע. הפתרון הוא לבדוק תמיד מול Linet לפני יצירת רשומת לקוח חדשה, ולא לתת למערכת שלכם ליצור לקוחות באופן עצמאי.
האם תוכן שיווקי כמו תמונות מוצר צריך לעבור דרך Linet בכלל?
לא, Linet מנהלת נתוני מוצר בסיסיים כמו מחיר וכמות, אבל תוכן עשיר כמו תמונות ותיאורים שיווקיים הוא בדרך כלל תפקיד של המערכת שלכם.
מה עדיף, לסנכרן מלאי בכל טעינת עמוד או בזמן קבוע?
בשלב הוספה לסל אפשר להסתפק בבדיקה מתוזמנת, אבל ממש לפני סגירת ההזמנה תמיד כדאי לבצע בדיקת מלאי אחרונה ועדכנית מול Linet.
