- 1שלוש הדרכים לבנות אינטגרציה של WooCommerce QuickBooks
- 2מדוע סנכרון ברמת ההזמנה שובר את ההתאמה
- 3דוגמה מפורטת
- 4“זה קוד פתוח — תוסף חינמי אמור לטפל בזה”
- 5הארכיטקטורה שעובדת: ניקוי חשבונות, סיכומי יומיים, שורות עמלות
- 6ב-LedgerPort, ארכיטקטורה זו היא דף הגדרות
- 7מתי תוסף מספיק — ומתי לא
- 8שכבת הסנכרון של סרגל ההנדסה צריכה להתבהר
- 9איך זה נראה אוטומטי
- 10וכאשר webhook נכשל — כי אחד כזה יקרה
- 11מס הגמישות
הכנסת הזמנות ל-QuickBooks היא החלק הקל. מדריך זה עוסק בחלק שרשימת התוספים לא מזכירה: לגרום לספרים להתאים לבנק.
יש 1,400 חשבוניות חדשות בקובץ QuickBooks Online שלכם, וכל אחת מהן נכונה.
התקנתם את המחבר, מיפיתם כמה שדות, וצפיתם בו עובד. כל הזמנת WooCommerce הגיעה ל-QBO עם שם הלקוח, פריטי השורה, המשלוח, המסים. לפי כל מדד בדף התכונות של התוסף, אינטגרציית WooCommerce QuickBooks שלכם הושלמה.
ואז פתחתם את הזנת הבנק. Stripe הפקידה 6,782.40$ ביום שני. PayPal הכניס 1,911$ ביום רביעי. ואף אחת מ-1,400 החשבוניות האלה — אף אחת — לא תואמת לאף אחד מהמספרים האלה. QuickBooks מבקש מכם כעת להתאים הפקדה בודדת לעשרות חשבוניות פתוחות, שאף אחת מהן לא מסתכמת אליה.
אם הייתם כאן, כנראה שעשיתם מה שרוב בעלי החנויות עושים: הסרת התוסף, חזרה לייצוא CSV, והסקת המסקנה שכל הקטגוריה שבורה. היא לא. אבל הדבר שנמכר לכם — סנכרון הזמנות — מעולם לא היה הבעיה האמיתית.
הבעיה האמיתית היא ש-WooCommerce וחשבון הבנק שלכם מתארים שני מציאויות שונות, ושום כמות של סנכרון הזמנות לא מתרגמת ביניהן. פוסט זה מסביר מדוע, עם המספרים, ועובר דרך ההגדרה שמתאימה בפועל.
שלוש הדרכים לבנות אינטגרציה של WooCommerce QuickBooks
באופן כללי, כל גישה נופלת לאחת משלוש קטגוריות.
1. מחבר QuickBooks הרשמי. המחבר של Intuit עצמו (שבנוי על מנוע OneSaas הישן) דוחף הזמנות WooCommerce ל-QBO כחשבוניות או קבלות מכירה. הוא זול, הוא נתמך על ידי Intuit, ולצורך העתקת הזמנות בסיסית הוא עושה את מה שהוא אומר. מה שהוא יודע עליו זה הזמנות — מה הלקוח קנה ומה WooCommerce חייב להם.
2. תוספי סנכרון ייעודיים. כלים כמו MyWorks Sync הולכים הרבה יותר עמוק: סנכרון דו-כיווני, מיפוי שדות גרעיני, סנכרון מלאי ולקוחות, דחיפות בזמן אמת. אם העסק שלכם פועל על חשבוניות בודדות — חשבונות סיטונאיים, לקוחות B2B, תשלומים הקשורים לאנשים ספציפיים — נאמנות פר-הזמנה זו בעלת ערך אמיתי, ו-MyWorks חזק בזה. כתבנו השוואה מפורטת ב-LedgerPort vs. MyWorks אם אתם שוקלים את המסלול הזה.
3. ייצוא CSV ידני. ייצוא הזמנות מ-WooCommerce, עיבוד גיליון האלקטרוני, הזנת רשומות יומן ל-QBO ידנית. שליטה מוחלטת, עלות תוכנה אפסית, ובין שעתיים לשמונה שעות בחודש תלוי בנפח — בתוספת כל שגיאה שאדם עייף עושה בשעה השלישית.
| שיטה | מה זה מעביר | עלות | מתאים לבנק? |
|---|---|---|---|
| מחבר QuickBooks | הזמנות → חשבוניות/קבלות | נמוך | לא מעצמו |
| תוסף סנכרון (לדוגמה, MyWorks) | הזמנות, לקוחות, מלאי | $ – $$ | רק עם הגדרות תשלום זהירות |
| CSV ידני | כל מה שתקליד | הזמן שלך | רק אם אתה עושה את חישובי התשלום בעצמך |
שימו לב מה יש לשלושתם במשותף: כולם מתחילים מנתוני הזמנה. ונתוני הזמנה הם רק חצי ממערך הנתונים שאתה צריך.
מדוע סנכרון ברמת ההזמנה שובר את ההתאמה
הנה הבעיה המבנית, ואין לה שום קשר לאיזה תוסף בחרת.
WooCommerce יודע על הזמנות: לקוח, פריטים, סכומים, מס. הוא לא יודע כמה Stripe ניכה בעמלות עיבוד, מתי PayPal איגד תשלום, איזה החזר מהשבוע שעבר קוזז מול הפקדה של השבוע, או מה עמלת חיוב חוזר עשתה לפידיון של יום שלישי. המידע הזה חי אצל שערי התשלום שלך — מערך נתונים נפרד לחלוטין, בלוח זמנים נפרד לחלוטין.
הזנת הבנק שלך, בינתיים, רואה תמיד רק את הצד של שער התשלום בסיפור: פיקדונות נטו, מאוגדים בלוח הזמנים של שער התשלום. אז כשכלי סנכרון מעתיק הזמנות ל-QBO, הוא רושם נאמנה מערך נתונים שחשבון הבנק שלך לעולם לא יאשר.
דוגמה מפורטת
נניח שהחנות שלך קיבלה 96 הזמנות בסוף שבוע, בסך כולל של 7,200 דולר ברוטו. WooCommerce מדווח על כך כשלושה ימי מכירות נפרדים, וסנכרון ברמת ההזמנה שלך יוצר 96 חשבוניות ב-QBO.
ביום שני, Stripe שולח תשלום אחד:
| תשלום Stripe — יום שני | סכום |
|---|---|
| מכירות סוף שבוע ברוטו (96 הזמנות) | $7,200.00 |
| עמלות עיבוד (2.9% + $0.30 × 96) | −$237.60 |
| החזרים (2 הזמנות משבוע שעבר) | −$180.00 |
| פיקדון נטו לחשבונך | $6,782.40 |
QuickBooks מחזיק כעת 96 חשבוניות בסך 7,200 דולר, הפרוסות על פני שישי, שבת וראשון. הזנת הבנק שלך מחזיקה פיקדון אחד ביום שני בסך 6,782.40 דולר. 237.60 הדולר בעמלות אינם מופיעים בספרים שלך בשום מקום. 180 הדולר בהחזרים שייכים להזמנות שכלל אינן בנתוני סוף השבוע הזה. אין שום שילוב של 96 החשבוניות הללו ששווה לפיקדון הזה — החישוב בלתי ניתן להתאמה מבנית.
הכפל בכל תשלום, בכל שער תשלום, בכל חודש. כך מגיעים ל-1,400 חשבוניות מבריקות והזנת בנק שלא מסכימה עם אף אחת מהן.
[תמונה: תרשים המראה נתוני הזמנות של WooCommerce ונתוני תשלומים של Stripe כשני זרמים נפרדים, כאשר הזנת הבנק מחוברת רק לזרם התשלומים — והפער היכן שחיות עמלות ותזמון החזרות]
בשלב זה רוב האנשים מגיעים לאחת משלוש מסקנות: חלקם מחליטים שהם צריכים לשכור הנהלת חשבונות, חלקם חוזרים לגיליונות אלקטרוניים, וחלקם מבינים שהבעיה היא ארכיטקטונית ומתקנים את הארכיטקטורה. חלק זה מיועד לקבוצה השלישית.
“זה קוד פתוח — תוסף חינמי אמור לטפל בזה”
בואו נקרא להנחה בשמה ישירות, כי היא סבירה והיא שגויה.
WooCommerce הוא קוד פתוח, לאקוסיסטם יש תוסף לכל דבר, ורובם בחינם או זולים. אז האינסטינקט הוא: תוסף חינמי אמור לטפל גם ב-QuickBooks. ותוסף חינמי יכול לטפל במה שתוספים טובים בו — העברת נתוני הזמנות מבסיס נתונים אחד לאחר. החלק הזה באמת נפתר.
אבל התאמה אינה בעיית העברת נתונים. זו בעיית תרגום בין שתי מערכי נתונים שאינם מסכימים על סכומים (ברוטו מול נטו), תזמון (תאריך הזמנה מול תאריך תשלום), והיקף (הזמנות של סוף השבוע הזה מול החזרים של השבוע שעבר). אף תוסף לא פותר זאת על ידי העברת הזמנות מהר יותר או מיפוי שדות בצורה מדויקת יותר – לא הגדרתם את זה לא נכון, וגם מפתח התוסף לא. הכלי פתר את הבעיה שהוא הבין. הבעיה שיש לכם באמת גדולה יותר מהמודל של הכלי לגביה.
הארכיטקטורה שעובדת: ניקוי חשבונות, סיכומי יומיים, שורות עמלות
התיקון הוא מבנה שהרואי חשבון השתמשו בו במשך עשרות שנים, המיושם לשערים. שלושה רכיבים: חשבון סליקה לכל שער, סיכומי יום במקום חשבוניות לכל הזמנה, ושורות עמלה מפורשות בכל תשלום. הנה ההגדרה הידנית, שלב אחר שלב.
צור חשבון סליקה לכל שער. ב-QBO, הוסף חשבון מסוג נכס שוטף אחר בשם “Stripe Clearing”, חשבון נוסף עבור “PayPal Clearing”, ואחד לכל שער נוסף. חשבון זה מייצג כסף שלקוחות שילמו שעדיין לא הגיע לבנק שלך – וזה בדיוק מה שהוא.
רשום סיכומי מכירות יומיים במקום חשבוניות בודדות. פעם ביום, רשום רשומה אחת לכל שער: מכירות ברוטו, הנחות, החזרים שהונפקו, הכנסות משילוח, ומע"מ שנאסף. חייב את חשבון הסליקה בסכום הברוטו; זכה את חשבונות ההכנסות, השילוח, והחבות במס שלך. דוח רווח והפסד שלך מציג כעת הכנסה לפי יום – שזה כל מה שנדרש להכנת מס וניתוח רווחיות – ללא 96 חשבוניות יתומות. (אם אתה מגדיר חשבונות הכנסה ומס מאפס, מדריך הנהלת החשבונות של WooCommerce שלנו מכסה את מבנה תוכנית החשבונות המלאה.)
רשום כל תשלום כרשומת יומן כאשר הוא מתקבל. זכה את חשבון הסליקה בסכום הברוטו של התשלום. חייב את חשבון הבנק שלך בהפקדה נטו. חייב חשבון הוצאות “עמלות עיבוד סוחר” בהפרש העמלה, ורשום זיכויים של החזרים כנגד הכנסות. בשימוש בדוגמת סוף השבוע: זכה את Stripe Clearing ב-7,200$, חייב את הבנק ב-6,782.40$, חייב עמלות ב-237.60$, רשום את 180$ ההחזרים כנגד הכנסות. לכל דולר יש כעת בית.
התאם את ההפקדה בפיד הבנק. מכיוון ששורת הבנק ברשומת היומן שלך היא 6,782.40$ וההפקדה היא 6,782.40$, QuickBooks מתאים אותם בלחיצה אחת. זה הרגע שבו כל המבנה משתלם: התאמה הופכת לאישור במקום לחקירה.
עקוב אחר יתרת חשבון הסליקה. היא אמורה לרחף ליד הסכום שנמצא כעת במעבר עם השער – כמה ימי מכירות, לא יותר. יתרה גדלה בהתמדה פירושה שעמלות או החזרים הולכים ללא רישום איפשהו. מספר יחיד זה הוא מערכת ההתראה המוקדמת שלך, והוא הדבר הראשון שרואה חשבון טוב יבדוק.
[IMAGE: תרשים זרימה – רשומות סיכום יומיות זורמות לחשבון Stripe Clearing, ואז רשומת יומן תשלום מפצלת לבנק (נטו) ועמלות עיבוד (הוצאה), עם התאמת פיד הבנק בסוף]
זה נעשה ידנית, לוקח למנהל חשבונות מוכשר 30–60 דקות לשער בשבוע, וכל שלב הוא הזדמנות לטעות הקלדה. אבל המבנה נכון — והמבנה הוא הדבר שאף פלאגין לסנכרון הזמנות לא נותן לך.
ב-LedgerPort, ארכיטקטורה זו היא דף הגדרות
אם חמשת השלבים הללו נשמעים כמו משמעת יומן רבה, הנה החלק שכדאי לדעת: בתוסף WooCommerce של LedgerPort, כל רכיב קיים כתצורה. לשונית התשלומים של תצורת סנכרון מזהה אוטומטית כל שער תשלום פעיל בחנות שלך ומקצה לכל אחד מהם חשבון סילוק משלו, עם חשבון סילוק ברירת מחדל כגיבוי לכל מה שלא הגדרת. חשבון סילוק אחד לכל שער אינו התעמלות יומן — זוהי רשימה נפתחת לכל שער.
מס נהנה מאותו יחס: מס מכירות נרשם לחשבון התחייבות של QuickBooks שתקבע, ופריט שורה של עיגול סופג את ההבדלים ברמת הסנט בין חישובי המס של WooCommerce לבין אלו של QuickBooks — נייר הפתק של התאמה שלא מזהירים אותך לגביו. כיצד הזמנות נרשמות הוא עוד רשימה נפתחת: קבלת מכירה להזמנות ששולמו, חשבונית כאשר התשלום מגיע מאוחר יותר, הצעת מחיר להצעות מחיר. והטקסונומיה של שיטות סנכרון היא כללית לפלטפורמה — ההנחיה של התיעוד עצמו מציבה בערך 100+ הזמנות ביום כנקודה שבה רשומות לכל הזמנה מפסיקות להיות הנהלת חשבונות והופכות לקרקעית, וזה בדיוק המקום שבו סיכומי יומיים מרוויחים את מקומם.
שום דבר מזה לא דורש פרויקט תצורה, גם כן. לפי שאלות נפוצות של התיעוד עצמו, כל לשונית מגיעה עם ברירות מחדל הגיוניות — רוב החנויות יכולות להתחיל לסנכרן מבלי לגעת בתצורת סנכרון כלל, ולהדק את ההגדרות מאוחר יותר כשהספרים ידרוש זאת.
מתי תוסף מספיק — ומתי לא
תשובה כנה: לפעמים הכלים ברמת ההזמנה הם הפתרון הנכון.
פלאגין סנכרון ברמת ההזמנה כנראה מספיק אם: אתה מקבל פחות מ-100–200 הזמנות בחודש ויכול לעקוב אחר הפערים בעין; אתה מנהל שער אחד עם החזרים פשוטים ונדירים; או שהעסק שלך מבוסס חשבוניות — חנויות סיטונאיות ו-B2B שבהן תשלומים קשורים בפועל לחשבוניות לקוח ספציפיות. במקרה האחרון, סנכרון לכל הזמנה אינו באג, אלא דרישה, וכלי כמו MyWorks בנוי בדיוק בשבילו.
אתה צריך את שכבת המודעות לתשלומים אם: אתה מנהל מספר שערים (Stripe יחד עם PayPal זה המקום שבו רוב החנויות חוצות את הקו); החזרים וסכסוכים הם מציאות שבועית; הנפח שלך הופך את הרישומים לכל הזמנה לבלתי ניתנים לניהול; או רואה חשבון סוגר לך את הספרים חודשית ומצפה שעדכון הבנק יתאים. בנקודה זו, נתוני הזמנה בלבד לא יכולים להפיק ספרים ניתנים להתאמה — לא משנה כמה טוב הם מסונכרנים.
אם אתה נוטה לכיוון המסלול המודע לתשלומים, שלוש התנגדויות מעשיות נוטות לעלות לאחר מכן:
“האם זה יטפל במנויים שלי?” LedgerPort מסנכרן נתוני הזמנות ולקוחות סטנדרטיים של WooCommerce, וחידושי מנויים מגיעים כהזמנות רגילות כאשר WooCommerce יוצר אותם — כך שהכנסה חוזרת זורמת באותו צינור, אין צורך להגדיר שום דבר מיוחד.
“מה אם סנכרון נכשל בשקט?” סנכרון בזמן אמת רוכב על Webhooks של WooCommerce, ו-WooCommerce מנסה מחדש משלוחים שנכשלו באופן אוטומטי. אם משהו עדיין חומק, דף סנכרון ידני בתוך wp-admin דוחף נתונים לפי דרישה — אתה לעולם לא מחכה לתמיכה שתשלח מחדש הזמנה.
“האם אני יכול להפעיל מספר חנויות מול חשבון אחד?” כן — כל חנות מחוברת נחשבת כחיבור אחד כנגד מגבלת התוכנית שלך, גלוי בדף החיבור. שאר השאלות המעשיות (תאימות HPOS, אחסון אישורים, תפקידי משתמש נדרשים) נענות בהתחלה מהירה עם LedgerPort עבור WooCommerce.
שכבת הסנכרון של סרגל ההנדסה צריכה להתבהר
יש עוד ציר הערכה אחד, והוא זה שרישומי התוספים לעולם לא מראים: מה התוכנה עושה לחנות שלך כאשר היא מתחברת — וכאשר היא עוזבת. ההקצאה של LedgerPort היא אוטומטית ועסקית. חיבור יוצר מפתח API של WooCommerce REST לקריאה בלבד — הוא קורא את החנות שלך, הוא לא כותב אליה — ורושם 13 webhooks בשם המכסים הזמנות, מוצרים, וריאציות, לקוחות והחזרים. אם כל שלב הקצאה נכשל באמצע הדרך, כל מה שכבר הושלם מוחזר אוטומטית, כך שהחנות שלך לעולם לא תישאר מוגדרת חלקית.
שאר מצב האבטחה ניתן לבדיקה באותה מידה: אישורי כניסה מאוחסנים מוצפנים ב-AES-256-CBC באמצעות מפתחות האבטחה של WordPress של האתר שלך, חיבור דורש את ההרשאה manage_woocommerce (מנהלי מערכת ומנהלי חנות), ו-LedgerPort לעולם לא נוגע ב-webhooks שיצרת בעצמך. ניתוק קשר הוא נקי באותה מידה - הוא מוחק בדיוק את מפתח ה-API ואת ה-webhooks שהוא יצר, החנות וההזמנות שלך אינן נפגעות, והמיפויים שלך שורדים לחיבור מחדש. ניסיון ראשון כושל עולה כלום.
אותה משמעת באה לידי ביטוי כאשר סנכרון משתבש. כשלים אינם פער שקט או הודעת PHP - הם טקסונומיה בשם עם תיקונים מתועדים: אסימון QuickBooks שפג תוקפו (הבחירה של התיעוד לשגיאת הסנכרון הנפוצה ביותר), מוצר ללא מיפוי, ערך כפול, שדה חובה חסר. כל שגיאה מציינת את הסיבה שלה ואת נתיב ההתאוששות שלה. זה, יותר מכל תיבת סימון של תכונה, הוא הגבול האמיתי של "תוסף מספיק": הוא מסתיים היכן שנכשל בלתי ניתן לשחזור ובלתי נראה מתחיל.
איך זה נראה אוטומטי
LedgerPort בנוי כשכבת המודעות לתשלומים הזו, והוא תומך בWooCommerce לצד Shopify. הוא מתחבר לחנות שלך *וגם* לשערים שלך, ואז מריץ את הארכיטקטורה שלמעלה באופן אוטומטי: סיכומים יומיים שפורסמו לחשבונות סליקה של שערים, יומני תשלומים עם עמלות מפורטות, הפקדות שמתאימות לעדכון הבנק שלך עד השקל האחרון. ההתקנה לוקחת כ-15 דקות, וחנויות בנפח משמעותי מדווחות על חיסכון של שעות בכל שבוע.
הנה כל הגדרת WooCommerce, מההתחלה ועד הסוף:
התקן את הפלאגין. בממשק הניהול של WordPress שלך, עבור אל Plugins » Add New Plugin, חפש את LedgerPort, לחץ על Install Now, ואז Activate. תצטרך HTTPS באתר שלך וחשבון LedgerPort — המדריך המלא להתקנה מכסה את שתי הדרישות המוקדמות.
הפעל את אשף ההתקנה. לאחר ההפעלה, LedgerPort פותח את האשף באופן אוטומטי כשכבה במסך מלא. לחץ על התחבר ל-LedgerPort כדי להתחיל.
אשר את החיבור. אתה מופנה ל-app.ledgerport.com כדי להתחבר, לבחור את העסק שאליו אתה מתחבר, וללחוץ על אשר — ואז נשלח בחזרה ישירות לממשק הניהול של וורדפרס שלך.
- תן לאספקה לרוץ. LedgerPort יוצר מפתח WooCommerce REST API עם גישת קריאה, רושם webhooks עבור הזמנות, החזרים, מוצרים ולקוחות, ומאשר את החיבור. אם שלב כלשהו נכשל, הכל חוזר אוטומטית — אין חנות שהוגדרה חלקית. כאשר זה מצליח, אתה מגיע ללוח המחוונים של LedgerPort, מחובר.
משם, הכל נמצא תחת תפריט LedgerPort בתוך ממשק הניהול של וורדפרס — לוח מחוונים, מיפויים, סינכרון ידני, יומני ביקורת — כך שמעקב אחר הצנרת לעולם לא מצריך יציאה מוורדפרס. ומבנה חשבון הפירוט מהסעיף הקודם אינו פרויקט תצורה נפרד: זהו שיטת הסינכרון של סיכום יומי, בחירה אחת מתוך חמש, שנבחרה פעם אחת.
וכאשר webhook נכשל — כי אחד כזה יקרה
סנכרון בזמן אמת רוכב על webhooks, ו-webhooks כן כן לגבי טבעם: במוקדם או במאוחר, מסירה נכשלת. השאלה שרוב התוספים החינמיים לא יכולים לענות עליה היא מה קורה הלאה. כאן לתשובה יש שכבות. WooCommerce עצמו מנסה מחדש מסירות webhook שנכשלו באופן אוטומטי. כל מה שעדיין חומק לא נעלם - הוא צף כסטטוס סנכרון לכל רשומה, ניתן לשחזור מדף הסנכרון הידני בתוך wp-admin.
זרימת העבודה היא בחירת תיבת סימון, ואז דחוף נבחרים או דחוף הכל, ואז חלון מודאלי של התקדמות חיה שמראה כל רשומה נוחתת או נכשלת - עם סיבה מצורפת, לא רק אייקון אדום. והפירוט שהופך את ההתאוששות לאחר הפסקה לבטוחה: דחיפה מובטחת לא לשכפל. רשומות שכבר סונכרנו מדולגות אוטומטית, ודחיפה מחדש של רשומה שנכשלה יוצרת או מעדכנת את הרשומה ב-QuickBooks במקום לפרסם אותה פעמיים. "בחר הכל, דחוף הכל" לאחר שבוע גרוע לא יכול לפרסם הכנסות כפולות.
עוד שני עובדות מה-FAQ ששייכות לכאן: התוסף תואם באופן מלא לאחסון הזמנות בעלות ביצועים גבוהים של WooCommerce ללא כל תצורה נוספת, ו - כפי שצוין לעיל - חידושי מנויים של WooCommerce רוכבים על אותו צינור כמו הזמנות רגילות. מילוי היסטורי משתמש גם הוא באותו דף, מה שאומר ש"היינו על גיליונות אלקטרוניים כל השנה" הוא ייבוא, לא פרויקט הזנת נתונים: דפדף בשנה, דחוף, צפה בסטטוסים הופכים לירוקים.
הפשרה, נאמר בפשטות: LedgerPort מסכם. הוא לא יסנכרן רשומות לקוח בודדות או ינהל מלאי ב-QBO — אם העסק שלך זקוק לחשבוניות לכל לקוח, כלי כמו MyWorks נשאר ההתאמה החזקה יותר, וההשוואה עוברת על הקו הזה בכנות.
תמחור מתחיל בחינם — עד 30 הזמנות בחודש, חנות אחת, סינכרון ידני לפי דרישה — כך שתוכל לצפות בתשלום אמיתי מתבצע לפני שתשלם משהו. צמיחה מתחילה מ-$25 לחודש עם סינכרון יומי אוטומטי; קנה מידה, מ-$67 לחודש, מוסיף סינכרון בזמן אמת בתוספת יומני התשלומים וטיפול בעמלות שהפוסט הזה עוסק בהם. כל תוכנית בתשלום נושאת אחריות להחזר כספי ללא תנאי של 14 יום — לא ניסיון, החזר מלא, ללא שאלות.
מס הגמישות
הנה האמת הטרגית-קומיקלית על WooCommerce: הדבר שהופך אותו למצוין הוא הדבר ששובר את הספרים שלך.
אתה יכול להפעיל כל שער תשלום, כל תוסף קופה, כל הרחבת מנויים, כל שיטת תשלום אזורית — והאקוסיסטם יתמוך בכל זה. הגמישות הזו היא הסיבה האמיתית שבגללה בחרת בפלטפורמה. אבל זה גם אומר שהנתונים הפיננסיים שלך מקורם בארבע או חמש מערכות שלעולם לא הסכימו לדבר באותה שפה, ושכבת הנהלת החשבונות יורשת כל אחת מהדיאלקטים האלה.
מערכת הפלאגינים לא יכולה לבנות לך את זה, כי מבנה הוא בדיוק מה שמערכת פתוחה לא מכתיבה. לכן המבנה צריך להתקיים בשכבת הנהלת החשבונות: חשבונות סליקה, סיכומים יומיים, שורות עמלות. זה המס שתשלמו עבור גמישות בכל מקום אחר - וזה מחיר הוגן, ברגע שתפסיקו לצפות שסנכרון ההזמנות ישלם אותו עבורכם.
אותן 1,400 חשבוניות מהפתיחה לא היו שגויות. הן פשוט ענו על שאלה שהבנק שלכם מעולם לא שאל. אם תעדיפו שהספרים שלכם יענו על השאלה הנכונה, חברו את חנות ה-WooCommerce שלכם ל-LedgerPort — התוכנית החינמית מכסה את התשלום הראשון שלכם, וברגע שההפקדה תתאים, תדעו שהארכיטקטורה עובדת.
