Посмотрел тут разный софт под учет ремонтов и материалов/запчастей (нужен для удобства работы). Что могу сказать...
Наиболее обнадёживающе выглядел «Сервисный центр» от YukoSoft. В общем, решил я посмотреть на это ПО в деле. И вот тут-то меня поджидало сильное разочарование. Упрощенные алгоритмические обвязки и ошибки делают данное ПО практически неприменимым (или ограниченно применимым).
Первым делом я отправил автору свои замечания по логике приходования одинаковых товаров с разной ценой закупки (указав на это как на грубую ошибку) – и получил в ответ вот такую отповедь:
В программе нет никакой ошибки, тем более грубой.Существует множество различных способов товарного учёта: партионный учёт, учёт ФИФО, учёт ЛИФО, учёт по среднему, учёт по последнему приходу и т.д.Называть один из этих способов учёта верным а остальные "грубейшей ошибкой" ошибочно.Для данной простой программы стоимостью 8000р выбран самый простой способ товарного учёта с одним складом. Цена товара в справочнике всегда берётся из цены закупки этого товара в последнем приходе.
Из всего этого я сделал несложный вывод, что данное ПО (т.е. оболочка СУБД, фактически) хоть и выглядит красиво, но во многом сделано на от@бись. Я говорю о логике обработки данных и их учёта, заложенной в SQL-запросы данного ПО.
Могу предположить, что логика SQL-запросов писалась теоретиком, весьма далёким от практической работы «в полях». Более-менее знакомый с практикой разработчик сделал бы, в худшем случае, учёт по среднему, а в идеале — партионный учёт (т.е. учёт по цене закупки). Или это условие вписал бы в ТЗ постановщик задачи/архитектор, знакомый с практикой. Но так получилось, что этого не случилось. В общем, количественно-стоимостное ведение базы товаров (т.е. запчастей и материалов) в данном ПО лишено всякого смысла.
Могу предположить, что логика SQL-запросов писалась теоретиком, весьма далёким от практической работы «в полях». Более-менее знакомый с практикой разработчик сделал бы, в худшем случае, учёт по среднему, а в идеале — партионный учёт (т.е. учёт по цене закупки). Или это условие вписал бы в ТЗ постановщик задачи/архитектор, знакомый с практикой. Но так получилось, что этого не случилось. В общем, количественно-стоимостное ведение базы товаров (т.е. запчастей и материалов) в данном ПО лишено всякого смысла.
Стоит добавить, что у данного ПО откровенно плохо обстоят дела и с управлением версионностью БД. Возникает ошибка SQL при попытке изменения текущего статуса заказа (т.е. изменения этапа работы с заказом). Отправил скриншот с ошибкой всё туда же. Получил ответ:
Скорее всего у вас старая версия базы где была такая проблема. Вы можете прислать скриншот ошибки и свой файл базы (путь указан в нижнем правом углу программы)
Вот это предложение прислать ему (или им) свою базу как следует понимать и воспринимать? А если в вашу БД уже вбиты реальные контактные и персональные данные клиентуры? Автор что, ничего не знает о 152-ФЗ?
Вот такие впечатления. Сделано хоть и красиво внешне, но довольно-то бестолково внутри (местами).
Продолжаю ковырять, т.к. в виде бесплатного (и только) варианта оно, в принципе, приемлемо. Нашёл еще один баг: если в изготовителях (в моём случае) попадаются дубли, то потом у этого дроплиста в карточке заказа пропадают совершенно другие строчки.
ОтветитьУдалитьПри удалении дублей всё оживает.
УдалитьСобственно, всё это достаточно типично для институтской науки (автором данного ПО значится Юрий Кольцов, он же Юрий Владимирович Кольцов, он же декан ф-та компьютерных технологий и прикладной математики, он же заведующий кафедрой информационных технологий Кубанского государственного университета).
ОтветитьУдалитьНаконец-то вышел апдейт с исправлениями по статусам – заработало. Проверил товарный учёт – нет, там всё по-прежнему, с околонулевой ценностью.
ОтветитьУдалить