База для учёта проката строительного инструмента и малой техники: одна центральная база вместо шести отдельных копий в пунктах выдачи по Москве и области. Построил её Евгений Росляков — с 2016 года он делает сайты и учётные системы для бизнеса. Он самозанятый, до начала работ подписывает договор, юрлицам выдаёт закрывающие документы. Живёт в Москве; здесь проект шёл в основном удалённо, с поездками на пункты.
У компании шесть пунктов выдачи, и в каждом стояла своя копия базы Microsoft Access. Раз в несколько дней файлы пересылали друг другу по почте и пытались свести остатки. Они не сходились.
Однажды один перфоратор выдали двум клиентам: оба пришли по брони, а в двух копиях базы он числился свободным. Залоги писали в тетрадь и в комментарии к строкам, поэтому они терялись. Инструмент, ушедший в ремонт, мог пропасть из виду на несколько недель.
Сотрудникам при этом нужен был привычный интерфейс. Годами они работали с формами Access и не хотели учить новую программу.
И ещё условие: никаких серых лицензий. Новые лицензии Microsoft в России сейчас не продаются, а центральная база должна работать на том, что можно использовать законно.
Начал с Data Modeling. Сел с администраторами пунктов и расспросил, что на деле происходит с инструментом. В модели появилась единица инструмента с серийным номером и состоянием, отдельно от вида инструмента: «перфоратор» — это вид, а конкретный экземпляр живёт своей жизнью. Дальше бронь, договор проката, залог, продление, возврат, ремонт, списание. Клиент может быть физлицом или компанией, у каждого свои реквизиты.
Центральной базой стал Microsoft SQL Server в бесплатной редакции Express. У неё есть потолок на размер одной базы, но строк проката даже за много лет хватает с запасом: сканы договоров лежат файлами рядом, а в базе только записи и ссылки на них. В Express нет планировщика заданий, поэтому резервные копии запускает штатный планировщик Windows через командную строку. Права разделены по ролям: пункт видит свои операции и общий справочник, руководитель видит всё. Для SQL Server это обычная схема, ничего самодельного.
Бизнес-правила написал на T-SQL (язык запросов структур транзакций) — так называют диалект SQL от Microsoft, в котором есть процедуры и транзакции. Выдача и возврат — хранимые процедуры. Внутри транзакции процедура блокирует запись инструмента, проверяет состояние и брони и только потом фиксирует выдачу. Выдать один перфоратор двум людям теперь нельзя: второй запрос дождётся и получит отказ. Триггеры ведут журнал изменений: кто, когда и что поменял в договоре или залоге. Отчёты по загрузке парка и простоям считаются запросами к этой же базе.
Microsoft Access остался интерфейсом сотрудников. Формы переделал под новую схему, таблицы подключил к серверу по ODBC, и данные больше не лежат файлом на компьютере пункта.
Остатки теперь одни на всех. Менеджер пункта видит, где физически находится каждая единица, свободна ли она и на какие даты забронирована. Двойная выдача исключена на уровне базы, а не договорённостью между людьми.
Залоги и ремонты не теряются: у каждого есть запись с датой и ответственным. В споре с клиентом можно открыть журнал и посмотреть, что происходило с договором.
Сотрудникам почти ничего не пришлось учить. Они открывают знакомые формы и нажимают те же кнопки, а сложное происходит на сервере. На обучение хватило вечера на пункт.
Руководитель получил отчёты по загрузке и простоям: видно, какой инструмент работает постоянно, а какой месяцами стоит. По ним решают, что докупать, а что списывать.
Ограничения тоже есть. У бесплатной редакции потолок по размеру базы и по мощности, и если сеть вырастет до десятков пунктов, схему придётся менять. Связка Access и ODBC хороша для шести пунктов, но на длинной дистанции интерфейс лучше перевести в веб. Как это сделать без переделки базы, я описал отдельной запиской.
Разрозненные файлы в точках, склад или аренда на таблицах — обсудим, как свести это в одну базу. Напишите мне здесь, на freelance.ru: сколько у вас точек и в чём вы ведёте учёт сейчас.
