המטרה
הסוכנות הכינה דוחות חידוש שנתיים ללקוחות שלה (רשויות מקומיות) בעבודה ידנית: ייצוא חתך פוליסות מה-CRM, ואז בנייה מחדש באקסל של שורות סה"כ, טבלת חידוש לשנה הבאה, עמלות והפרשים מהשנה הקודמת. גם גיליונות ניסיון תביעות לאקטואריה נבנו כך. המטרה הייתה לחסוך את העבודה הידנית ולהפיק קבצים זהים במבנה ובנוסחאות לאלה שהצוות כבר סומך עליהם.
הפתרון
מנוע Python שקורא כל אחד מפורמטי האקסל של חתך הפוליסות בסוכנות וכותב חוברת חידוש עם נוסחאות חיות: שורת סה"כ, טבלת חידוש לשנה הבאה, הפרש מהשנה הקודמת ופרוט ההפרשים. מעליו ממשק ווב ב-Flask ו-Vue 3 שמריץ את כל התהליך מקצה לקצה: Playwright מתחבר ל-CRM הווב של הסוכנות, שולף את דוח החידושים, מחלץ את כל הרשויות, מייצא חתך לכל אחת ומריץ עליו את המנוע. תהליך שני מקבל את דוח הרווחיות שהמבטח שולח ומוסיף לו גיליון ניסיון תביעות לאקטואריה. המערכת רצה כשירות Windows בשרת של הסוכנות, עם פריסה אוטומטית מ-GitHub.
עיקרי הדברים
- חידוש מלא לכל הרשויות בלחיצה אחת: מייצוא מה-CRM ועד קובץ אקסל מוכן
- קבצי הפלט שומרים על נוסחאות חיות, כך שהצוות יכול להמשיך לערוך אותם
- מתמודד עם כמה פורמטי אקסל היסטוריים, כולל xls ישן
- בדיקה תא אחר תא מול הדוחות הידניים של הלקוחה
- רץ על השרת של הסוכנות עם פריסה אוטומטית וחזרה לגרסה קודמת
האתגר
ייצואי החתך הגיעו בכמה פורמטים שונים: כותרות בשורה 3 או 4, השנה בתאים שונים, שמות עמודות נרדפים, עמודות שנתי ותקופה כפולות, וקבצי xls ישנים שהחזירו מספרי פוליסה כ-float. בנוסף היו טעויות הקלדה במספרי הפוליסות, כך שקיבוץ לפי התאמה מדויקת פיצל פוליסות אמיתיות.
זיהוי כותרות בהתאמה גמישה של שמות עמודות במקום מיקומים קבועים, נרמול מספרים לקבצים ישנים, וקיבוץ פוליסות לפי מילת ענף וספרות הסיום עם מיזוג במרחק עריכה 1. כל שינוי נבדק מקצה לקצה מול כל פורמטי הדוגמה.
openpyxl כותב נוסחאות אבל לא את הערכים המחושבים שלהן, ולכן קבצים שנוצרו נראו ריקים בתצוגה מקדימה, ופתיחה ושמירה של חוברת של הלקוחה דרכו מוחקת ערכים שמורים, גרפים ו-Pivot.
שלב Excel COM ב-Windows מחשב מחדש ושומר כל קובץ פלט, עם ניסיונות חוזרים כשאקסל לא משתחרר בזמן. גיליונות חדשים נוספים לחוברות של הלקוחה רק דרך COM, עם בדיקה שמספר הגיליונות גדל ושאף גיליון מקורי לא נעלם.
ב-CRM, יציאה מכל שדה תאריך מפעילה postback שיכול לאפס שדות אחרים, כך שלפעמים הייצוא החזיר בשקט פוליסות משנים אחרות. בנוסף הוא מאפשר session אחד למשתמש, ולכן שתי הרצות במקביל ניתקו זו את זו.
שדות התאריך ממולאים בלולאה עד שכולם מחזיקים את הערך יחד, ואחרת התהליך נכשל עם שגיאה ברורה. כל ההרצות עוברות דרך תור עם worker יחיד לתהליכי CRM ומסלול נפרד לעבודת אקסל מקומית, כך ש-sessions ב-CRM לא חופפים לעולם.
הכללים העסקיים נגזרו מהאופן שבו הלקוחה בונה את הדוחות ידנית, והיא בודקת כל מספר. נוסחאות העמלה, אילו שורות נכנסות לסיכומים ומה מותר לשנות בבלוק הנתונים המקורי היו צריכים להתאים לקבצים שלה בדיוק.
כל הלוגיקה העסקית מתועדת, שאלות פתוחות נשלחות ללקוחה בכתב, ובדיקה אוטומטית משווה את הפלט תא אחר תא, כולל פורמט המספרים, מול הגיליונות שהיא בנתה ידנית.
מה נמסר
- מחולל דוחות חידוש (Python CLI + הפעלה בגרירת קובץ)
- ממשק ווב ב-Flask ו-Vue 3 עם תור הרצות והיסטוריה
- אוטומציה ל-CRM ב-Playwright
- תהליך דוח תביעות אקטואריה
- סקריפטי התקנה כשירות Windows ופריסה ב-GitHub Actions עם rollback
- תיעוד לוגיקה עסקית וסקריפטי בדיקה
תוצאות
4
תהליכים
End-to-end
תהליך
Hebrew RTL
ממשק
מה זה לימד אותי
- כשהלקוחה בודקת כל מספר, צריך לבדוק מול הקבצים הידניים שלה, כולל פורמט המספרים ולא רק ערכים
- תהליך שעובד רק לפעמים הוא המסוכן: עדיף להיכשל בבירור כשמצב ה-CRM לא בדיוק מה שהתבקש
- אסור להניח מבנה קבוע לאקסל - כל קובץ דוגמה חדש חשף מבנה שלא היה בקודמים