מערכת IDP לחברת שילוח ישראלית צריכה לטפל בתיק יבוא שלם כמקרה אחד, חשבונית ספק, פקינג ליסט, שטר מטען ורשימון מכס, ולא בכל מסמך בנפרד. היא צריכה לקרוא עברית ואנגלית, לזהות מי שלח, לבדוק את המסמכים מול תיק היבוא ב-ERP, ולקלוט רק אחרי שהכול תואם.
בחברת שילוח שמטפלת באלפי מסמכים בחודש, מישהו פותח כל מייל. מוריד את הקבצים, מחפש את התיק, משווה שורות, מקליד. כל טעות קטנה מתגלה רק כשהמכולה כבר בנמל, ואז זה דחוף.
במאמר הזה נעבור על מה שחשוב לבדוק לפני שבוחרים, ואיך נראית אוטומציה של מסמכי מכס שבאמת עומדת בנפח כזה.
למה כלי OCR רגיל לא מספיק לחברת שילוח
המסמכים לא מגיעים ביחד
תיק יבוא הוא ארבעה או חמישה מסמכים שמגיעים בכמה מיילים, לפעמים מכמה שולחים ובימים שונים. כלי שקורא מסמך אחד בכל פעם משאיר לכם את העבודה של לחבר ביניהם.
כל סוכן שולח אחרת
חשבונית מסין, פקינג ליסט מגרמניה, שטר מטען של חברת הספנות. אין פורמט אחיד, ואין סיכוי לתחזק תבנית לכל שולח. סוכן חדש צריך לעבוד מהמסמך הראשון, בלי שמישהו יגדיר אותו קודם.
הבדיקה היא העבודה האמיתית
לחלץ שדות זה החלק הקל. לבדוק שהכמויות בפקינג ליסט תואמות לחשבונית, ושהחשבונית תואמת לתיק היבוא ב-ERP, זה מה שלוקח את הזמן. סורק לא עושה את זה, ולכן אחרי הסורק מישהו עדיין בודק הכול ביד.
מה לבדוק לפני שבוחרים מערכת IDP
טיפול בתיק שלם
האם המערכת יודעת לאסוף את כל המסמכים של אותו משלוח לתיק אחד, גם כשהם מגיעים בימים שונים ומשולחים שונים. בלי זה, מישהו אצלכם עדיין מחבר את החלקים.
עברית ואנגלית באותו מסמך
רשימון מכס בעברית, חשבונית באנגלית, הערות ידניות על הפקינג ליסט. המערכת צריכה לקרוא את שניהם בלי להתבלבל, ובלי שתגדירו לה מה מופיע איפה.
בדיקה מול ה-ERP לפני הקליטה
המערכת צריכה למצוא את תיק היבוא בפריוריטי או ב-Oracle Fusion, להשוות, ולעצור מה שלא תואם. בלי זה קיבלתם סורק מהיר, לא פחות עבודה. ככה זה נראה בקליטת תיק יבוא לפריוריטי בלי הקלדה.
איפה הנתונים נשמרים
חברות שילוח מטפלות במסמכים של לקוחות. בדקו אם אפשר להתקין את המערכת על השרתים שלכם, ואם הנתונים יוצאים לצד שלישי בדרך.
חיבור ישיר ל-ERP
חיבור דרך Make, n8n או Zapier הוא עוד נקודת כשל ועוד מערכת לתחזק. חיבור ישיר ודו-כיווני גם קורא מה-ERP וגם כותב אליו, וזה מה שמאפשר את הבדיקה.
מודל כללי או מודל מתמחה
על ההבדל בין מודל כללי למודל שמתמחה במסמכי שרשרת אספקה יש ויכוח אמיתי בתעשייה. בנפחים של חברת שילוח ההבדל מורגש כל יום, בשטר מטען מצולם עקום או בפקינג ליסט בכתב יד.
איך זה עובד עם דוקונברט
דוקונברט היא שכבת ה-AI מעל ה-ERP. היא מחוברת לפריוריטי דרך הקונקטור הדו-כיווני של דוקונברט לפריוריטי, ול-Oracle Fusion Cloud ERP בחיבור ישיר, בלי תוכנת ביניים. ככה נראה תיק יבוא אחד.
המסמכים מגיעים למייל
חשבונית ספק, פקינג ליסט ושטר מטען, בשלושה מיילים נפרדים, מסוכן המכס ומהספק. אף אחד לא מעביר אותם לתיקייה.
דוקונברט מזהה את השולח ואת המשלוח
לפי כתובת המייל, מספר המכולה ומספר ההזמנה. המסמכים מתקבצים לתיק אחד, גם כשהאחרון מגיע יומיים אחרי הראשון.
דוקונברט מוצאת את תיק היבוא ב-ERP
ומשווה כמויות, מחירים, משקלים וסכומים בין המסמכים לבין עצמם ומול התיק. שורה שחסרה באחד המסמכים מסומנת מיד.
מה שלא תואם נעצר
עם הסבר קצר, למשל כמות בפקינג ליסט שלא תואמת לחשבונית. הצוות מטפל רק בחריגים, לא בכל תיק.
מה שתואם נקלט
לתוך תיק היבוא בפריוריטי, בלי הקלדה. ככה עובדים אצל קול טימבר, שביטלו את הבדיקות הידניות בתיקי יבוא.
למי זה מתאים
חברות שילוח ועמילי מכס שמקבלים אלפי מסמכים בחודש מעשרות סוכנים וספקים.
יבואנים עם מחלקת יבוא שמקלידה תיקים לפריוריטי או ל-Oracle Fusion.
מנהלי תפעול שרוצים לדעת איפה כל תיק עומד בלי לשאול.
מנהלי מערכות מידע שמחפשים חיבור ישיר בלי פיתוח ובלי תוכנת ביניים, כמו בקליטת רשימוני מכס אוטומטית אצל iDigital.
שאלות ותשובות
כמה זמן לוקחת ההטמעה?
הטמעה טיפוסית של דוקונברט היא כ-10 ימי עסקים. מתחילים מסוג תיק אחד או מקבוצת סוכנים ומרחיבים.
האם צריך להגדיר תבנית לכל סוכן או ספק?
לא. דוקונברט מזהה את המסמך ואת השולח בלי תבניות, וסוכן חדש עובד מהמסמך הראשון.
מה קורה כשמסמך אחד מהתיק מגיע באיחור?
התיק נשאר פתוח עד שכל המסמכים הגיעו. דוקונברט מצרפת את המסמך המאוחר לתיק הנכון ומשלימה את הבדיקה.
האם המסמכים של הלקוחות יוצאים מהארגון?
לא חייבים. אפשר להתקין את דוקונברט בענן ייעודי או על השרתים שלכם, והחיבור ל-ERP ישיר.
רוצים לראות את זה על המסמכים שלכם? לתיאום דמו או להתחיל ניסיון