Тест план: версия от 21.10.2026#

Обхват: всички промени в кода след билд 07.10.2026 до билд 21.10.2026.
Тествайте на копие на реална база данни, обновено с новия билд. Точките с SQL изискват достъп до базата с SQL Server Management Studio.

Обновяване на базата данни#

  1. Скрипт за обновяване.
    Какво е пипано: нова колона за настройка в Администрация » Настройки, нова таблица за история на цените, ново основание за ДДС, корекция на обединени продажби, колона Партида в журнала на изтритите редове.
    Как да се тества:

    • Обновете копие на клиентска база, която има история на обединени продажби. Обновяването трябва да мине без грешки.

    • Обновете празна база (създадена с новия билд). Също трябва да мине без грешки.

    • Пуснете обновяването повторно на вече обновена база. Не трябва да има грешки, нито дублирани основания за ДДС.

Търговска система: продажби#

  1. Автоматично изравняване на количествата с РСД при приключване.
    Какво е пипано: при приключване на продажба количествата се изравняват със свързаните РСД, ако всички складове в тях са с отметка Задължително равнение на количества на продажба със свързаните РСД (Номенклатури » Контрагенти, атрибути на склада).
    Как да се тества:

    • Отметнете настройката за склад А. Направете продажба в редакция с 3 реда и генерирайте РСД. Променете количествата в РСД (едно намалено, едно увеличено, един ред изтрит) и приключете продажбата. Количествата в продажбата трябва да станат като в РСД, а тоталите да се преизчислят.

    • Направете същото с РСД от два склада, единият без отметка. Изравняване не трябва да има; поведението е като досега.

    • Повторете с продукт с алтернативна мярка (кашон = 12 бр.). Количеството в продажбата трябва да е правилно, а не умножено или разделено по коефициента.

    • Повторете с рецептурен (комплектован) продукт.

    • Приключете от списъка Търговска система » Документи за продажба (един и няколко маркирани документа).

    • При приключване с генериране на плащане или товарителница с ръчно въведена сума изравняване не трябва да има.

  2. Наличност в продажба в основна мярка.
    Какво е пипано: сравнението на количеството в реда с наличността в склада вече отчита коефициента на мярката.
    Как да се тества: в продажба добавете ред с алтернативна мярка за продукт със свързан РСД. Задайте количество, различно от наличното, и проверете, че количеството в основна мярка се предлага правилно.

  3. Обединяване на продажби.
    Какво е пипано: след обединяване на документи за продажба данните за документа в пула на документи (дата и ID) се разминаваха. При обновяване на базата се коригират съществуващите случаи, като ръчно променена счетоводна дата се запазва.
    Как да се тества:

    • Маркирайте 2–3 продажби в редакция в списъка и обединете ги (меню Средства). Проверете предупреждението, че документите след първия се анулират.

    • Отворете обединения документ, променете ред, запишете и приключете с генериране на фактура, плащане и счетоводен документ. Не трябва да има грешка PK_stp_DocPool.

    • Обединете продажби с различни дати. Документът трябва да е с датата на първия, а счетоводната дата да съответства.

    • На обновена база отворете стари обединени продажби: те трябва да могат да се приключват и разприключват.

  4. Товарителница с наложен платеж.
    Какво е пипано: ако при генериране на товарителница не е въведена сума за наложен платеж, се взема неплатеният остатък, а не цялата сума.
    Как да се тества:

    • Продажба за 100 €, без плащане. Генерирайте товарителница без сума: наложеният платеж трябва да е 100.

    • Същата продажба с приключено частично плащане 30 €: наложеният платеж трябва да е 70.

    • Изцяло платена продажба: 0.

    • С ръчно въведена сума: взема се въведената сума.

    • Кредитно известие (отрицателна сума): 0, когато знакът на остатъка не съвпада.

  5. Журнал на изтритите редове с партида.
    Какво е пипано: при изтриване на редове се записва и партидата. Започнаха да се записват и изтритите редове от складови документи и документи за покупка. Засегнати са заявки, продажби, POS и мобилното API.
    Как да се тества: изтрийте ред с партида от заявка, продажба, покупка и складов документ, после запишете. SQL: SELECT TOP 20 * FROM sys_LogDeleteRows ORDER BY CD DESC – трябва да има запис за всеки документ с попълнена колона Lot.

Търговска система: покупки#

  1. Отложено ДДС при покупка с повече от един ред за ДДС.
    Какво е пипано: генерирането на счетоводен документ при отложено ДДС създаваше дублиран ред, когато има повече от един ред за ДДС. Продукти, осчетоводявани по 4531 от автоматичния осчетоводител, вече не се местят към сметката за отложено ДДС.
    Как да се тества:

    • Покупка с редове с ДДС 20% и 9% и отложено ДДС: приключете с осчетоводяване. Не трябва да има грешка PK_acc_DocsDetails. В счетоводния документ трябва да има един заглавен ред за отложеното ДДС и отделни редове за всяка ставка.

    • Покупка с две различни основания за ДДС с еднаква ставка: същата проверка.

    • Покупка с продукт, осчетоводяван от автоматичния осчетоводител по 4531 (например митническа декларация): редът по 4531 не трябва да се мести към сметката за отложено ДДС.

    • Регресия: покупка с една ставка и отложено ДДС работи както досега.

  2. Акциз в тоталите на покупка.
    Какво е пипано: когато колоната за акциз не е редактируема, тоталът се изчислява с акциза от настройките на продукта. Във вътрешнофирмени покупки (без кредитни и дебитни известия) се използва акцизът на партидата.
    Как да се тества: създайте покупка с акцизен продукт с вид документ, при който колоната за акциз не е редактируема, и сравнете тотала с акциза на продукта. Повторете с вътрешнофирмен документ и с кредитно известие.

  3. Номерация на протоколи към покупки.
    Какво е пипано: кодът на обекта се използва в номера на протокол само ако няма номератор без обект за съответния префикс.
    Как да се тества: в Администрация » Номератори проверете номераторите с префикс на протоколите (окончание A/E). Генерирайте протокол без такъв номератор, а след това с добавен номератор без обект, и проверете номерата.

Склад и счетоводство#

  1. Автоматична приключителна статия от складов документ.
    Какво е пипано: нова настройка Автоматично генериране на приключителна статия от складов документ в Администрация » Настройки » Група: Генерация на документи.
    Как да се тества:

    • Изключена: генериране на счетоводен документ от складов документ работи както досега, опциите за приключване се виждат.

    • Включена: във формата за генериране опциите за приключване са скрити и се показва текст, че статията се генерира по Счетоводство » Автоматичен осчетоводител. Генерирайте и сверете сметките на приключителната статия с автоматичния осчетоводител.

    • Проверете с поне два вида складови документи (например производство и ревизия).

  2. Осчетоводяване на амортизации за активи без продукт или признак.
    Какво е пипано: генерирането на счетоводни документи за амортизации (Номенклатури » Дълготрайни активи) създава автоматично липсващ продукт и счетоводен признак. При съвпадение на кода с друг продукт се добавя [2]. При съвпадение на името се показва съобщение Невъзможно синхронизиране с Продукти. Вече съществува продукт с име ….
    Как да се тества (подготовка само на тестова база, SQL):

    • Актив без признак: изтрийте реда на актива от nom_Priznaci и генерирайте амортизациите за периода. Документът трябва да се генерира, а признакът да се създаде отново.

    • Актив без продукт и признак: създайте актив директно в nom_Dma (копие на съществуващ с нов ID) и генерирайте. Трябва да се създадат продукт и признак.

    • Код на актива, съвпадащ с код на друг продукт: новият продукт трябва да получи код с [2].

    • Име на актива, съвпадащо с име на друг продукт: очаква се съобщението по-горе, без генериран документ.

    • Регресия: обикновено генериране на амортизации.

  3. Синхронизация на счетоводни признаци с код [2].
    Какво е пипано: при запис на продукт или контрагент кодът на признака вече не се връща към оригиналния, ако признакът е бил създаден с [2] заради съвпадение.
    Как да се тества:

    • В Счетоводство » Счетоводни признаци създайте ръчно признак с код X в категория продукти. Създайте продукт с код X: признакът трябва да е X[2].

    • Редактирайте продукта (име, активност, мярка) и запишете. Не трябва да има грешка, а кодът на признака да остане X[2].

    • Сменете типа на продукта на ДМА и обратно: категорията на признака трябва да се сменя без грешка.

    • Повторете за контрагент (категория контрагенти) и за служител (категория лица).

  4. Ново основание за ДДС 1-09-3.
    Как да се тества: след обновяване проверете в Номенклатури » Референтни номенклатури основание 1-09-3 Без право на ДК: Доставки по чл.82, ал.2-4. Използвайте го в покупка и проверете колоната в дневника за покупки.

Номенклатури#

  1. История на цените в ценовите листи.
    Какво е пипано: всяка промяна на цена в ценова листа се записва в таблицата nom_PriceListsLog.
    Как да се тества: в Номенклатури » Ценови листи променете цена ръчно, с импорт и с Средства » Прилагане нови цени. SQL: SELECT TOP 20 * FROM nom_PriceListsLog ORDER BY CD DESC – трябва да има стара и нова цена за всяка промяна.

  2. Планирани промени в цените.
    Как да се тества: създайте планирана промяна на цена от потребител А и я приложете (по график или от потребител Б). В реда на ценовата листа като последен редактирал трябва да е потребител А.

  3. Закръгляне на цени във формите на ценовите листи.
    Какво е пипано: цената с ДДС се закръглява с прецизността на продукта само ако продуктът няма кратност, иначе до 2 знака.
    Как да се тества: въведете цена за продукт без кратност и за продукт с кратност, в обикновена и в клиентска ценова листа. Запишете и сравнете показаната цена с тази след повторно отваряне. Трябва да са еднакви.

  4. Клиентска ценова листа: поле за автоматично генериране.
    Как да се тества: в клиентска ценова листа с редове, без отметка за автоматично генериране, сменете таба. Полето трябва да е заключено. В празна листа то трябва да е редактируемо.

  5. Бързо отваряне на карти на контрагенти и продукти.
    Как да се тества: отворете карта на контрагент и продукт с много обекти, кодове и цени и сравнете времето с предишния билд. Проверете, че всички табове показват същите данни като преди.

  6. Номератори: фиксирана колона с префикса.
    Как да се тества: в Администрация » Номератори превъртете хоризонтално. Колоната с префикса трябва да остава видима.

  7. Съобщения за грешка с име на списъка.
    Как да се тества: опитайте да изтриете използвани записи – мярка, валута, държава, тип контрагент, тип продукт, длъжност, вид транспорт. Съобщението трябва да посочва име на списъка на български, а не име на таблица.

Справки, API и интеграции#

  1. Справка за реализация на продажбите.
    Какво е пипано: оптимизирана е скоростта. Премахната е временно добавена категория. Добавен е параметър за връщане само на основния резултат (за API).
    Как да се тества: изпълнете справката за всички категории (продажби към фактури, фактури към продажби, продажби към склад, по части, само продажби), с и без филтри по продукти, контрагенти, обекти и дименсии и с показване на дименсии. Сравнете резултатите с предишния билд за същия период. Трябва да са еднакви, а времето – по-кратко.

  2. Външно API: продажби, приходи и разходи, брутен марж.
    Какво е пипано: нови методи. Коригирана е XML структурата на продажбите. Полето за разход е преименувано на ExpenseAmount (беше Expenseamount). Справката за брутен марж има варианти без метаданни за API.
    Как да се тества: през API конектора извикайте методите за продажби, приходи и разходи и марж по продукти и по контрагенти. Проверете XML/JSON структурата, имената на полетата и сумите спрямо справките в системата.

  3. EDI поръчка: име на XML елемент.
    Внимание: съобщението към промяната казва преименуване към OrderedUnitPackSize, но кодът вече генерира OrderedUnitPacksize.
    Как да се тества: генерирайте EDI поръчка от заявка и проверете името на елемента спрямо спецификацията на партньора. При разминаване докладвайте.

  4. Синхронизация с WebDox.
    Какво е пипано: синхронизацията на заявки вече не създава папка Документи WebDox в медия каталога. Обновени са процедурите за статусите на продажби и заявки.
    Как да се тества: от Средства » Синхронизация с външни системи в списъците със заявки и продажби пуснете синхронизация и проверете статусите и прикачените документи.

  5. Експорт за BI анализи.
    Какво е пипано: доставната цена се взема от историята на цените. Коригирана е себестойността на съставни продукти.
    Как да се тества: пуснете експорта и сравнете доставните цени и себестойността на съставен продукт с ръчно изчислени.

Общи промени в интерфейса#

  1. Детайлни форми: въпрос за запис преди проверка на полетата.
    Как да се тества: в карта на продукт въведете в поле с избор от номенклатура текст, който не съществува, и затворете формата. Първо трябва да се появи въпрос за запис. При Не формата се затваря без грешка. При Да се показва проверката на полето.

  2. Поле за избор от номенклатура: изчистване на текста.
    Как да се тества: изтрийте текста в поле за избор (например контрагент в документ). Не трябва да се задействат промени и автоматични попълвания, както при избор на нова стойност.

  3. Прозорец за избор: повторно отваряне.
    Как да се тества: натиснете бързо няколко пъти бутона за избор (или F4) в поле за продукт или контрагент. Трябва да се отвори само един прозорец, без грешка Invalid form state.

  4. Поставяне (Paste) в таблици.
    Как да се тества:

    • Копирайте от Excel колони с код на продукт и количество и ги поставете в редовете на продажба и покупка. Продуктите трябва да се намерят.

    • Поставете несъществуващ код: не трябва да има грешка ‘Value’ property can not be change in this context.

    • Поставете 200+ реда: таблицата трябва да се превърта и опреснява. Затварянето на формата по време на поставянето трябва да прекъсне процеса без грешка.

    • Поставете и в колона, която не е за избор от номенклатура.

  5. Прозорец за изчакване.
    Как да се тества: стартирайте дълга операция (голяма справка или списък). Докато се показва прозорецът за изчакване, кликайте в други прозорци на системата и пишете. Действията трябва да се пренебрегнат. Бутонът за прекъсване и Esc трябва да работят.

  6. Начален екран и WebView2.
    Как да се тества:

    • Затворете системата веднага след стартиране, докато се зарежда началният екран. Не трябва да има забавяне или грешка.

    • На компютър без Microsoft WebView2 системата трябва да предложи инсталиране.

  7. Смяна на клавиатурна подредба в текстови полета.
    Как да се тества: в поле за забележка с форматиране сменете подредбата с Alt+Shift. Не трябва да се отваря контекстно меню и да се изпълнява действие на Shift+F10.

  8. Стабилност и памет.
    Как да се тества:

    • Работете продължително (2+ часа) с отваряне и затваряне на документи, справки и номенклатури.

    • Превключвайте между отворени прозорци от лентата с менюта.

    • След това проверете лога с грешки. Не трябва да има recordset(s) leaked, Object leak detected и грешки от SetFocus.

Dreem POS#

  1. Банков терминал по USB: възстановяване на връзката.
    Какво е пипано: при грешка при изпращане към терминала POS затваря и отваря порта (до 3 опита) и изпраща данните отново. При неуспех веднага показва Прекъсната връзка с устройство (COMn).
    Как да се тества:

    • Нормално плащане с карта, отказана карта и прекъсване от потребителя: работят както досега.

    • По време на плащане извадете USB кабела на терминала за 1–2 секунди и го върнете. Плащането трябва да продължи и продажбата да се приключи.

    • Извадете кабела и не го връщайте. До около 10 секунди трябва да се покаже съобщението за прекъсната връзка, а продажбата да остане неприключена.

    • След връщане на кабела следващото плащане трябва да работи без рестарт на POS.

    • Повторете за всички поддържани протоколи на терминали.

  2. Избор на принтер по подразбиране.
    Как да се тества: на компютър с фискално устройство и принтер за етикети (зададен като принтер по подразбиране в Windows) стартирайте POS без изрично зададен принтер. Трябва да се избере фискалното устройство.

  3. Отдалечена поддръжка.
    Как да се тества: свържете се към POS чрез модула за отдалечена помощ. Проверете картината, мишката и клавиатурата.