מחירי חוזה לדילרים ב-Bitrix: הגדרה ואינטגרציה

מחירי חוזה ב-Bitrix: היכן נשברת לוגיקת ההנחות

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

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

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

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

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

מה משתנה אחרי ההגדרה: הזמנות, מחירונים, פניות

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

הזמנות ומחירונים

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

פניות לתמיכה

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

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

דרכים להפצת מחירונים אישיים: השוואת גישות

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

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

שלבי ההטמעה: מביקורת כללים ועד מסירת נהלים

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

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

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

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

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

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

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

מדיניות גישה ומחירונים ב-Bitrix לדילרים

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

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

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

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

מדדים לפני ואחרי

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

"מחירונים הפסיקו להיות עבודה נפרדת של המנהל", — מנהל מחלקת המכירות של הלקוח. מה שינו: ב-1C הגדירו סוגי מחירים נפרדים לכל חוזה וקישרו אותם לקבוצות משתמשים בצד 1C-Bitrix.

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

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

במה שונה מחירון נפרד מהנחה ללקוח עסקי?

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

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

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

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

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

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

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

מקרים מורכבים: מטמון, סנכרון עם מערכת החשבונות, הרשאות גישה

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

אפשר לנהל כמה מחירונים ללקוח עסקי אחד?

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

הסנכרון דורס תיקונים ידניים — איך מפרידים?

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

האם המטמון יציג מחיר של מישהו אחר?

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

נדון בסכימת תנאי הדילרים שלכם ונחזור עם תוכנית

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

• גישות לקטלוג ולמערכת החשבונות. סביבת בדיקה של האתר ומשתמש נפרד במערכת החשבונות עם הרשאות קריאה בלבד לפריטים ולסוגי מחירים — מנהל מערכת פעיל לצורך ההערכה לא נדרש.
• דוגמאות מחירונים. שניים-שלושה קבצי ייצוא אמיתיים עם מק"טים, עמודות ספק ורמות מחיר: מהם רואים איך מותאמים הפריטים ואיפה יש פערים בין הפריטים.
• תפקידים וקבוצות קונים. מי מקבל תנאים חוזיים — דילר, מפיץ, שותף; המחיר מקושר לקבוצה או לחוזה מסוים.
• כללי עדיפות וחישוב. איזה מחיר גובר בקונפליקט (אישי, קבוצתי, בסיסי), איך מעגלים, מה להציג אם אין מחיר לקבוצה.
• נקודת סנכרון. מה נחשב מקור האמת — קטלוג האתר או מערכת החשבונות, לאיזה כיוון ובאיזו תדירות מתבצע הייצוא, ואיך מטפלים בפריטים שהופסק ייצורם.
• מקרים מיוחדים. תוספות אזוריות, מע"מ במחיר או מעליו, כמה מחסנים, מגבלות כמות והיסטוריית רכישות של הדילר.

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