WooCommerce היא שלכם. וזו בדיוק הנקודה.
WooCommerce רצה על ה-WordPress שלכם, בשרת שלכם, עם הקוד פתוח. אין דמי פלטפורמה, אין מגבלות על מה מותר להתקין, ואפשר לשנות כל דבר. בשביל בעל חנות ישראלי זה יתרון אמיתי - אבל הוא מגיע עם מחיר: מה שלא מותקן, פשוט לא קיים.
ובישראל, מה שלא מותקן זה בדרך כלל בדיוק הדברים שהרשויות דורשות.
שלושת החורים שכל חנות WooCommerce ישראלית פוגשת
חשבונית מס. WooCommerce שולחת "אישור הזמנה" - מסמך שיווקי, לא מסמך חשבונאי. לקוח עסקי שמבקש חשבונית מס נשאר בלי מענה, ואתם נשארים עם רשימת הזמנות שצריך להפוך למסמכים בסוף החודש.
מספרי הקצאה. תיקון 157 דורש שחשבונית מעל הסף תקבל מספר מרשות המסים ברגע ההפקה. בעולם של WooCommerce הדרישה הזו לא קיימת - אין לה שדה, אין לה תהליך.
הדלפק. ברגע שאתם מוכרים גם פיזית - בחנות, בדוכן, בתערוכה - צריך קופה. ואם הקופה לא מדברת עם WooCommerce, נוצרות שתי אמיתות: מה שהאתר חושב שיש במלאי, ומה שבאמת יש על המדף.
הפער שהכי כואב: המלאי
זה החלק שמפיל עסקים, כי הוא לא מתגלה מיד.
מוכרים חולצה בדלפק. האתר לא יודע. לקוח מזמין את אותה חולצה אונליין. עכשיו יש הזמנה שאי אפשר לספק - וצריך להתקשר, להתנצל, לזכות. כל אירוע כזה עולה לקוח.
הפתרון היחיד שעובד לאורך זמן הוא מלאי אחד: מכירה בדלפק מורידה מהמלאי שהאתר מציג, והזמנה באתר מורידה מהמלאי שהקופה מציגה. לא ייצוא, לא סנכרון לילי - אותו מספר, בשני המקומות.
מה מתחבר בפועל
חיבור WooCommerce לקופה אמור להזיז ארבעה סוגי מידע, בשני הכיוונים:
- מוצרים - הקטלוג מהאתר מופיע בקופה, כולל וריאציות ומחירים. לא מקלידים מחדש.
- מלאי - עמודה אחת, משותפת. מה שנמכר בדלפק יורד מהאתר.
- הזמנות - מכירה בקופה נרשמת כהזמנה ב-WooCommerce, כך שכל ההיסטוריה של הלקוח במקום אחד.
- לקוחות וקופונים - כרטיס הלקוח והקופונים מהאתר עובדים גם בדלפק.
מה לבדוק לפני שמתחברים
לפני חיבור, שווה לוודא שלושה דברים בחנות שלכם:
- מפתחות API - WooCommerce מייצרת זוג מפתחות (Consumer Key/Secret) בהגדרות. ודאו שהם בהרשאת קריאה וכתיבה, אחרת ההזמנות מהקופה לא ייכתבו חזרה.
- מבנה הווריאציות - מוצר עם מידות וצבעים צריך להיות מוגדר כ-Variable Product עם SKU לכל וריאציה. וריאציה בלי SKU היא וריאציה שהקופה לא יודעת לזהות מול ברקוד.
- פרמלינקים - WooCommerce דורשת מבנה כתובות ידידותי כדי שה-REST API יענה. אם האתר על ברירת המחדל, ה-API יחזיר שגיאות.
והצד הישראלי - זה מה שמשלים את התמונה
חיבור טכני לבד לא פותר את הרגולציה. מה שצריך להיסגר במקביל:
- חשבונית מס קבלה על כל מכירה, בדלפק ובאתר, עם מספר הקצאה בזמן אמת מול רשות המסים.
- מספור רציף ונעול, חתימה דיגיטלית וארכיון - כדי שבבדיקה יהיה מה להראות.
- ייצוא מבנה אחיד ו-PCN874 לרואה החשבון, מנתוני האמת.
ב-Popay החיבור ל-WooCommerce כלול, לא מודול בתשלום נפרד, והצד הישראלי מובנה באותה מערכת - כך שהמכירה, החשבונית והדיווח הם תהליך אחד ולא שלושה.
שלוש התקלות שחוזרות בחיבורי WooCommerce
וריאציה בלי SKU. מוצר עם מידות וצבעים חייב SKU נפרד לכל וריאציה. בלי זה, סריקת ברקוד בדלפק לא יודעת איזו מידה נמכרה - והמלאי יורד מהמוצר הכללי או לא יורד בכלל. זו התקלה מספר אחת, והיא מתגלה רק בספירה.
מפתחות בהרשאת קריאה בלבד. WooCommerce מייצרת זוג מפתחות (Consumer Key/Secret). אם ההרשאה היא Read ולא Read/Write, הקטלוג יופיע יפה בקופה - אבל ההזמנות מהדלפק לא ייכתבו חזרה לאתר. הכל ייראה תקין עד שתחפשו מכירה ולא תמצאו אותה.
תוספים שמתערבים בהזמנה. אתר Woo ותיק אוסף תוספים - שדות מותאמים בצ'קאאוט, ניהול מלאי חיצוני, כלי מחירים. תוסף שכותב למלאי בעצמו ייכנס להתנגשות עם הקופה. לפני חיבור, שווה לעבור על רשימת התוספים הפעילים ולזהות מי נוגע במלאי ובהזמנות.
מרוץ המלאי - ומה באמת קורה
זה התרחיש ששווה להבין לעומק, כי הוא מסביר למה "סנכרון כל 15 דקות" לא מספיק.
יש פריט אחד במלאי. בשעה 10:00:05 לקוח בחנות קונה אותו בדלפק. בשעה 10:00:20 לקוח באתר מוסיף אותו לעגלה ומשלם. אם הסנכרון עובד בקצב של דקות, האתר עדיין חושב שיש פריט - וההזמנה תתקבל.
עכשיו יש לכם הזמנה שאי אפשר לספק: שיחת טלפון, התנצלות, זיכוי, ועלות סליקה שכבר שולמה. בעונת חגים זה לא מקרה נדיר.
לכן השאלה לספק היא לא "האם יש סנכרון" אלא "תוך כמה זמן מכירה בדלפק משתקפת באתר" - וכמה זמן בכיוון ההפוך.
רוצים להעמיק? קראו על החיבורים והאינטגרציות, על ניהול מלאי ועל חשבוניות ורשות המסים.
רוצים לראות איך זה עובד אצלכם בחנות? רישום להדגמה קצרה - חצי שעה, בלי התחייבות.