מילון מונחים — עברית ואנגלית

הפגישה נערכה בעברית. הלקוח אמר “פרויקטים”. אתם כתבתם Projects בקוד וקיבלתם Object not found. הטבלה נקראת Sales.

זה לא באג — זה מבנה. במוצר הזה מתקיימות שלוש שכבות שמות בו‑זמנית, ורק אחת מהן היא מה שה‑API רואה.

שלוש שכבות השמות

#	השכבה	מה בה	האם ה‑API רואה אותה
1	שמות סכימה	טבלאות ושדות באנגלית CamelCase — Accounts, SaleStatusId	כן. זו השכבה היחידה שקיימת מבחינת הקוד
2	תוויות שדה בעברית	תרגום לכל שדה, מוצג בטפסים. יושב בטבלת _Dictionary	לא. חוזר כשדה dictionary בתשובת Get-Schema של ה‑MCP (לא ב‑GET /parse/schemas), כמידע בלבד
3	מילון המונחים (מילון מונחים)	מפה עברית→עברית ברמת הישות: “מכירה”→“פרויקט”. מוגדרת ב‑Set-Terminology-Dictionary ומוחלת על דפים ב‑Replace-Terms	לא. שכבת תצוגה בלבד

הכלל שלא משתנה

שינוי שם הוא קוסמטי. שמות טבלאות, שמות שדות, targetClass ושמות תפקידים (role:Sales) לעולם אינם משתנים — גם כשהלקוח שינה כל מילה בממשק. כל קריאת API, כל טריגר וכל דוח ממשיכים לדבר אנגלית.

טבלת התרגום — ישויות

עברית (ברירת המחדל בממשק)	English	הטבלה בבסיס הנתונים	שדות שמזהים אותה	משתנה אצל לקוחות
לקוחות / חשבונות	Accounts / Customers	Accounts עם IsAccount:true	Name, Email, PhoneNumber, OwnerId	כן — משתתפים, מבוטחים, תלמידים
לידים	Leads	Accounts עם IsAccount:false	LeadStatusId, LeadOwnerId, LeadSourceId	לפעמים
מכירות	Sales	Sales	Name, Total, AccountId, SaleStatusId	כן — הישות המשתנה ביותר: פרויקטים, עסקאות, תיקים
פניות / קריאות שירות	Cases / Tickets	Cases	Name, Number, StatusId, PriorityId	כן — קריאות, בקשות
משימות	Tasks	Tasks	Name, Date, StatusId, OwnerId	נדיר
פעילויות (יומן)	Activities	Activities	Name, StartTime, EndTime, Location	נדיר
אנשי קשר	Contacts	Contacts	FirstName, LastName, AccountId	נדיר
מוצרים	Products	Products	Name, Price, Active	לפעמים — שירותים, קורסים
שורות מכירה	Sale line items	SaleRows	SaleId, ProductId, Quantity, Total	—
הצעות מחיר	Price Quotes	PriceQuotes	Number, AccountId, SaleId, TemplateId	—
חשבוניות / מסמכים חשבונאיים	Invoices / accounting docs	AccountingHeaders (+AccountingInvoiceLines)	DocumentDate, TotalSum, VatValue, DocTypeId	—
מנויים / הוראות קבע / ריטיינרים	Retainers / subscriptions	Retainers	NextChargeDate, ChargesLimit, TotalSum	—
שיחות (צ’אט)	Conversations	Conversations (+ConversationMessages)	Identity, ChannelId, StatusId	—
ערוצים	Channels	Channels	Identity — לא objectId — לשליחת WhatsApp	—
קמפיינים	Campaigns	Campaigns	Type, EmailContent, CampaignStatus	—
הערות	Notes	Notes	Name, Comment, File	נדיר
משתמשים	Users	_User	username, email, name, status (active ו‑isPortalUser נוצרים רק כשכותבים אליהם)	—
תפקידים	Roles	_Role	name — תמיד באנגלית	לעולם לא

הליד יושב ב‑Accounts, לא בטבלה משלו

זו נקודת המעידה הנפוצה ביותר. ליד ולקוח הם אותה שורה באותה טבלה; ההבדל הוא ערך של שדה בוליאני יחיד. ספירת “כמה לקוחות יש” מחייבת where={"IsAccount":true} — בלעדיו סופרים גם את הלידים. בחלק מהמערכות תמצאו בסכימה גם מחלקה בשם Leads — בטננט הדמו היא קיימת עם FirstName, LastName, Email, LandingPage, Referer ובסך הכול 4 שורות. זה שריד של מנגנון קליטה ישן ולא זרימת הלידים של המוצר — אל תכתבו אליה ואל תשלפו ממנה לידים; getlead ומסכי הלידים עובדים על Accounts.

טבלת התרגום — מונחי פלטפורמה

מונח (EN)	עברית	מה זה
Pointer	שדה מצביע / פוינטר	שדה שמצביע לשורה בטבלה אחרת
Trigger	טריגר	אוטומציה בצד שרת על שינוי נתונים או לפי לוח זמנים
Form Rule	חוק טופס	התנהגות שדה בצד לקוח, דקלרטיבית, בלי JS
CLP — Class‑Level Permissions	הרשאות טבלה	הרשאות לכל טבלה × תפקיד: Find/Get/Create/Update/Delete/addField
Advanced Permissions	הרשאות מתקדמות	סינון ברמת שורה לפי ערכי שדות
ACL	—	הרשאות ברמת רשומה בודדת; במוצר לרוב ריק
Role	תפקיד / רול	קבוצת משתמשים נושאת הרשאות; נכתב role:Name
Package	חבילה	רישיון לכמות מושבים; משתמש בלי חבילה לא יכול להיכנס לממשק («תקלה בשיוך לאפליקצייה») — אבל POST /parse/login כן מנפיק לו Session Token (core-api-13)
Master Key	מפתח מאסטר	סוד לכל מערכת שעוקף כל הרשאה
Session Token	טוקן התחברות	האישור שחוזר מ‑POST /parse/login
Portal user	משתמש פורטל	משתמש חיצוני (isPortalUser) — אינו צורך מושב רישוי
Table View / list page	תצוגת טבלה / דף רשימה	עמוד שמציג את כל הרשומות. שם ברבים (apps/mybusiness/Sales)
Form page / Card page	דף טופס / דף כרטיס	עמוד לרשומה בודדת. שם ביחיד (apps/mybusiness/Sale)
masterPage	דף אב / מאסטר	שלד פריסה שעמודי הבן נטענים לתוכו
Timeline	ציר זמן	יומן שינויי הרשומות — טבלת _Timeline
Report / Dynamic Query	דוח / שאילתה	הגדרת דוח שמורה בטבלת _DynamicQueries
Terminology Dictionary	מילון מונחים	מפת שינוי השמות עברית→עברית
getlead / web2table	קליטת לידים מטופס	פונקציות השרת שיוצרות רשומות מטופס חיצוני (בחומרים ישנים getlead נקראת “web2lead”)
Multi‑select field	שדה בחירה מרובה	מערך Pointer דרך תבנית השם array_<purpose>_Pointer_<Target>
Define Parent	הגדרת אב / שדה תלוי	רשימה נפתחת מסוננת לפי בחירה קודמת
SLA	זמן תקן לטיפול	מנגנון דדליין לפניות

מונחי מודולים

עברית	המודול	נתיב בממשק
ניהול לקוחות	CRM Core	apps/mybusiness/ (הקידומות הן שמות הדפים ב‑Get-Site-Pages; מודול שאינו מותקן במערכת — הדפים שלו פשוט אינם קיימים)
הנהלת חשבונות	MyBooks	apps/mybooks/
קמפיינים	MyCampaigns	apps/mycampaigns/
צ’אט	MyChat	apps/mychat/
מכללה	MyCollege	apps/mycollege/
שעון נוכחות	TimeSheet	apps/timesheet/
דואר נכנס	MyInbox	apps/myinbox/

מסמכים חשבונאיים (MyBooks)

כל סוגי המסמכים יושבים באותה טבלה AccountingHeaders, ומופרדים ב‑DocTypeId:

עברית	English
חשבונית מס	Tax Invoice
חשבונית מס קבלה	Tax Invoice‑Receipt
חשבונית עסקה	Transaction (proforma) Invoice
חשבונית מס זיכוי	Credit Invoice
קבלה	Receipt
תעודת משלוח	Delivery Note
הזמנת עבודה	Work Order

_Dictionary — מאיפה מגיעה התווית בעברית

כשנוצר שדה עם label, הפלטפורמה כותבת שורה לטבלת _Dictionary:

JSON

{ "tblName": "Sales", "field": "OwnerSetDate", "value": "תאריך הגדרת אחראי" }

מאותו רגע, תשובת Get-Schema של ה‑MCP נושאת את התווית בתוך הגדרת השדה (הסכימה של Parse ב‑GET /parse/schemas אינה מחזירה אותה):

JSON

"StatusId": { "type": "Pointer", "targetClass": "AccountStatuses", "dictionary": "סטאטוס" }

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

התווית אינה שם השדה

אל תחפשו שדה בשם “טלפון”. השדה הוא PhoneNumber; “טלפון” היא התווית שמוצגת עליו.

מילון המונחים — למה ה‑CRM של הלקוח מדבר אחרת

מעבר לתוויות השדה, ללקוח יש מפה עברית→עברית ברמת הישות, שמחליפה מונח בכל הממשק. דוגמה מסביבה חיה שבה “מכירה” שונתה ל“פרויקט”:

JSON

{
  "מכירה": "פרויקט",  "מכירות": "פרויקטים",
  "פנייה": "פנייה",   "פניות": "פניות",
  "לקוח": "לקוח",     "לידים": "לידים"
}

מיפוי זהותי ("לקוח": "לקוח") הוא הדרך לומר “לא שונה” — הכתיבה למילון (Set-Terminology-Dictionary) היא החלפה מלאה, לא מיזוג: מונח שלא נשלח חוזר למיפוי הזהות שלו (אומת).

המילון לבדו אינו משנה תפריטים וכותרות דפים קיימים — אחרי Set-Terminology-Dictionary עם “מכירות”→“פרויקטים” התפריט עדיין הציג “מכירות”. ההחלפה בדפים נעשית ב‑Replace-Terms דף‑דף; ראו כלי המינוח.

דוגמאות ורטיקליות אמיתיות: מכירה→פרויקט (חברת פרויקטים) · לקוח→משתתף (עמותה) · פנייה→קריאה (מוקד שירות) · מכירה→תיק (משרד עורכי דין) · לקוח→סטודנט (מכללה).

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

מה לא משתנה בשינוי שם

שכבה	ההתנהגות
שמות טבלאות ושדות	לעולם לא נוגעים בהם
נתיבי עמודים	apps/mybusiness/Sales נשאר, גם כשהכותרת אומרת “פרויקטים”
שמות תפקידים (role:Sales)	אסור לשנות — הם המפתח המילולי בכל CLP
תוכן תבניות מייל ו‑WhatsApp	מאוחסן בנפרד; דורש בדיקה ידנית
עמודים שנוצרו אחרי השינוי	עלולים להחזיר את המונח הישן מתוך תבנית

המשך מכאן

• מפת הטבלאות — מה יש בכל טבלה שזיהיתם כאן
• מוסכמות המוצר — מוסכמות השמות והמנגנון שמאחורי התוויות
• סוגי נתונים — פורמט הכתיבה לכל טיפוס
• סביבות וגישה — לאיזו מערכת בכלל אתם מחוברים