הפקת מסמכים בעברית אוטומטית: מצבי הכשל של RTL ואיך מונעים אותם

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

כשל 1: מחרוזת מעורבת

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

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

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

כשל 2: גופן שאינו מוטמע

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

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

כשל 3: סוגריים, מרכאות וסימנים

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

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

כשל 4: טבלאות והיישור

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

כשל 5: חילוץ טקסט מ-PDF

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

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

איפה הבעיה יושבת, בנתון או בתבנית

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

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

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

הבדיקה שתופסת את כל החמישה

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

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

למה זה עובד בתצוגה ונשבר בהדפסה?

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

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

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

מה עוד שווה להגדיר בתבנית

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

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

מקורות

• אוטומציה לעסקים קטנים בישראל
• רשות המסים - מידע לעסקים