הגדרת קבלות 54-FZ ב-1C-Bitrix: ביקורת, יישום, תמיכה

לקוח הקים קופה רושמת, אך קבלות נכשלות בתהליך הפיסקליזציה עם שגיאה 'invalid tag format 1057'. תרחיש אופייני: עבור שירות משלוחים, חסר מאפיין אובייקט התשלום. אנו מפרקים את הגדרת קבלות 54-FZ ב-1C-Bitrix.

הצוות שלנו עם למעלה מ-5 שנות ניסיון ויותר מ-50 פרויקטים שהושלמו מבטיח פיסקליזציה בניסיון הראשון. ביצענו ביקורת על יותר מ-200 תצורות קופה רושמת, כך שאנו מכירים את כל המלכודות. לפי הסטטיסטיקה שלנו, 60% מהכשלים נובעים ממאפיין אובייקט תשלום שגוי, ו-30% נובעים מהיעדר הקצאת מע"מ.

בעיות שאנו פותרים

מאפיין אובייקט תשלום שגוי. Bitrix מצפה לשדה PAYMENT_OBJECT בכל פריט. אם לא צוין, הקופה הרושמת דוחה. עבור שירותים — SERVICE, עבור סחורות — COMMODITY, עבור מקדמה — PAYMENT. מוגדר דרך ממשק הניהול או עדכון גורפי דרך SQL. שימוש בהגדרת API מהיר פי 3 מהזנה ידנית ומפחית שגיאות ב-80%.

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

SELECT ID, NAME FROM b_catalog_product WHERE VAT_ID IS NULL LIMIT 20;

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

UPDATE b_catalog_product cp
JOIN b_iblock_element ie ON cp.ID = ie.ID
SET cp.VAT_ID = (
    SELECT ID
    FROM b_catalog_vat
    WHERE RATE = 20 AND ACTIVE = 'Y'
    LIMIT 1
)
WHERE ie.IBLOCK_ID = 7 AND cp.VAT_ID IS NULL;

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

כיצד להגדיר FFD 1.2 ב-1C-Bitrix?

מבנה הקבלה נקבע על ידי המחלקה \Bitrix\Sale\Cashbox\Check והמחלקות היורשות ממנה. הסוגים העיקריים מתוארים בתיעוד Bitrix Cashbox API.

עבור תשלום דו-שלבי (החזקה + אישור), נדרשות שתי קבלות: תחילה מקדמה, לאחר מכן התחשבנות מלאה. שדות חובה עבור FFD 1.2: PAYMENT_OBJECT ו-PAYMENT_METHOD. הראשון מציין מה נמכר (טובין, שירות, עבודה), השני מציין את אופן התשלום (תשלום מלא, מקדמה, אשראי). יש להגדיר במאפייני המוצר או דרך API.

מדוע הקבלה אינה מפוסקלת?

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

הפעילו ניפוי שגיאות:

define('CASHBOX_DEBUG', true);

היומן נכתב אל bitrix/modules/sale/cashbox/log/. כדי לקבל את גוף הקבלה ללא שליחה:

$checkData = $check->getDataForCheck(); var_dump($checkData);

הגישה שלנו להגדרה

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

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

מה כלול בעבודה

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

תהליך העבודה

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

לוח זמנים ועלות

לוח זמנים — בין 5 ל-15 ימים בהתאם למורכבות (אינטגרציה עם 1C, תוכניות בונוס, סכמות סוכנים). העלות מחושבת באופן אישי לאחר ביקורת. קבלו ייעוץ מהנדס — נעריך את הפרויקט שלכם.

שגיאות אופייניות במהלך ההגדרה

אם סטטוס הקבלה הוא 'F' — יש לשלוח אותה מחדש דרך לוח הניהול. איפוס סטטוס באופן פרוגרמטי:

$check = \Bitrix\Sale\Cashbox\CheckManager::getCheckById($checkId);
if ($check) {
    $check->setField('STATUS', \Bitrix\Sale\Cashbox\Internals\Check::STATUS_NEW);
    $check->save();
}

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