NOCA.AI: קליטת הזמנות, חשבוניות ומסמכים ל-Salesforce, NetSuite ו-Priority

מה זה NOCA.AI ומתי היא מתאימה

NOCA.AI היא פלטפורמת no-code לבניית תהליכים מבוססי AI: קליטה וקריאה של מסמכים, טפסים, בוטים ותהליכי אוטומציה שמתחברים למערכות הליבה של הארגון. היתרון שלה הוא מהירות: אפשר להגיע לתהליך עובד מול Salesforce, NetSuite או Priority בלי לפתח הכל מאפס בקוד.

תהליך ב-NOCA.AI בנוי משלבים: טריגר (מייל, העלאת קובץ, טופס או קריאת API), שלבי AI שמסווגים ומחלצים, תנאים וכללים עסקיים, ושלבי חיבור שקוראים ממערכת היעד או כותבים אליה. כל שלב אפשר לבדוק ולשנות בלי לפרוס קוד מחדש.

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

NOCA.AI מתאימה כשמתקיימים רוב התנאים האלה:

• מסמכים מגיעים בכמויות, במייל או בהעלאה, בפורמטים לא אחידים (PDF, Excel, סריקות).
• מישהו בארגון מקליד היום את הנתונים ידנית למערכת.
• היעד הוא מערכת עם API מסודר: Salesforce, NetSuite, Priority.
• צריך תהליך שאפשר לשנות מהר, בלי מחזור פיתוח מלא על כל שינוי בכלל עסקי.

בעיבוד כבד של כמויות גדולות, או בתהליך שכולו חי בתוך מערכת אחת, אנחנו משלבים את NOCA.AI עם קוד או עם הכלים המקוריים של המערכת, כך שכל חלק יושב בכלי שמתאים לו.

מה אנחנו בונים ב-NOCA.AI

קליטת הזמנות רכש מהמייל ל-Priority ול-NetSuite בלי הקלדה ידנית

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

בקליטה ל-Salesforce ול-NetSuite, שירות מייל ב-Apex (Apex Email Service) מקבל את המייל ושומר את הקבצים המצורפים כקובצי Salesforce על רשומת קליטה. משימת Queueable שולחת לתהליך ב-NOCA.AI מסמך אחד בכל פעם דרך Named Credential, והתוצאה חוזרת כיצירה או עדכון של הזמנה. כך הקריאות ל-NetSuite נשארות בתוך מגבלת הבקשות המקבילות שלה.

קליטת הזמנות ל-Priority

ההזמנות נכתבות ל-Priority דרך ה-REST API (OData) של המערכת, עם משתמש API ייעודי, כהזמנת לקוח עם השורות שלה. כך הבדיקות והתמחור של Priority עצמה ממשיכים לחול על כל הזמנה.

קריאת חשבוניות עם AI: מעבר ל-OCR

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

קריאת מסמכי שירות ל-Salesforce

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

טפסים, תשלומים וממשקים

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

לקחים מעבודה אמיתית על חילוץ מסמכים

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

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

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

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

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

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

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

בעיות עסקיות שהתהליך הזה פותר

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

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

איך נראה תהליך קליטה טוב, שלב אחרי שלב

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

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

האדם נשאר בתמונה

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

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

איך זה נראה בפועל: מהזמנה במייל ועד רשומה ב-Priority

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

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

מה כדאי להכין לפני שמתחילים

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

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

איך פרויקט רץ

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

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

בחירת שותף: מה לשאול

• האם הוא יכול להראות תהליך קליטת מסמכים שרץ בייצור, לא רק דמו?
• איך הוא מטפל במסמך שהתהליך לא הצליח לקרוא? יש תור לבדיקה ידנית?
• האם הוא מכיר את מערכת היעד שלכם לעומק (Salesforce, NetSuite, Priority), כולל המגבלות שלה?
• האם הוא מתכנן את כל התהליך, כולל החלקים שנכון לבנות בקוד או ב-ERP?

NOCA.AI מול חלופות

בפועל אנחנו משלבים. בקליטת הזמנות הרכש ל-Salesforce ול-NetSuite, הקליטה והוויסות נבנו ב-Apex, והסיווג והקריאה ב-NOCA.AI.

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

התאמת הכלי לתהליך

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

למה CloudX

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

רוצים לבדוק אם המסמכים שלכם מתאימים לקליטה אוטומטית? דברו איתנו.