מרכז החלטות

דף ההכרעות: למה התקבלו החלטות מסוימות, אילו עקרונות מחייבים את הפיתוח, ומהם כללי העבודה

v11.5.0
DevFromC2O v0.5.0 — דף נחיתה + סילבוס מלא
שיחה #139 — 29/04/2026
דף זה מרכז את כל ההחלטות שמנהל המערכת חייב לאשר לפני פיתוח מודולי CRM, תשלומים, SaaS וסנכרון.
עדכון החלטה אסטרטגית: לצד החלטות HubSpot/Finance/VIP, הוגדר עקרון חדש: לא מסמנים flow כ'הושלם' רק כי הקוד קיים. כל מסע חייב לעבור גם אימות התנהגותי בפועל לפני שהוא נסגר בדפי הפיתוח.
HubSpot כמקור אמת
CRM
אילו ישויות נשלטות ב-HubSpot ואילו נשמרות מקומית לצורכי תפעול בלבד
מהו כיוון הסנכרון לכל ישות: HubSpot → מערכת, מערכת → HubSpot, או דו-כיווני
מהו כלל ההכרעה בהתנגשות: HubSpot מנצח, עדכון אחרון מנצח, או לפי שדה

פלט מחייב:

מפת מקור אמת + טבלת כיווני סנכרון

ייחוס הכנסות ותשלומים
Finance
אילו שערי תשלום הם חלק מההשקה המיידית: Tranzila, PayPal, PayPlus או אחרים
לפי איזה מזהה מתאימים בין transaction_reference, רכישה, payment_provider, לקוח ו-Contact ב-HubSpot — מיושם ב-importTransactions function
מה נחשב פער בדוח התאמה: סכום, מטבע, סטטוס, לקוח חסר, רכישה כפולה, ספק תשלום חסר או מזהה טרנזקציה חסר
ברגע שרכישה מסומנת כ-matched — מופקת חשבונית ירוקה אוטומטית ונשלחת ללקוח דרך issueGreenInvoice function

פלט מחייב:

כללי התאמה, Snapshot חי ודוח reconciliation מוסכם

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

פלט מחייב:

מטריצת ספקים + מדיניות הפעלה פנימית/חיצונית

בקרת החלטות אנושית
HITL
לפני כל חיבור חדש יש אישור מנהל על ספק, scope, שדות וסיכוני השפעה
לפני מעבר לפרודקשן יש אישור אנושי על דוחות התאמה, כשלי סנכרון ונתוני אמת
כל שינוי ארכיטקטוני חייב להתעדכן במדריך מפתח, בתוכנית הפיתוח ובדף התיעוד

פלט מחייב:

שערי אישור מחייבים לפני Build, Sync ו-Go-Live

שערי אישור אנושיים

Gate 1 — בחירת מקור אמת

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

Gate 2 — מיפוי נתונים

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

Gate 3 — מדיניות חריגים

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

Gate 4 — אישור השקה

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

ההמלצה הרשמית לפרודקשן
המסלול המהיר ביותר לפרודקשן: HubSpot כמקור אמת ל-CRM.
המערכת המקומית נשארת שכבת תפעול, תצוגה, קאש ולוגים — לא מקור אמת ראשי.
לא בונים עכשיו CRM חדש ולא מחליפים ליבה עסקית לפני עלייה לאוויר.
כדי לאפשר מעבר עתידי חלק, בונים עכשיו שכבת provider abstraction, מיפוי מזהים ולוג סנכרון.
מה חייבים לבצע עכשיו כדי לשמור על גמישות עתידית
מודל נתונים קנוני פנימי שאינו תלוי בשמות שדות של HubSpot
טבלת מיפוי מזהים: local_id / hubspot_id / payment_provider_id
שכבת מדיניות למקור אמת שאפשר להחליף בעתיד בלי לשבור UI
לוג סנכרון ודוח reconciliation כבסיס למעבר רציף בין ארכיטקטורות
סדר פיתוח מומלץ
1

להגדיר מטריצת ספקים ומקור אמת לכל תחום

2

להקים דף ניהול שירותי SaaS והרשאות חיבור

3

להקים דשבורד סנכרון HubSpot עם לוגים והפעלה ידנית

4

להטמיע מודול התאמת תשלומים וחיובים מול אנשי קשר

5

להפעיל דוחות reconciliation אוטומטיים עם אישור מנהל