Новости

1.3.1 — 2026-10-06

Връщане: „Поръчката е анулирана след връщане на пратка N.“ се записва преди cancel() и е видим за клиента — влиза като причина в мейла за отказ (order-cancellation 1.2.0). MR !17

1.3.0 — 2026-10-02

1.3.0

Спрямо 1.2.1.

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

• DI: di.xml е променен — при деплоя се чисти generated/.

Комити (2)

• f08ecd9 Release 1.3.0
• bf8c34d feat: push канал за статуси (webhook на куриера)

Бележки

• Нов push канал за куриерски статуси: Api\StatusReceiverInterface::receive() приема един статус (от webhook на куриера), намира пратката по carrier code + track номер и го прилага по същия път като poll-а — снапшот, история, webcode_carrier_shipment_* събития и същите предпазители (терминално замразяване, по-старо събитие не презаписва по-ново, рециклиран номер не наследява COD).
• Нов маркер Api\PushProviderInterface: провайдър с него остава в ProviderPool (номенклатурата е оттам), но cron-ът update го прескача без нито една заявка към куриера.
• Прилагането на статус е изнесено от Service\UpdateStatus в Service\ApplyStatus. Поведението на poll-а не се променя.
• Първи консюмър: webcode/module-carrier-shipment-lifecycle-boxnow (BoxNow tracking webhook).

При деплой

• Сменен конструктор на Service\UpdateStatus + нова preference в di.xml → чисти generated/. Схема и data patch няма.

1.2.1 — 2026-09-24

1.2.1

Спрямо 1.2.0.

Комити (2)

• 7bcb2df Release 1.2.1
• 5b5a9cc fix(status): updated_at вече се мести при запис на снапшота

Бележки

• updated_at на снапшота вече се мести при запис (!15). Досега замръзваше на момента на създаване: зареденият снапшот връщаше стария updated_at в UPDATE-а като изрична стойност и MySQL не прилагаше ON UPDATE CURRENT_TIMESTAMP. Всяка проверка „кои пратки не са мръднали“ по updated_at лъжеше, а getByTrackNumber() подрежда по него. Мерено на aptekanove.bg: пратка, стигнала до ЛЛЦ на 23.09, носеше updated_at от 21.09.

При деплой

• Няма промени по схемата, DI или конструкторите. Съществуващите редове се оправят сами при следващата смяна на статуса им.

1.2.0 — 2026-09-23

1.2.0

• feat: сверката на наложения платеж пита куриера каква сума е събрал (ExpectedCodAmountProviderInterface). При платец получателя куриерът превежда само стоката, без доставката. Досега всеки такъв превод излизаше „частичен“ и поръчката не ставаше платена (ndbg: ~8 800 предупреждения на ден). (!13)

1.1.0 — 2026-09-09

Куриерът вече може да декларира своите статуси.

Мапингът „куриерски статус → статус на поръчката“ се настройва през падащо меню, което дотук се пълнеше само от вече видяното в данните. На магазин, който още не е тракирал, то излизаше празно — тоест мапингът беше неконфигурируем точно тогава, когато трябва да се настрои: преди да тръгне тракването. Новият договор Api\StatusNomenclatureInterface позволява на провайдъра да издаде таксономията на своя куриер предварително; менюто вече показва декларираното плюс наблюдаваното, групирано по куриер. Speedy bridge-ът декларира своите 15 статуса от своята 1.1.0.

Филтърът „Carrier Status“ в Shipment Tracking и Orders гридовете ползва същия слят списък. Причината не е симетрия: снапшотът пази само последния статус на пратка, тъй че само-наблюдаваният списък трепти според това коя пратка къде е в момента — мерено на прод, 11 от 15 реални статуса в даден час. Филтърът по КУРИЕР остава само на наблюдаваното, защото куриер без нито една пратка е трайно празна опция, а не преходна.

Shipment Tracking гридът получава валута за COD сумите, номер-линк към пратката и row действия.

Ново в публичния API — затова 1.1.0, а не 1.0.10: Api\StatusNomenclatureInterface и ProviderPoolInterface::getAll(). Номенклатурата трябва да е евтина и без I/O: вика се при всяко рендиране на конфигурационния екран и на двата грида, за всеки регистриран куриер.

1.0.8 — 2026-09-05

UpdateStatusTest отчита новото delivery_status_changed събитие. Тагът 1.0.7 беше червен в PHPUnit:unit (RefundOnReturnTest); master е зелен от 02.09.