הגדרת מטבעות ב-Битрикс: היכן נשבר שער החליפין
ריבוי מטבעות בחנות מקוונת נשען לא על סימון בתיבות הסימון בהגדרות הקטלוג, אלא על עקביות בין שלוש ישויות: מטבע הבסיס של המחיר, מטבע התצוגה ומטבע החיוב בחשבונית. ביניהן נמצא שער החליפין — עם התאריך, הכיוון וכלל העיגול שלו. די בכך שהשרשרת תתפרק, והקטלוג מציג סכום אחד, החשבונית מכילה אחר, והפער צץ כבר בהתכתבות עם הלקוח.
הכשל השכיח ביותר — חישוב מחדש כפול. חילופי מחירים עם 1С מגיעים במטבע הבסיס, מודול האינטגרציה מיישם את שער החליפין ורושם את התוצאה כמחיר, והליבה בעת התצוגה מחשבת אותו מחדש — לפי שער הקטלוג. הפריט מתייקר או מוזל בלי משים, וזאת באופן שונה עבור סוגי מחירים שונים.
סוג שני — השהיית שער החליפין. שער המטבע בקטלוג מתעדכן לפי לוח זמנים, חילופי המחירים עם 1С פועלים בחלון משלהם, והעמוד גם חי במטמון. המוצר נמכר לפי שער שכבר אינו קיים: אף אחד אינו שולט בפער בין העדכון, היישום ואיפוס המטמון, ולכן הפער נע בין שעה ליממה.
שלישי — הגדרת מטבעות ב-Битрикс כאשר יש כמה סוגי מחירים: לכל אחד כלל עיגול משלו ולוגיקת חישוב מחדש אוטומטי משלו. אז הפער בין מחיר הוויטרינה לסכום בחשבונית הופך למערכתי — הנחות מחושבות מבסיס אחד, ומיסים מבסיס אחר.
נפרק כיצד זה נסגר: מסדר החישוב מחדש ועד החיבור למערכת החשבונאית.
מה נותן חישוב מחדש נכון של מחירים ומלאי
כל עוד שער החליפין לא חושב מחדש, הוויטרינה והמחסן חיים לפי מספרים שונים: הקונה רואה סכום אחד, המנהל נשען על מלאי לפי מחיר ישן, ולהזמנה נכנס סכום שלישי. בפרויקטים מרובי מחסנים הפער מצטבר — חלק מהפריטים יורדים למינוס לפי עלות, והמרווח על ההזמנה נודע רק לאחר בדיקה ידנית.
חישוב מחדש מוגדר של מחירים לפי שער פועל באופן מתוזמן: המחירים משויכים לסוג ולמטבע בסיס, מקור השער נבחר, כללי העיגול וסף החישוב מחדש הוגדרו. הקונה מקבל מחיר במטבע של הקונה, והמחסן והעלות מחושבים במטבע הבסיס — המרווח הסופי בכל הזמנה צפוי.
סנכרון המחסן והוויטרינה סוגר את החצי השני של המשימה: המלאי נגרע ברגע ביצוע ההזמנה, ולא לפי ייצוא לילי, ולכן לא נוצרות מכירות "במינוס" וביטולים בגלל מוצר חסר. ההקצאה להזמנה נשמרת עד לתשלום ומוסרת בעת ביטול — הוויטרינה מציגה מלאי אמיתי.
ב-1С-Битрикс זה נפתר באמצעות צירוף של סוגי מחירים, סוכנים ומטפלי סל, בלי תיקונים ידניים בכרטיסים. האפקט המדיד: חישוב מחדש של הקטלוג אורך דקות במקום שעות, שיעור ההזמנות עם תיקון מחיר ידני יורד, והפער בין הוויטרינה למחסן מצטמצם לפריטים בודדים.
דרכים לעדכון שערים: ידני, לפי לוח זמנים, לפי אירוע
שער המטבע בקטלוג אינו שדה אחד, אלא צירוף: ערך השער, מטבע הבסיס, השיוך אליו של מחירים וכללי מחיר. לכן מצב העדכון נבחר לא לפי נוחות ממשק הניהול, אלא לפי שתי שאלות: באיזו תדירות המחירים משתנים, וכמה קריטי האיחור בין השער החדש לחישוב מחדש.
בנפרד נקבע מקור שער המטבע — שער רשמי, שער בנק או ספק תשלומים, או קובץ שמייצאת המערכת החשבונאית. אם המקור חיצוני, מיד מגדירים התנהגות בעת אי-זמינות שלו, היסטוריית ערכים ונוהל חזרה לאחור במקרה של שער שנטען בטעות.
השוואת מצבים
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| עדכון שער ידני | 2–5 מטבעות, השער נקבע בחוזה או משתנה לעיתים רחוקות | תלוי באדם: עדכון שהוחמץ, אין היסטוריה, בתיקונים תכופים — פערים בין השער למחיר |
| ייבוא אוטומטי של שערים לפי לוח זמנים | מטבעות עיקריים עם שער ציבורי, קטלוג עם מאות פריטים | איחור עד ההרצה הבאה; בכשל במקור המחירים נשארים לפי השער הישן, נדרשים בקרה על ביצוע המשימה והתראה על שגיאה |
| חישוב מחדש לפי אירוע | המחיר חייב להיות מדויק ברגע ביצוע ההזמנה או שמירת הפריט | עומס וחישובים חוזרים, קשה יותר לנפות; חובה הגבלות נפח והגנה מפני רקורסיה |
בפועל משלבים מצבים: הזנה ידנית משאירים למטבעות נדירים, ייבוא אוטומטי של שערים לפי לוח זמנים — עבור העיקריים, וחישוב מחדש לפי אירוע מפעילים רק היכן שהמחיר חשוב ברגע הפעולה. צירוף כזה לא מאפשר לכשל אחד במקור לשכתב מחירים בכל הקטלוג, והפער בין השער למחיר נתפס נקודתית.
סדר הטמעת ריבוי מטבעות באתר
ריבוי מטבעות אינו מתג בהגדרות, אלא מערכת כללים שלפיהם המחיר נכנס לקטלוג, לסל ולחשבונית. לכן סדר העבודות נבנה כך שאפשר יהיה להחזיר לאחור כל שינוי: תחילה מתעדים את סכימת המחירים הנוכחית, אחר כך מתכננים את כללי החישוב מחדש, ורק לאחר מכן נוגעים באתר הפעיל. להלן מסלול הטמעת ריבוי המטבעות.
-
מיפוי הסכימה הנוכחית: אילו סוגי מחירים מעורבים, איזה מטבע הוא בסיסי, היכן מאוחסנים המחירים וההנחות ומי עוד קורא אותם — ייצוא, זירות מסחר, אינטגרציה עם המערכת החשבונאית.
-
תכנון כללי החישוב מחדש: מקור ותדירות קבלת השער, כיוון החישוב מחדש, כללי עיגול מחירים — עד איזו ספרה, לטובת מי ובאילו טווחים, התנהגות בהיעדר שער.
-
הגדרת מטבעות וסוגי מחירים: מוסיפים מטבעות, משייכים לסוגי מחירים, מגדירים פורמטי תצוגה, תוספות מחיר ותצוגה עם מס, כך שהוויטרינה והמסמכים יציגו אותו דבר.
-
עדכון שערים מתוזמן: מגדירים עדכון אוטומטי, יומן שינויים והתראה כאשר השער יוצא מהטווח הצפוי — אחרת שגיאה בנתונים תצוף כבר בהזמנות שבוצעו.
-
בדיקה בסביבת בדיקות: פורסים עותק של הקטלוג וההזמנות, משווים מחירים שחושבו מחדש לפי מדגם פריטים, מריצים את הסל, ביצוע ההזמנה, חשבוניות ודוחות, ובנפרד — עיגול בערכי גבול.
-
העברה לאתר הפעיל ומסירה: מפעילים בחלון עומס נמוך, מתעדים נקודת שחזור, מוסרים את נוהל עדכון השערים ותיאור כללי עיגול המחירים.
הגדרות, נהלים ותיעוד בנושא שערים
ההגדרות אינן עומדות בפני עצמן: השער משתנה, המערכת החשבונאית מעדכנת ספרי עזר, ויש לחשב מחדש את המחירים באתר כך שהזמנות שכבר בוצעו לא ישתנו. לכן אנו מוסרים את הפרויקט יחד עם ערכת ארטיפקטים — לפיהם כל מהנדס, שלא השתתף בהטמעה, ישחזר ויחזור על הלוגיקה בלי התכתבות וניחושים.
- כרטיסי מטבעות — אילו מטבעות משתתפים בחישובים, איזה מהם הוגדר כבסיסי, דיוק העיגול, פורמטי תצוגת המחיר בקטלוג, בסל ובהודעות דוא"ל.
- נוהל עדכון שערים — מקור (הזנה ידנית, שירות חיצוני, סנכרון עם המערכת החשבונאית), תדירות הטעינה, התנהגות בעת אי-זמינות המקור ונוהל חזרה לשער התקין האחרון.
- כללי חישוב מחדש — באיזה מטבע נקבע מחיר ההזמנה, באיזה שלב נקבע השער, כיצד מחושבים מחדש תשלומים חלקיים, החזרים וחובות.
- סכימת סנכרון — אילו ספרי עזר ומסמכים מסונכרנים בין האתר למערכת החשבונאית, באיזה כיוון, באיזו תדירות ולפי איזה מאפיין נקבע הפער.
- תיעוד הסנכרון — מפת התאמת מטבעות, רשימת פרמטרי האינטגרציה, תיאור המטפלים והנקודות שבהן יש להוסיף מטבע חדש.
- תפקידי מנהל — מי משנה שערים, מי מתקן עיגול, למי זמינים חישוב מחדש ידני של הזמנות ויומן מלא של שינויי שער.
- הוראות בדיקה — רשימת בדיקה לקבלה: מה להשוות לאחר החלפת שער, חיבור מטבע חדש ועדכון מודול הסנכרון.
הערכה נשארת אצל המזמין במאגר הקוד ובבסיס הידע הפנימי — איתה תמיכה בשערים הופכת למשימה שגרתית של מנהל תורן, ולא לפנייה נפרדת למפתח.
מקרה בוחן: הסרנו פערי מחירים בין המערכת החשבונאית לוויטרינה
חנות עם שתי ויטרינות ושלושה מטבעות בקטלוג: המחירים חיו במערכת החשבונאית, ובאתר חושבו מחדש בעת הייצוא. השער הוזן ידנית פעם ביום, ואם הוא השתנה בערב שישי, הוויטרינה עד יום שני סחרה לפי ערך מיושן. המנהלים יישרו את הפער כבר בהזמנה — השלב הידני הזה היה המקום היקר ביותר בזרימה.
איך זה נראה לפני
הסנכרון הסטנדרטי הביא מחיר במטבע הבסיס, והחישוב מחדש לשאר המטבעות היה תלוי בסקריפט נפרד, שהורץ לפי לוח זמנים ולא ידע על תיקונים בספר המטבעות. העיגול לא תועד בשום מקום: בוויטרינה ובחשבונית אותו פריט נתן ערכים שונים, ובסל — ערך שלישי. בדיקה פעם בשבוע מצאה באופן עקבי פערים בעשרות פריטים, וכל אחד טופל ידנית.
מה ארגנו מחדש
הכנסנו סוג מחיר בסיסי אחד ונגזרים ממנו — עם כלל עיגול מפורש בכל שלב. ספר המטבעות מולא מתוך המערכת החשבונאית, והשערים נמשכים באמצעות משימה מתוזמנת, ולא בידי מפעיל.
1С-Битрикс במסגרת זו אחראי על החישוב, ולכן היה צריך להעביר את השיוך לאירוע שינוי מחיר ולאפס מטמון נקודתית, ולא בשלמותו — אחרת הוויטרינה הייתה מחזירה ערך ישן עד לעדכון המתוכנן.
הוספנו בדיקת לילה של הוויטרינה מול המערכת החשבונאית: פערים נאספים לדוח ונשלחים לאחראי, והיסטוריית שינויי המחיר נשמרת בנפרד — כל פריט ניתן להחזיר לערך הקודם בלי ייצוא חוזר.
מדדים לפני ואחרי
- שיעור ההזמנות עם תיקון מחיר ידני: 18% → 0,6% (היתר — תנאים אישיים של לקוחות).
- תגובה לשינוי שער: עד יומיים → עד 15 דקות לאחר פרסום הערך החדש.
- פערים בבדיקה השבועית: כמה עשרות פריטים → בודדים, כולם עם הסבר.
- ביטול ייצוא חוזר של הקטלוג בגלל מחיר: הרצה אחת במקום שלוש.
הסכימה הפכה לצפויה: המחיר בהזמנה, בחשבונית ובוויטרינה מחושב לפי כלל אחד, והחלפת שער אינה דורשת מעורבות מנהל.
במה עדכון שער ידני שונה מעדכון אוטומטי ב-Битрикс
מצב ידני — אלו רשומות בספר המטבעות: עבור כל מטבע נשמרים שער וערך נקוב, והמנהל מתקן אותם בממשק הניהול. כל עוד יש מטבע אחד-שניים והשער נבחן מחדש פעם בשבוע, הסכימה מחזיקה מעמד.
היא נשברת בלי לשים לב: הערך עודכן, אבל חישוב המחירים מחדש מתבצע בהרצה נפרדת — ועד אליה בוויטרינה תלויים סכומים ישנים, שאותם הקונה לוקח להזמנה.
עדכון אוטומטי של השער מסיר את הפעולה עצמה: הערך מגיע מהמקור — בנק מרכזי או המערכת החשבונאית — לפי לוח הזמנים של הסנכרון ונכתב לאותם שדות בספר. לוח הזמנים נקבע בידי סוכן: פעם ביום לפני פתיחה, כל כמה שעות, או ברגע הופעת ייצוא חדש בסנכרון עם 1С.
אז כבר לא המספרים חשובים, אלא ההגדרות סביבם: כמה ספרות אחרי הנקודה לשמור, כיצד לעגל, מה לעשות כאשר הפער מול השער הקודם גבוה מהסף שהוגדר.
ההבדל ניכר במסמכים. ההזמנה שומרת את השער שנקבע ברגע ביצועה, ואין לשכתב אותו בדיעבד; המצב הידני בקלות מפספס את רגע הקיבוע — סוף שבוע, חג, ממשק ניהול סגור.
האוטומציה כותבת את הערך ליומן ומשאירה היסטוריה: לפי כל תאריך ניתן לראות איזה שער פעל, ואת הסנכרון ניתן להריץ מחדש בלי לתקן הזמנות ידנית.
גם המגבלות של האוטומציה ספציפיות: נדרשים סנכרון מהודק ומטפל שגיאות. אם המקור אינו זמין, צריך להישאר השער הקודם ולהופיע התראה לאחראי, ולא ערך ריק או אפס, שבגללו הקטלוג ייכנס לחישוב מחדש לפי אפס. לכן בהגדרת מטבעות Битрикс משאירים בדרך כלל מצב ידני כמצב חירום — עם רישום חובה ביומן והתראה.
שאלות נפוצות בנושא שערים, עיגול וחישובים עם הקונה
שער המטבע ב-1С-Битрикс אינו ערך אחד: שער לתאריך, שער שנקבע בהזמנה, ושער החישוב מחדש של הקטלוג. הפער בין החשבונית לקטלוג מוסבר כמעט תמיד בכך שההזמנה שומרת את השער ברגע ביצועה, וכרטיס המוצר מציג מחיר לפי השער הנוכחי. המשימה אינה "להתאים" אחד לשני, אלא לקבוע מהו מקור האמת לכל פעולה.
הסתעפות נפרדת — עיגול מחירים. הכללים מוגדרים ברמת המטבע או סוג המחיר: עד איזו ספרה, באיזה כיוון ובאיזה רגע — לפני החישוב מחדש או אחריו. אם לעגל לפני החישוב מחדש, השגיאה בסל של עשרות פריטים יוצרת פער מורגש מול הסכום בחשבונית, ולכן סדר הפעולות מתועד במפורש.
ההזמנה בוצעה לפי שער ישן — מה לעשות איתה?
ההזמנה שומרת את השער ברגע ביצועה — זוהי התנהגות צפויה, ולא שגיאה. מחשבים מחדש רק לפי כלל מפורש: למשל, ברגע התשלום או המשלוח לפי השער בתאריך התשלום. הכלל מוגדר בתצורה, כדי שהמנהל לא יתקן סכומים ידנית.
כיצד לחשב הנחות ותוספות מחיר אם המחירים במטבעות שונים?
ההנחה מחושבת במטבע ההזמנה, אחרת האחוז שלה בקטלוג ובחשבונית יהיה שונה. הסדר אחיד לכל הכללים: תחילה חישוב מחדש לפי השער, אחר כך עיגול. תוספות המחיר יורשות את אותה לוגיקה.
מדוע החשבונית אינה תואמת לקטלוג?
ישנן שלוש סיבות טיפוסיות: שער היסטורי בהזמנה מול השער הנוכחי בקטלוג, סדר עיגול שונה, ומטמון מחירי הקטלוג. האבחון אורך דקות — משווים את השער בהזמנה, את שער המטבע בהגדרות ואת התוצאה לאחר העיגול.
נדון בסכימת התמחור בפרויקט שלכם
כדי שההערכה תישען על סכימת תמחור אמיתית, ולא על פריסט טיפוסי, אנו זקוקים לתמונת מצב של התצורה הנוכחית ולכמה תשובות בנוגע ללוגיקה העסקית. מהן תלוי אם נוגעים במודול הקטלוג, במנגנון ההנחות, בכללי העיגול או בסנכרון עם 1С.
- הרשאות גישה לממשק הניהול — חשבון משתמש עם הרשאות למודול הקטלוג ולמדור המטבעות, ובנוסף גישה לסביבת בדיקות, אם קיימת: תיקוני שערים ופורמטי מחירים נבדקים לא באתר הפעיל.
- רשימת מטבעות — אילו מטבעות באמת משתתפים במכירות, איזה נחשב לבסיסי לאחסון מחירים, ואילו רק מוצגים לקונה.
- ספק שערים — בנק מרכזי, בנק מסחרי, בורסה, מקור עצמאי או הזנה ידנית: מכך תלויים לוח הזמנים של העדכון האוטומטי והטיפול בכשלים.
- ביקורת ריבוי מטבעות — היכן מחושבים כעת מחדש המחירים: בקטלוג, בסל, בהזמנות, בייצוא ובאינטגרציות. פער בנקודה אחת שובר את הסכום הסופי.
- כללי עיגול ופורמט — צעד העיגול, הכיוון, המפרידים, מיקום סמל המטבע בתבנית המחיר.
- תרחישים עבור קבוצות קונים — קמעונאות, סיטונאות, אזורים, שותפים: לכל קבוצה עשוי להיות מטבע חיוב משלה ומערכת כללים משלה.
- מערכות משיקות — סנכרון עם 1С, מערכות תשלום, מרקטפלייסים ופידים: חשוב לדעת מראש מי עוד קורא מחירים מהקטלוג.
- מה כבר ניסיתם — ניסיונות הגדרה קודמים, שגיאות ידועות ומקומות שאסור לגעת בהם.
אם חלק מהנתונים לא נאסף — לא קריטי, את החסר נבהיר בהתכתבות. תארו את המשימה ושלחו את מה שיש בהישג יד: נחזור עם הערכה, שלבי עבודה ותוכנית בדיקה בסביבת הבדיקות.