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