Новости

2.8.2 — 2026-10-02

2.8.2

Спрямо 2.8.1.

Комити (3)

• 5dc4a92 fix: надбавката за наложен платеж влиза в реда „Доставка“ на описа
• 14efb66 fix: описът се закръгля с пренос, за да е равен на наложения платеж

Бележки

• Описът (packingList) е точно равен на наложения платеж. Отстъпката (купон, точки лоялност) идва по редовете с 4 знака, а всеки ред се закръгляше поотделно — aptekanove 000089738: опис 61.45 срещу НП 61.43 → HTTP 517 „Сумата на наложения платеж е различна от сумата по описа“. Сега — закръгляне с пренос.
• Надбавката за наложен платеж (Webcode_Surcharge) е в реда „Доставка“, доколкото е в наложения платеж (доставка + надбавка = една сума). Диалогът: сумата на реда следва избрания платец.

При деплой

Нищо специално. Диалогът за ръчна товарителница изисква webcode/module-carrier ≥ 2.14.6 за същото закръгляне.

2.8.1 — 2026-09-30

2.8.1

Спрямо 2.8.0.

Комити (1)

• ef2cd6d fix: taxonomy:sync обявява само поддържаните типове (econt-2)

Бележки

• econt:taxonomy:sync обявява само поддържаните типове (econt-2): помощта изброяваше state и complex, street, block, POI, които командата отказва с „Invalid Data Type“. Сега: country, city или office. Поведението на синхронизацията не е променено.

При деплой

• Без промени в базата, DI или статичното съдържание.

2.8.0 — 2026-09-25

2.8.0

Спрямо 2.7.2.

Внимание при деплой

• Конструктор: сменена сигнатура на __construct — при деплоя се чисти generated/.
• Зависимости: require в composer.json: webcode/module-carrier: ^2.10 → ^2.12.

Комити (2)

• b5c6515 Release 2.8.0
• 3916ea6 feat(admin): searchable sender office picker

Бележки

• „Choose office“ в конфигурацията на куриера е поле с търсене (UI Select от Webcode_Carrier 2.12.0) вместо <select> с всички офиси: търсене по град, име, адрес или номер, подредба по град и име, етикет [номер] ГРАД — име, адрес.
• Model\Config\Source\Office е изтрит — оттам идва сигналът „Конструктор“ горе; нов конструктор няма. Запазената стойност (office_id) не се променя.
• Важи и за „Office“ при наложен платеж (money_transfer_office_id). Старият source model показваше само офисите в един град (зашит city_id 602).

При деплой

• Изисква webcode/module-carrier ^2.12. Чисти generated/ и пусни setup:static-content:deploy за adminhtml (заради JS-а в Carrier).

2.7.2 — 2026-09-24

2.7.2

Спрямо 2.7.1.

Внимание при деплой

• Конструктор: сменена сигнатура на __construct — при деплоя се чисти generated/.
• Setup: data/schema patch — изпълнява се срещу жива база при setup:upgrade.

Комити (1)

• 7cec449 fix: записът на куриера се възстановява сам (RecurringData), patch-ът е идемпотентен

Бележки

• Записът на куриера в webcode_carrier_entity се възстановява сам. Ако таблицата е празна, а отметката на AddEcontCarrierEntityPatch е останала в patch_list (модулът е бил изключван и таблицата е създадена наново), куриерът досега оставаше без запис, докато някой не махне отметката на ръка. Сега новият Setup\RecurringData създава липсващия запис при всеки setup:upgrade: неактивен, както и при първа инсталация.
• AddEcontCarrierEntityPatch::apply() е идемпотентен. При махната отметка и съществуващ запис вече не гърми на уникалния code.

При деплой

• Уточнение към автоматичните предупреждения: никоя съществуваща сигнатура не е сменена. __construct е на новия клас Setup\RecurringData. В production mode е нужен setup:di:compile заради новия клас.
• Съществуващият data patch не се пуска наново. RecurringData при всеки setup:upgrade чете записа по code и създава нов само ако липсва. Съществуващ запис, вкл. is_active, не се пипа.

2.7.1 — 2026-09-24

2.7.1

Спрямо 2.7.0.

Комити (4)

• 80479b3 Merge branch ‘rate-skip-empty-city’ into ‘master’
• 24ffc49 test: set readonly deps via ReflectionProperty (PHPStan)
• e6884c1 fix(rates): don’t ask Econt for a door rate without a receiver city
• 45bbada chore: post-release bump to 2.7.1

2.6.6 — 2026-09-24

2.6.6

Спрямо 2.6.5. Линия 2.6 (Carrier ^2.9.2) — за магазини без Carrier 2.10.

Комити (3)

• a1053f1 Release 2.6.6
• 3d12753 test: set readonly deps via ReflectionProperty (PHPStan)
• 960cc34 fix(rates): don’t ask Econt for a door rate without a receiver city

2.7.0 — 2026-09-19

2.7.0

Спрямо 2.6.5.

Внимание при деплой

• Зависимости: require в composer.json: webcode/module-carrier: ^2.9.2 → ^2.10.

Комити (3)

• f26ce10 Release 2.7.0
• d97c026 chore(carrier-11): изисквай webcode/module-carrier ^2.10
• e6524af feat(carrier-11): отказ на товарителница при отказ на поръчка

Бележки

Модулът вече може да анулира товарителницата при отказ на поръчка.

Празният stub ShippingLabel::delete() (без аргументи) става истински: LabelService.deleteLabels.

⚠️ Еконт е единственият куриер в стека, който съобщава провала със статус HTTP 200 — причината стои в results[].error за всяка товарителница поотделно. Затова тук отговорът се разчита, а не се съди по това дали заявката е хвърлила; липсващ ред за товарителницата се брои за провал, не за успех. Копие на шаблона от другите куриери би оставяло жива товарителница при отказана поръчка, без нито един признак.

Включва се от Магазини → Конфигурация → Webcode Solutions → Delivery Methods → Товарителници. Настройката е обща за всички куриери и е изключена по подразбиране — това издание не променя нищо от само себе си.

Отказ от куриера никога не блокира отказа на поръчката; причината влиза в коментарите на поръчката и в лога.

Внимание при деплой

• Изисква webcode/module-carrier ^2.10 — констрейнтът е стегнат в това издание, защото модулът вече ползва LabelCancellationInterface, който идва с carrier 2.10.0. Деплой без него би дал фатал при зареждане на класа.
• Нужен е cache:flush (заради новия observer и конфигурация в carrier 2.10.0).
• Няма промени по схема и по static content.

Известен проблем

Не е минат реален отказ на жива товарителница при куриера (DoD т. 2–3) — покритието е unit. Първият жив отказ да се наблюдава.

2.6.5 — 2026-09-18

2.6.5

Спрямо 2.6.4.

Комити (1)

• 62237b9 диалогът за товарителница: не сваляй избрания тип на „до адрес“

2.6.4 — 2026-09-18

2.6.4

Спрямо 2.6.3.

Комити (1)

• d98f2f7 опис: price е единична цена, не ред-тотал

2.6.3 — 2026-09-16

• fix(label): непразен inventoryNum на всеки ред от описа

2.6.2 — 2026-09-15

2.6.2

• Опис от поръчката при масово генериране (!32). С включено „Use Itemized Contents“ (use_items_list) товарителниците без диалог вече носят packingList от редовете на поръчката плюс доставката (освен ако я плаща получателят). Без него споразумение за НП по департамент се отхвърляше: HTTP 517 „Необходимо е да въведете данни за фактура или опис за споразумение по департамент.“
• E-fiscal = опис (!33). Мъртвата настройка „E-Fiscal Cash Receipt“ (fiscal_reciept) отпада; коментарът на use_items_list казва, че описът е и електронният фискален бон — както при Speedy.
• Споразумението за НП без validate-number (!33). Кодът е във вида CD164850; валидацията пречеше на записа на секцията в админа.

Изключено use_items_list (по подразбиране) → заявката към Еконт е като в 2.6.1.

2.5.2 — 2026-09-09

Товарителницата на Econt за подател юридическо лице пада с HTTP 517 ExInvalidParam: подател: За юридическо лице, задължително се попълва упълномощено лице., защото заявката не носи senderAgent. 2.5.1 прочете това като липсващ senderClient.molName и затова не лекуваше нищо: профилът от getClientProfiles() обикновено вече носи МОЛ-а, а Econt пак отказва.

Мерено срещу живото API в mode=validate (не създава пратка), с профил, който ВЕЧЕ носи molName:

адрес, без senderAgent → 517 За юридическо лице, задължително се попълва упълномощено лице.
адрес, + senderAgent   → приета
офис,  без senderAgent → 517 същото
офис,  + senderAgent   → приета

Econt го иска независимо откъде тръгва пратката — за офис твърдението обратното дойде от проба с празен senderOfficeCode, който сам по себе си е невалиден (ExInvalidCity).

Какво влиза

• senderAgent се подава като собствен ключ: име от профила (molName) или от carriers/econt/sender_mol_name, връзка от телефоните на профила (резерва contact_telephone), иначе е-пощата.
• Решаващо е има ли име и връзка, а не какво пише в juridicalEntity — профил на фирма, който не обявява полето, иначе оставаше без упълномощено лице и товарителницата пак падаше.
• Юридическо лице без упълномощено лице никъде спира преди заявката, с указание кое поле да се попълни, вместо да получи 517 без посока.
• Подател физическо лице не се пипа.
• Test/Integration стъб с юридическо лице, МОЛ и телефон — дотогава случаят не се изпитваше изобщо.

MR-и: !26, !29 (!27 и !28 са дубликати, писани паралелно, затворени).

2.5.1 — 2026-09-09

Поправя econt-4: Econt отказваше създаването на товарителница за подател юридическо лице с HTTP 517 — подател: За юридическо лице, задължително се попълва упълномощено лице.

resolveSenderClient() подаваше профила от getClientProfiles() дословно, а той не носи molName. До 2.x модулът го слагаше хардкоднат в кода, заедно с името и клиентския номер на конкретна фирма — тоест всеки друг магазин пращаше чужди данни като подател. С рефактора хардкодът падна без заместник.

Ново поле: Authorised person (MOL) — carriers/econt/sender_mol_name, до избора на клиент.

• профил, който сам носи molName, печели пред конфигурацията
• липсва ли и на двете места, а профилът е юридическо лице → ясна грешка кое поле да се попълни, вместо 517 от Econt
• подател физическо лице минава без промяна

Четири нови теста, единият отрицателна контрола. Стубът дотогава връщаше профил само с id и name — случаят не се е изпитвал изобщо.

2.4.1 — 2026-08-25

Register carriers/econt/api_url as a hidden system.xml field, so the API base URL is manageable per environment via bin/magento config:set / env.php (no merchant UI; default stays in config.xml).

2.3.1 — 2026-08-19

Поправено

Теглото на пратката идва от поръчката, не от конфигурацията.

buildContent() подаваше default_weight винаги, когато няма override — тоест при масово генериране и при автоматичното създаване на товарителница. Реалното тегло на поръчката се игнорираше и куриерът дотаксуваше.

Мерено на bilki.bg (Speedy, 30 дни, същият дефект): средно 1.41 кг, максимум 44.13 кг, а 764 от 1756 поръчки (43%) са над 1 кг при default_weight = 1.

Редът на приоритет става override → тегло на поръчката → default_weight, по модела на BoxNow, който единствен от петте куриера го правеше правилно.

2.3.0 — 2026-07-28

Populate webcode_directory_city.region_id during Econt city taxonomy sync via Webcode Carrier RegionResolver, on create and as self-heal for existing rows. Requires carrier ^2.6.

2.2.0 — 2026-07-28

Uses the shared resolvePackagesCount() from Webcode\Carrier\Model\AbstractCarrier (min-1 package-count invariant); drops the private copy. Requires webcode/module-carrier ^2.5. Fixes Econt rejecting sub-1kg carts with “Невалиден брой пакети.” and returning no rate methods.

2.1.0 — 2026-07-25

Delivery Methods config cleanup:

• API base URL default живее в etc/config.xml (carriers/econt/api_url), не като PHP const; ShippingLabel::downloadPdf() минава през getConfigValue(api_url) без инлайн fallback.
• Креденшълите (username/password) вече не са required за Save на секцията; валидацията е бутонът Login & Configure.

2.0.0 — 2026-07-22

Major release — moves onto the shared Webcode_Carrier label pipeline.

⚠ Breaking

• Requires webcode/module-carrier ^2.0.
• Removed the per-carrier vat_rate config: VAT is now reconciled centrally with the store Shipping Prices setting via the shared ShippingPriceTaxAdjuster (module-carrier). Econt returns the raw with-VAT API price.

Changes

• Econt shipment tracking added; removed the CSS logo class in favour of the shared logo.
• money_transfer_method uses MoneyTransferMethod::OFFICE constant instead of a string literal.
• Namespace refactor; currency_code taken from getQuoteCurrencyCode.

Chore

• Proprietary/EULA copyright headers standardized across the module.

Base

• Uses webcode/module-base for the shared Console command.