Опис версії 2022.0.36

Доопрацювання

77957 — Налаштування → Параметри → Додаткові функції → Верифікація дисконтної картки через смс. 

Додано два нові налаштування:

• "Для вибору клієнта в реалізації та поверненні" (ввімкнена за замовчуванням). Це налаштування дозволяє верифікувати клієнта через смс при проведенні операцій реалізації та при поверненні товарів. Клієнту надсилається смс повідомлення для підтвердження.
• "Для підтвердження списання бонусів" (за замовчуванням вимкнена). Це налаштування дозволяє увімкнути додаткове підтвердження списання бонусів через смс. Коли клієнт хоче списати бонуси на оплату товарів в Реалізації чи Торгівлі з випискою рахунка, після введення кількості бонусів клієнту надсилається повідомлення з кодом. Текст повідомлення такий самий, як і при верифікації в Реалізації чи Поверненні. Без введення правильного коду списання бонусів неможливе. Якщо в рамках одного документа та одного клієнта вже підтвердили списання бонусів, то при повторному списанні (наприклад, інші товари) відправка повідомлення не потрібна. Якщо в картці клієнта відсутній номер телефона або номер вказаний некоректно, повідомлення не надсилається і списати бонуси неможливо.

Це налаштування забезпечує додатковий захист від несанкціонованого списання бонусів, оскільки продавець не може оплатити товар бонусами без введеного коду від покупця.

187892 — Аналіз → Аналіз продажу фіскального товару → Друк зведеної податкової накладної

• При створенні зведеної податкової накладної прибрали вимогу обов'язкового вибору центру обліку.

Це дозволяє створювати зведені податкові накладні для товарів незалежно від центру обліку, з якого вони були продані. Наприклад, підприємець може створити податкову накладну, охоплюючи всі продажі, без необхідності вручну вибирати центр обліку.

• На формі редагування податкової накладної:

Поле "Відправник (Продавець)" зробили невидимим. Це спрощує форму, прибираючи зайві поля.

В полі "Отримувач (Покупець)" буде вказано "Отримувач", якщо на формі "Аналіз продажу фіскального товару" було вибрано значення для фільтра "Отримувач". В іншому випадку буде вказано системний покупець. Це автоматизує процес заповнення форми, зменшуючи кількість ручних операцій.

Додано перемикач "на Покупця", який відображається, якщо в якості покупця було вказано іменованого клієнта у фільтрі "Отримувач" на формі "Аналіз продажів фіскального товару" при створенні накладної (за замовчуванням вимкнений). При активації налаштування в якості покупця підставляється системний покупець, при вимкненні — повертається іменований покупець.

В полі "Підприємство" буде вказано підприємство, якщо на формі "Аналіз продажів фіскального товару" було обрано значення для фільтра "Підприємство". В іншому випадку поле буде порожнім з можливістю вибору. Це полегшує заповнення форми, автоматично підставляючи підприємство.

На формі "Облік податкових накладних" на вкладці "Зведені накладні" додано поле "Підприємство". Також для нових зведених накладних не буде відображатися значення в полях "Відправник" та "Отримувач" для податкових накладних та коригувальних розрахунків відповідно. Це забезпечує більш зручний облік і сортування зведених накладних.

При експорті файлу податкової накладної в файл XML необхідні параметри для продавця (ІНН, ПІБ, ЄДРПОУ) будуть братися лише з налаштувань підприємства, вказаного при створенні податкової. Це гарантує, що всі необхідні дані автоматично підставляються з правильних налаштувань, зменшуючи можливість помилок і прискорюючи процес експорту.

189356 — Синхронізація з Новою поштою.

На форму створення ТТН Нової пошти додали налаштування "Послуги" (доступно для типів вантажу "Вантаж" та "Посилка"), яке має підлеглі налаштування "Без коробки" та "Пакування" (доступно лише для посилок з типом доставки "Відділення — Відділення").

• Послуга "Пакування":

Передбачає розміщення відправлення у найбільш підходящий вид пакування, що забезпечує його надійне транспортування, складування, зберігання та захист.

Пакування здійснюється в упаковку з асортименту, запропонованого компанією Нова пошта.

При активації послуги "Пакування" стає доступним поле для вибору виду упаковки, інформація отримується з сервера Нової пошти. У переліку доступні варіанти відповідно до вказаних розмірів посилки.

• Ідентифікація послуг:

В таблицю параметрів посилки додано іконки ідентифікації, яка послуга додана до відправлення (без коробки або пакування).

189553 — Документ → Торгівля з випискою рахунка → Оплати клієнтів → Оплати.

• Перейменування дії "Друк фіскальних чеків за передоплатами":

Дію перейменовано на "Друк фіскальних чеків". Тепер ця форма може відображати також оплати рахунків, за якими створені видаткові накладні.

У пункті меню Налаштування потрібно активувати пункт "Відображати оплати за рахунками з видатковими накладними" (за замовчуванням вимкнено). Після активації стає доступним другий пункт налаштування "При наявності видаткової накладної, формувати чек за видатковою".

Якщо не друкувався чек ні при внесенні передоплати за рахунком, ні при створенні видаткової накладної, можна надрукувати чек за передоплатою або за видатковою накладною. Якщо оплата вносилася після створення видаткової накладної, чек буде надруковано за видатковою накладною.

При друку чека за видатковою накладною з цього режиму вказується форма оплати (готівкова або безготівкова), на відміну від друку чека з вкладки Видаткова накладна, де вказано — Попередня оплата.

• Додано два додаткових фільтри "Каса" та "Розрахунковий рахунок":

Це дозволяє фільтрувати оплати за рахунками залежно від джерела оплати, що спрощує пошук потрібних оплат.

• Додано колонку "Останній контакт" та фільтр "Стан контакту за рахунком":

У налаштування видимості колонок таблиці додано колонку "Останній контакт". Після увімкнення видимості цієї колонки стає доступним фільтр "Стан контакту за рахунком".

• Виправили розрахунок мінімального та максимального залишку у "Склад" — "Реєстр складських запасів":

Виправили помилку, коли у розрахунку кількості реалізацій використовувалися неактивні реалізації, що впливало на точність розрахунків мінімального та максимального залишку.

Гнучкість у друку фіскальних чеків:

Підприємці тепер можуть вибирати, друкувати чек за передоплатою або за видатковою накладною. Наприклад, якщо клієнт зробив передоплату, але ще не отримав товар, підприємець може надрукувати чек за передоплатою. Якщо ж товар був відвантажений і оплата проведена пізніше, можна надрукувати чек за видатковою накладною.

Зручність фільтрації оплат:

Додавання фільтрів "Каса" та "Розрахунковий рахунок" дозволяє швидко знаходити необхідні оплати, що підвищує ефективність роботи з фінансами. Наприклад, бухгалтер може легко знайти всі оплати, зроблені через конкретну касу або розрахунковий рахунок, для перевірки звітності.

Ідентифікація останнього контакту:

Колонка "Останній контакт" та фільтр "Стан контакту за рахунком" допомагають швидше ідентифікувати потрібні документи. Це корисно для менеджерів, які можуть відстежувати останні контакти з клієнтами та відповідно реагувати на них, забезпечуючи своєчасне обслуговування.

Точний облік товарів на складі:

Виправлення розрахунку мінімального та максимального залишку забезпечує точний облік товарів, що допомагає уникнути помилок у замовленнях і плануванні запасів. Наприклад, керівник складу може бути впевнений, що дані про залишки товарів відображають актуальну інформацію, що сприяє ефективному управлінню складськими запасами.

188807 — Налаштування → Програмний РРО.

До переліку приватних ключів, які підтримує програмний РРО Торгсофт, додано формат PFX.

Це розширює можливості роботи з програмним РРО та використовувати приватні ключі формату PFX для підписання електронних документів. 

188866 — Налаштування → Параметри → Чек → Тип чека → Фіскальний → Налаштування робочого місця → Фіскальний реєстратор.

1. У налаштування фіскального реєстратора робочого місця в перелік "Тип фіскального реєстратора" додали пункт E-POS Systems Узбекистан. При виборі такого фіскального реєстратора з'являються наступні поля для заповнення: 

Назва компанії (як зареєстрований в системі),

Адреса реєстрації каси, 

ІПН компанії (до якої належить каса), 

Номер телефону компанії, 

Ширина чека. 

Обов'язкові поля для заповнення підсвічені червоним.

2. Для цього типу фіскального реєстратора доступні дії: Відкрити зміну, Надрукувати Х-звіт, Надрукувати Z-звіт. Чек формується на стороні онлайн-каси у вигляді PDF, а програма його друкує.

3. На форму Вид товару → Динамічні характеристики товару → Додати параметри по шаблону додано розділ "Узбекистан", який містить необхідні характеристики:

ІКПП (ідентифікаційний код продукту та послуги за Єдиним електронним каталогом),

Код упаковки продукту, 

Одиниця вимірювання товару. 

Для успішного друку товарів в чеку потрібно, щоб ці системні динамічні характеристики були заповнені.

4. Підтримується робота з маркованим товаром за умови додання відповідних динамічних характеристик.

5. Неможливо повернути товари через реєстратор, якщо вони не були через нього продані.

Це оновлення забезпечує повну інтеграцію з фіскальним реєстратором E-POS Systems Узбекистану, дозволяючи підприємцям з Узбекистану використовувати Торгсофт для обліку та друку фіскальних чеків відповідно до місцевих вимог.

Покращення

188380 — Налаштування → Перелік додаткових функцій → Банківський термінал. 

Оптимізували роботу з банківським терміналом для запобігання "зависанню" при проведенні оплати за протоколом JSON(TCP/COM), що забезпечує швидке та надійне завершення процесу оплати.

188934 — Налаштування → Параметри → Додаткові функції → Банківський термінал → Мерчант (операція) банківського термінала. 

Для терміналів за протоколом PosApi закрили дію "Тест підключення" та додали "Тест з'єднання з мерчантом". Це забезпечує коректне тестування підключення, якщо на терміналі зареєстровано декілька мерчантів (TerminalID).

188959 — Налаштування → Параметри → Додаткові функції → Банківський термінал. 

Виправили можливість додавання більше одного терміналу з однаковою IP адресою, але з різними портами для протоколу PosApi. Це дозволяє підключати декілька терміналів на одній IP адресі, що розширює гнучкість налаштувань і підвищує зручність використання.

190049 — Налаштування → Параметри → Додаткові функції → Банківський термінал. 

Для терміналів за протоколом JSON виправили обробку відповіді при наявності подвійних лапок у назві торгової точки. Це усуває помилки "Не вдалося розпарсити відповідь JSON" і забезпечує стабільну роботу з терміналами.

189355 — Торгсофт → Бонусна система з терміном дії. 

Виправили некоректне списання бонусів при поверненні товару, якщо термін дії бонусів ще не минув. Оптимізували автоматичний розрахунок невикористаних бонусів, термін дії яких закінчився, та оновлення даних у Маркетинг → Клієнти. Це забезпечує точний облік бонусів і коректну роботу бонусної системи.

189154 — Документ → Прихід товару → Введення цін для товару цієї накладної. 

Виправили відображення дробових частин у полі "Кількість", щоб кількість і підсумок по колонці відповідали даним у списку товарів накладної.

188671 — Документ → Повернення → Повернути гроші. 

Виправили розрахунок суми реалізації, сплаченої подарунковими сертифікатами, у повідомленні-попередженні при внесенні грошей за повернення. У випадках, коли товар однієї реалізації оплачувався кількома сертифікатами, сума в повідомленні завищувалася кратно кількості використаних сертифікатів.

Також виправили некоректну роботу механізму повернення грошей після натискання кнопки "Ні" у повідомленні-попередженні. Кнопка "Повернути гроші" переставала реагувати, а дія "Повернути гроші (F6)" створювала документ повернення без внесення грошей.

Ці зміни забезпечать правильний розрахунок сум і стабільну роботу механізму повернення грошей, зменшуючи ризик помилок.

183178 — Журнал зміни документів. 

Виправили неправильне визначення типу документа після виконання дії "Скасувати" на формі "Реалізація". Тепер у журналі відображається правильний тип документа.

188970 — Документ → Прихід товару → Імпорт. 

Виправили проблему, через яку при імпорті товару з увімкненим параметром "Оновлювати параметри товару" значення поля "УКТ ЗЕД" затиралося, навіть якщо це поле не імпортувалося. Тепер значення "УКТ ЗЕД" зберігається, що забезпечує коректність даних при оновленні параметрів товарів.

189497 — Торгсофт → Синхронізація з інтернет-магазином.

Виправили проблему, коли при синхронізації через файл до нього потрапляли лише роздрібна та оптова ціни у валюті для першої валюти. Тепер у файлі синхронізації коректно відображаються всі необхідні валютні ціни. 

Це корисно для підприємців, які працюють з кількома валютами, оскільки забезпечує правильне відображення цін у всіх валютах на сайті. Наприклад, якщо підприємець продає товари як за долари, так і за євро, синхронізація гарантує, що клієнти побачать коректні ціни в обох валютах.

186334 — Торгсофт → Маркетинг → Клієнти. 

На формі редагування клієнта для поля "Дата видачі дисконтної картки" прибрали дію "Очистити". Це зроблено, оскільки, якщо це поле не заповнене, при натисканні "Записати" програма все одно встановить поточну дату.

Це корисно для підприємців, оскільки усуває зайві дії та зменшує ризик помилок. Наприклад, підприємець може бути впевнений, що дата видачі дисконтної картки завжди буде правильною та актуальною, без необхідності вручну очищувати та перевіряти це поле. 

189024 — Налаштування → Контрагент. 

На формі редагування "Контрагент" у вкладці "Розрахунковий рахунок" виправили проблему, коли розрахункові рахунки контрагента не відображалися, якщо користувач мав рольові обмеження та активне обмеження доступу до розрахункових рахунків.

Це забезпечує доступ до важливої інформації навіть при використанні обмежень для окремих ролей. Наприклад, менеджер з обмеженим доступом тепер може бачити розрахункові рахунки контрагента.

189074 — Торгсофт → Торгівля з випискою рахунка.

Виправили проблему, коли при копіюванні рахунка (Документ → Торгівля з випискою рахунка → вкладка Рахунок → дія Копіювати рахунок) у новий рахунок переносилася сума оплати бонусами по товарах.

Також у вкладці Комерційна пропозиція таблиці "Товар комерційної пропозиції" прибрано колонку "Сплачено бонусами", оскільки комерційна пропозиція не може бути оплачена бонусами.

Це доопрацювання запобігає помилкам при оплаті товарів бонусами. Наприклад, коли менеджер копіює рахунок для іншого клієнта, він може бути впевнений, що сума оплати бонусами не буде перенесена, що забезпечує коректний облік бонусів і уникнення можливих фінансових втрат.

189019 — Торгсофт → Ліцензія

Виправили проблему, коли в румунській локалізації за пунктом меню Допомога → Ліцензія в браузері відкривався текст ліцензії англійською мовою, а не румунською.

Це корисно для підприємців, які використовують румунську локалізацію, оскільки тепер вони можуть читати текст ліцензії рідною мовою. Наприклад, румунські користувачі отримують точну та зрозумілу інформацію про умови ліцензії без необхідності перекладу, що полегшує розуміння і дотримання ліцензійних угод.

189135 — Документ → Виробництво готової продукції → Виробничі акти → Друк маршрутного листа. 

Виправили проблему, через яку при друку маршрутного листа в друковану форму не підтягувалися дані: штрих-код, дата, кількість, номер маршрутного листа.

Тепер працівники виробництва можуть бути впевнені, що всі необхідні дані включені в маршрутний лист, що спрощує відстеження і контроль виробничих процесів, зменшує ризик помилок.

190000 — Торгсофт → Масова розсилка. 

Виправили проблему, коли при відкритті форми редагування Масова розсилка (Маркетинг → Масова розсилка) у списку шаблонів масової розсилки відображалися лише шаблони для стандартного типу розсилки. Це призводило до відсутності потрібного шаблону при редагуванні розсилки не стандартного типу. Тепер у списку шаблонів при створенні нової розсилки відображаються лише шаблони стандартного типу, а при редагуванні — шаблони, що стосуються конкретного типу масової розсилки.

188571 — Торгсофт → Налаштування → Налаштування ролей.

Виправили проблему, коли в налаштуваннях ролей для пункту меню головної форми Товарознавство → Повний перелік товарів та послуг була відсутня можливість встановити права доступу до компонентів відповідної форми.

189153 — Налаштування → Налаштування ролей

Виправили проблему, коли не можна було налаштувати доступ до поля "Відділ" на формі редагування "Співробітник" у вкладці "Виробництво".

Це корисно для підприємців, оскільки дозволяє більш гнучко керувати правами доступу співробітників. Наприклад, тепер адміністратор може обмежити або надати доступ до поля "Відділ" для певних користувачів, що дозволяє забезпечити належний рівень конфіденційності й безпеки. Це також допомагає уникнути випадкових або несанкціонованих змін в інформації про відділи, що підвищує точність і надійність обліку даних у виробництві.

190054 — Торгсофт → Налаштування ролей. 

Виправили проблему, коли в налаштуваннях ролей не можна було надати доступ до колонок "Сума середнього чека фактична" та "Сума середнього чека запланована" для обмеженої ролі в розділі Розрахунок заробітної плати → Планування → План продажів.

Це дозволяє точніше контролювати доступ до важливих фінансових показників. Наприклад, керівники відділів тепер можуть надати доступ до цих колонок лише певним працівникам, що дозволяє більш ефективно планувати та контролювати виконання планів продажів.

188086 — Налаштування → Параметри → Чек → Решта на картку.

1. Виправили проблему зі значенням поля "Текстова назва для Решти на карту". При повторному відкритті форми налаштувань відображалося старе значення, а не те що було введено перед цим. Тепер введене значення зберігається і відображається коректно.

2. Виправили встановлення ознаки фіскальності для виду товару "Решта на карту". При початковому створенні послуги ознака фіскальності встановлювалася порожньою, замість того щоб братися з виду товару. Тепер ознака фіскальності встановлюється правильно відповідно до виду товару.

3. Додали переклад для значення за замовчуванням "Текстова назва для Решти на карту". При зміні мови програми, якщо значення поля не змінювалося, відображатиметься перекладене значення "Решта на карту".

Введені назви для "Решти на карту" залишаються незмінними при повторному відкритті налаштувань, що зменшує можливість помилок і покращує точність обліку. Крім того, правильне встановлення ознаки фіскальності гарантує відповідність податковим вимогам, а підтримка перекладу значення за замовчуванням покращує зручність використання програми в різних локалізаціях.

187369 — Торгсофт → Оновлення. 

Перед оновленням тепер автоматично закриваються всі відкриті довідки Торгсофт, щоб уникнути проблем з оновленням. Виправили помилку пам'яті, яка виникала при виклику довідки F1 з додаткової реалізації. Це забезпечує безперебійне оновлення та стабільну роботу програми.

170503 — Торгсофт → Обмеження продажу товару. 

Виправили проблему, коли при встановленому обмеженні на продаж товару іменованому клієнту (Товарознавство → Обмеження продажу товару), у разі перевищення ліміту, користувачеві відображалося некоректне повідомлення. Це відбувалося, якщо в Налаштування → Параметри → Документ не було встановлено налаштування "Знімати товар зі складу при додаванні в реалізацію". 

188579 — Торгсофт → Документ → Реалізація → Оплатити (F6).

Виправили проблему, коли на формі оплати при змішаній оплаті готівкою та безготівково під час зміни суми "До оплати" за допомогою випадаючого калькулятора не змінювалися значення полів "До оплати б/г" та "Решта".

Це доопрацювання забезпечує точний розрахунок сум при змішаній оплаті. Наприклад, касир тепер може правильно обчислити суми готівкової та безготівкової оплат, що зменшує ризик касових помилок.

157945 — Торгсофт → Звіт з реалізованого товару.

• Виправили включення даних з Торгівлі з випискою рахунка у звіт:

Виправили помилку, коли у звіті "Звіт по реалізованому товару" були присутні дані з торгівлі з випискою рахунка. Тепер ці дані виключено з наступних розділів звіту:

Повернення неоплаченого товару

Товар, відпущений у борг (VIP-клієнту)

Реалізація та повернення звичайним клієнтам без оплати

Повернення товару з виплатою грошей

Оплати за товар, взятий у борг, погашення боргів клієнтів, повернення грошей клієнту, оплати подарункових сертифікатів

• Додано нове налаштування до діалогу звіту:

До настроювального діалогу звіту з реалізованого товару додано опцію "Відображати дані з торгівлі з випискою рахунка" (за замовчуванням вимкнено, вибір запам'ятовується в реєстрі).
Якщо її включити, у звіті з'являються додаткові набори даних і підсумки за ними:

Реалізації та повернення через торгівлю з випискою рахунка

Оплати та повернення оплат готівкою у торгівлі з випискою рахунка

Оплати та повернення оплат на розрахунковий рахунок у торгівлі з випискою рахунка.

189068 — Торгсофт → Налаштування → Перелік додаткових функцій. 

Виправили відображення слова "Купити" в таблиці на формі Налаштування → Список додаткових функцій у румунській локалізації програми. Також змінено шрифт на формі на стандартний шрифт програми. Покращене відображення інтерфейсу румунською мовою робить програму зручнішою для румунських користувачів. 

188713 — Торгсофт → Перенесення основних даних. 

Виправили проблему, коли при перенесенні основних даних (Файл → Перенесення основних даних у нову БД → Відкрити...) не знаходило центр обліку, якщо номер телефону центру обліку в базі даних, де відбувалося збереження, не збігався з номером телефону центру обліку в базі даних, куди завантажували інформацію.

188376 — Товарознавство → Повний перелік товарів та послуг → Послуги → Нова послуга.

Виправили проблему, коли можна було створити більше однієї послуги з неунікальним артикулом при ввімкненій перевірці унікальності артикулів. 

Тепер кожна послуга матиме унікальний артикул, що спрощує облік і управління послугами.

189411 — Налаштування → Користувачі → Змінити. 

Змінили формат підказки (хінту) для елемента "Дозволено бачити стан за складами". Тепер текст підказки змінюється залежно від вибраного значення, що полегшує налаштування доступу для користувачів і забезпечує точне розуміння прав доступу до інформації про стан складів.

188956 — Документ → Прихід товару → Товари накладної → Змінити параметри приходу.

Виправили проблему, коли при закритті форми редагування приходу могла закриватися також і форма приходу товару (список товарів). Це траплялося, якщо в сеансі роботи хоча б раз було змінено центр обліку на формі редагування приходу. Аналогічна проблема могла виникати під час роботи з накладною внутрішньої передачі.

Це забезпечить стабільність роботи з приходом товару і внутрішніми накладними, запобігаючи випадковому закриттю форм.

189128 — Документ → Прихід товару → Товари накладної.

Виправили проблему, коли некоректно працював фільтр за найменуванням товару у формі "Список товару". Помилка виникала під час пошуку товару з апострофом у назві, що призводило до появи помилки типу "[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]Incorrect syntax near 'хххх'.", де "хххх" — частина назви товару після апострофа.

Це покращить точність пошуку товарів, щоб безпомилково знаходити товари з апострофами в назві.

186969 — Налаштування → Програмний РРО → Налаштування програмного РРО.

Виправили проблему тривалого відкриття та оновлення даних у вкладці "Налаштування програмного РРО". 

Додали формальну ознаку відкритої зміни, яка встановлюється при відкритті або закритті зміни. У групу дій додані дві нові дії: "Встановити формальну ознаку відкритої зміни" та "Встановити формальну ознаку закритої зміни". Ці дії взаємовиключні та доступні у відповідних станах. При ручному або автоматичному завантаженні чеків визначається і встановлюється ознака закритої або відкритої зміни за старим алгоритмом (зміна відкрита, якщо є чек відкриття зміни, за яким немає чека закриття зміни, і його локальні номери більше за номер останнього чека закриття зміни).

188836 — Програмний РРО.

Виправили проблему, коли можна було встановити ключ касира, сертифікати якого були відкликані. 

Це запобігає використанню недійсних ключів касира, що підвищує безпеку та відповідність вимогам. Тільки актуальні та дійсні ключі використовуються для роботи з пРРО.

190055 — Документ → Прихід товару → Розподіл товару.

Виправили проблему, коли при відкритті форми "Розподіл товарів за торговельними точками" з'являлося повідомлення "Integer overflow".

189530 — Документ → Торгівля з випискою рахунка → Видаткова накладна → Друк накладної → Надрукувати видаткову накладну.

Виправили проблему, коли під час перегляду або друку видаткової накладної могла з'являтися помилка "Could not convert variant of type (Null) into type (OleStr)". Це відбувалося, якщо до шаблону видаткової накладної було додано змінну "Умова доставки", але цей параметр не був заповнений для рахунку.

Тепер видаткові накладні коректно друкуються і переглядаються, навіть якщо параметр "Умова доставки" не заповнена.

188238 — Розрахунок зарплати → Рейтинг співробітників.

Виправили проблему, коли в рейтингу співробітників могла некоректно відображатися кількість відпрацьованих днів для співробітників, які працювали в нічну зміну і реєстрували прихід та завершення в різні дні. Через це кількість відпрацьованих днів могла подвоюватись. Тепер кількість відпрацьованих днів відповідає кількості зареєстрованих приходів.

Це забезпечує точніший облік відпрацьованих днів для нічних змін. Наприклад, якщо співробітник працює в нічну зміну, його відпрацьовані дні тепер правильно враховуються, що забезпечує коректний розрахунок зарплати та рейтингів співробітників.

188239 — Розрахунок зарплати → Планування.

Виправили проблему, коли на формі "Планування" у вкладці "Журнал роботи співробітників" не можна було вручну зареєструвати завершення роботи, якщо співробітник працював у нічну зміну і реєстрував прихід вчорашньою датою, а завершення — поточною.

Тепер реєстрація завершення буде дозволена, якщо для посади співробітника встановлено параметр "Робота в нічну зміну". Якщо цей параметр не встановлено, реєстрацію завершення заборонено, і при спробі реєстрації завершення датою, відмінною від приходу, з'явиться повідомлення, що дата завершення буде встановлена рівною даті приходу.

У таблиці "Журнал роботи співробітників" для посад, яким дозволено роботу в нічну зміну, додано статус "Нічна зміна", який відображається піктограмою в колонці "Посада", якщо час приходу пізніше часу завершення робочого дня.

Це дозволяє коректно реєструвати робочий час для нічних змін і уникати помилок у плануванні та обліку робочого часу.

189066 — Розрахунок зарплати → Планування → Графік роботи.

Виправили проблему, коли в графіку можна було ввести кількість годин фактичного відпрацювання на день більше ніж 24.

Це забезпечує коректне введення робочих годин, запобігаючи введенню нереалістичних значень. Наприклад, тепер керівник не зможе випадково вказати більш як 24 години для одного дня, що гарантує точність розрахунку зарплати та планування робочого часу.

188401 — Маркетинг → Клієнти → Розрахунок зниження знижок за відсутність покупок.

Виправили проблему, коли при натисканні кнопки "Знизити знижку" (для всіх виділених рядків) на формі "Зниження знижок клієнтів за відсутність покупок" могла виникати помилка "Violation of UNIQUE KEY constraint 'uqsFineAbsenceBuying'. Cannot insert duplicate key in object 'dbo.FineAbsenceBuying'. The duplicate key value...". Це відбувалося, якщо в одного й того клієнта була знижка на кількох торговельних мережах.

Тепер знижки знижуються коректно, навіть якщо у клієнта є знижки на кількох торговельних мережах. Це забезпечує точне управління програмами лояльності та запобігає виникненню помилок при обробці знижок.

189299 — Склад → Реєстр внутрішніх передач.

Виправили проблему, коли під користувачем з обмеженням доступу до центрів обліку, дані на формі Склад → Реєстр внутрішніх передач оновлювалися в десятки разів довше, ніж у користувача без обмеження прав доступу. 

Також змінили Аналіз → Прибутковість реалізацій за період, тепер при оновленні даних не блокує їх для інших користувачів, а блокування даних іншими користувачами не впливає на цей аналіз. Це забезпечує швидше оновлення даних у цьому аналізі та зменшує вплив на роботу інших користувачів.

189117 — Склад → Реєстр прибуткових накладних → Пов'язати оплату з накладною.

Виправили проблему, через яку у списку оплат, який відкривається при виклику дії "Пов'язати оплату з накладною", відображалися оплати, що є початковими боргами, які могли з'явитися в результаті видалення статистик.

188965 — Нова пошта

Внесли зміни до функції автоматичного створення адреси доставки на замовлення інтернет-магазину.

Старий спосіб пошуку даних за рядковими даними (назва міста, номер та адреса складу, назва та тип вулиці) доопрацьований для підвищення точності. Однак, цей спосіб не гарантує абсолютну точність, тому радимо використовувати новий спосіб на основі ідентифікаторів Нової пошти.

Новий спосіб пошуку даних на основі ідентифікаторів Нової пошти гарантує абсолютну точність. Цей спосіб доступний лише при доставці на склад. До файлу замовлення інтернет-магазину додано поле WarehouseRef, в якому передається ідентифікатор складу (відділення) Нової пошти. При використанні цього поля, заповнювати поля "Назва міста" (DeliveryCity) та "Номер складу" (WarehouseNumber) не потрібно.

Приклад блоку параметрів доставки з використанням нового поля: