שתי הדרכים למשוך שערי חליפין יציגים מבנק ישראל, מה באמת חוזר בתשובה, מלכודת היחידה של הין והלירה, ואיך לשמור שער כדי שאפשר יהיה להסביר מחיר בדיעבד.
עיקרי הדברים
- הנתיב הפשוט מחזיר את השערים העדכניים בלבד, כולל חותמת עדכון אחת לכל האוסף.
- מסד הסדרות EDGE מחזיר סדרה לפי קוד בתבנית `RER_<מטבע>_ILS`, עם טווח תאריכים או מספר תצפיות אחרונות.
- לא כל מטבע מצוטט ליחידה אחת. בבדיקה שביצענו הין היפני הוחזר עם `unit` של 100 והלירה הלבנונית עם 10.
- אין שער חדש בימים שאין בהם מסחר, ולכן מערכת שמצפה לערך יומי תיתקע בסופי שבוע ובחגים.
- מחיר שנשמר בלי השער ששימש לחישובו אינו ניתן להסבר, וזו הבעיה שמגיעה חודשיים אחרי ההשקה.
בנק ישראל מפרסם את השערים היציגים בשני נתיבים תכנותיים נפרדים: נקודת קצה פשוטה שמחזירה את השערים העדכניים לכל המטבעות, ומסד הסדרות EDGE שמחזיר סדרה היסטורית לפי קוד סדרה. לתמחור יבוא צריך את שניהם - האחד לעדכון היומי, השני להסבר מחיר בדיעבד.
שני הנתיבים, ומתי בוחרים בכל אחד
| מאפיין | נקודת הקצה הפשוטה | מסד הסדרות EDGE |
|---|---|---|
| מה מחזיר | כל המטבעות, השער העדכני בלבד | סדרה אחת לפי קוד, עם היסטוריה |
| בחירת פריט | אין - האוסף כולו | קוד סדרה בתבנית RER_USD_ILS |
| טווח תאריכים | אין | startPeriod ו-endPeriod, או lastNObservations |
| תבניות | JSON, וגם XML בפרמטר asXML | sdmx-json וגם csv |
| שימוש טיפוסי | רענון יומי של טבלת שערים | טעינת היסטוריה, בדיקה בדיעבד |
בבדיקה שהרצנו החזירה נקודת הקצה הפשוטה 14 מטבעות, ובהם דולר, אירו, לירה שטרלינג, ין, פרנק שוויצרי, דולר קנדי ואוסטרלי, כתר דני, נורווגי ושוודי, ראנד, דינר ירדני, לירה לבנונית וג'ניה מצרית. אם המטבע שאתם מייבאים בו אינו ברשימה, זו החלטה שצריך לקבל מראש ולא לגלות בייצור.
מה באמת חוזר בתשובה, ולמה שדה היחידה מפיל חישובים?
כל פריט בתשובה של הנתיב הפשוט מכיל את קוד המטבע, את השער, שדה unit ושינוי באחוזים, וכן חותמת lastUpdate אחת שמשותפת לכל האוסף. שדה ה-unit הוא המלכודת: הוא לא תמיד 1.
בבדיקה שהרצנו הוחזר הין היפני בשער 1.9227 עם unit של 100 - כלומר הערך מתייחס ל-100 ין, לא לין אחד. הלירה הלבנונית הוחזרה עם unit של 10. קוד שמכפיל סכום בשער בלי לחלק ביחידה יטעה פי מאה בדיוק במטבע שבו הטעות הכי פחות בולטת לעין.
שתי מסקנות מעשיות:
- שומרים בבסיס הנתונים את השער ואת היחידה כשני שדות נפרדים, ולא את המנה ביניהם.
- כל חישוב עובר דרך פונקציה אחת שמקבלת סכום, מטבע ותאריך - ולא דרך כפל ידני שמפוזר בקוד.
איזה שער בכלל צריך - של היום או של אז?
תלוי מה השורה עושה. הצעת מחיר ללקוח צריכה שער עדכני, כי היא צופה פני עתיד. חשבונית ספק שהתקבלה לפני חודשיים צריכה את השער שהיה בתוקף באותו יום, אחרת אי אפשר להסביר את הסכום שנרשם.
לכן ההפרדה הנכונה היא בין שער חי לבין שער נעול:
- שער חי נמשך אוטומטית ומשמש רק לתצוגה ולחישוב הצעה חדשה.
- שער נעול נשמר על המסמך ברגע שנוצר, יחד עם התאריך שממנו נלקח ועם היחידה.
- מסמך שנוצר מחדש משתמש בשער הנעול שלו, ולא מושך שער חדש רק כי מישהו לחץ "הדפס".
- שינוי שער אינו מעדכן מסמכים קיימים. הוא מייצר גרסה חדשה, אם צריך.
- דוח היסטורי נשען על השדות שנשמרו, ולא על משיכה חוזרת מהמקור.
עיקרון דומה של הקפאת נתון על המסמך מתואר גם בניהול מקור אמת אחד לרשימת מחירים והצעות.
ההפרדה הזו נשמעת מובנת מאליה עד שמסתכלים על מה שקורה בלעדיה. מערכת שמחשבת מחדש כל סכום מהשער הנוכחי מציגה הצעת מחיר שנשלחה בינואר בסכום אחר במרץ, וסוכן שפותח את המסמך מול הלקוח לא יודע איזה מהמספרים נכון. ברגע שהשער נעול על המסמך, השאלה "למה זה יצא כך" נפתרת בשלושה שדות ולא בשחזור. בעסק שמנהל גם חוזים מתמשכים, אותה שאלה חוזרת בכל חידוש - ראו בקרת תזכורות לחידוש חוזה.
איך נראית משיכה יומית שלא שוברת אף אחד
משיכה יומית טובה היא כמה שורות קוד ושלוש החלטות. הקוד מבקש את האוסף העדכני, כותב שורה אחת לכל מטבע עם השער, היחידה ותאריך הפרסום, ולא דורס שורה קיימת של אותו תאריך. ההחלטות הן מתי מריצים, מה עושים כשהתשובה זהה לאתמול, ומי מקבל התראה כשלא הגיעה תשובה כלל.
- תדירות. פעם ביום מספיק לרוב העסקים, ורצוי אחרי שעת הפרסום ולא בחצות.
- אי-שינוי. תשובה זהה לאתמול אינה שגיאה. שומרים אותה כאותו פרסום, ולא כיום חדש.
- כישלון שקט. משיכה שנכשלה ולא כתבה כלום נראית בדיוק כמו יום ללא פרסום. לכן מפרידים בין "לא היה פרסום" לבין "לא הצלחנו למשוך", בשני סטטוסים נפרדים.
- טעינה היסטורית. לטעינה ראשונית משתמשים במסד הסדרות עם טווח תאריכים, ומריצים אותה פעם אחת. אין סיבה למשוך את 2019 בכל בוקר.
מה נשבר בפועל בתמחור יבוא
- יום ללא שער. שבתות, חגים וימים שאין בהם פרסום מייצרים חור בסדרה. משיכה שמצפה לערך יומי צריכה כלל ברור: לקחת את הפרסום האחרון שקדם לתאריך, ולתעד איזה תאריך נלקח בפועל.
- אזור זמן. חותמת העדכון מגיעה ב-UTC. מערכת שמתייגת אותה כזמן מקומי תזיז פרסום של בוקר ליום הקודם.
- עיגול. עיגול בכל שלב ביניים במקום בשלב האחרון מייצר הפרשי אגורות שמצטברים לאורך שורות רבות בהזמנה.
- המרה כפולה. סכום שהומר לשקל, נשמר, ואז הומר בחזרה לצורך תצוגה - כמעט אף פעם לא חוזר למספר המקורי.
- שער יציג מול שער בפועל. השער שהבנק פרסם אינו השער שבו הבנק המסחרי המיר בפועל את הכסף שלכם. את ההפרש רואים בהתאמת הבנק, לא בתמחור.
הפער האחרון קשור ישירות לפריסת עלויות על יבוא, שמתוארת בבקרת עלות נחיתה ליבואן.
מה כדאי שיהיה מוכן לפני שמחברים
- רשימת המטבעות שבהם העסק באמת עובד, מול הרשימה שהמקור מפרסם.
- החלטה מהו "השער של היום" בעסק שלכם, כולל מה עושים ביום ללא פרסום.
- שדות במסמך לשער, ליחידה ולתאריך השער - שלושה שדות, לא אחד.
- מקום לשמור את התשובה הגולמית של המשיכה, לפחות לתקופה קצרה, לצורך חקירה.
- הגדרה מי רשאי לדרוס שער ידנית, ואיפה זה נרשם.
מקורות
שאלות נפוצות
למה השער לא השתנה מאתמול?
כי אין פרסום בכל יום קלנדרי. בבדיקה שהרצנו ביום שישי הוחזרה חותמת עדכון של היום הקודם, וזו התנהגות רגילה בסופי שבוע ובחגים. מערכת שמניחה ערך יומי חייבת כלל שמחזיר את הפרסום האחרון שקדם לתאריך המבוקש, ומתעד איזה תאריך נלקח.
איך מושכים שער היסטורי לתאריך מסוים?
דרך מסד הסדרות, לפי קוד הסדרה של אותו מטבע ובתבנית `RER_<מטבע>_ILS`, עם פרמטרי טווח תאריכים או עם מספר התצפיות האחרונות. הנתיב הפשוט מחזיר את המצב העדכני בלבד ואינו מתאים לשליפה היסטורית, גם לא לתאריך שהיה אתמול.
מה המשמעות של שדה היחידה בתשובה?
הוא אומר לכמה יחידות של המטבע מתייחס השער. בבדיקה שהרצנו הין היפני הוחזר עם יחידה 100 והלירה הלבנונית עם 10, בעוד רוב המטבעות הוחזרו עם 1. חישוב שמתעלם מהשדה הזה יטעה בסדר גודל, ודווקא במטבעות שבהם קשה לזהות זאת בעין.
האם אפשר לתמחר לפי השער בלבד?
השער הוא רק אחד הרכיבים. מחיר יבוא מושפע גם מעמלות המרה, מהובלה, מביטוח ומעלויות נוספות שמוקצות לפריט. השער קובע את בסיס ההמרה, אבל מחיר סופי שנבנה ממנו בלבד יסטה מהעלות בפועל, ולכן מקובל להפריד בין שכבת ההמרה לשכבת פריסת העלויות.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.