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

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

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

מאיפה זה מגיע ומה זה אומר

הנתונים מפורסמים בפורטל הדאטה הפתוחה הממשלתי, שרץ על CKAN. המשמעות המעשית פורטה במדריך ה-API של data.gov.il, וכאן חשובות שלוש נקודות:

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

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

המפתח: מספר רישום, לא שם

זו הנקודה שקובעת אם התהליך יעבוד.

שם חברה אינו מזהה. הוא לא ייחודי, הוא משתנה, והוא נכתב בכמה צורות: עם "בע"מ" ובלי, עם גרשיים ובלעדיהם, בעברית ובאנגלית, עם רווחים כפולים. "חברת ישראל בע"מ", "ישראל בעמ" ו-"Israel Ltd" יכולים להיות אותה חברה - או שלוש חברות שונות.

מספר הרישום כן מזהה. הוא יציב, ייחודי, ומופיע בכל מסמך רשמי.

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

אותו מספר הוא גם מפתח החיבור הטוב ביותר בין ה-CRM ל-ERP, ובדיוק מאותה סיבה.

מה בדיקה אוטומטית באמת נותנת - ומה לא

זו ההבחנה שהכי חשוב להעביר ללקוח לפני שמבטיחים משהו.

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

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

מה שנשבר בפועל

התאמת טקסט בעברית

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

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

גיל הנתונים

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

חברה שלא נמצאה

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

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

הדפוס שעובד

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

מתי בכלל לא לבנות את זה

שאלה ששווה לשאול לפני שמתחילים: כמה לקוחות עסקיים נקלטים בחודש?

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

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