צריך תוסף או שאפשר בלי?

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

מה קורה כשלקוח מבטל הזמנה לפני משלוח?

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

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

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

למה החשבוניות הפסיקו להיווצר פתאום?

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

חיבור חשבוניות לחנות אונליין: הזמנה, קבלה, חשבונית והחזרות

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

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

ארבעת האירועים שצריך לכסות

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

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

מתי נוצר המסמך?

זו ההחלטה הראשונה, ולשתי האפשרויות יש היגיון:

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

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

מה נשבר בעדכון פלטפורמה

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

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

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

מה מגדירים בהקמה

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

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

הבדיקה השבועית

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

מה עם כמה ערוצי מכירה

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

מה עושים עם הזמנות שלא שולמו

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

מה קורה עם עלות המשלוח

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

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

איך בודקים את זה נכון בהקמה

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

מה נשאר ידני גם אחרי החיבור

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

חיבור חשבוניות לחנות אונליין: הזמנה, קבלה, חשבונית והחזרות

עיקרי הדברים