Склад на объекте живёт не по правилам склада
Машина приходит в пятницу в семь вечера. Водитель торопится, кладовщик расписывается в накладной не глядя, накладная едет в папку, папка лежит в вагончике до конца месяца. В понедельник прораб спрашивает, сколько осталось гипсокартона, и кладовщик идёт считать листы глазами.
Обычный склад стоит на одном месте годами: стеллажи, адреса ячеек, приёмка по графику. Объектный склад — это бытовка, навес и кусок земли за забором, и через восемь месяцев их тут не будет вообще. Кладовщик редко занят только складом: принял машину — пошёл разгружать вместе с бригадой. Снабженец сидит в офисе за тридцать километров и заказывает следующую партию по звонку прораба, то есть по памяти прораба.
Дальше начинаются знакомые вещи. Купили лишнее, потому что не знали про остаток на соседнем объекте. Или не купили вовремя, потому что «вроде было», и бригада стоит и ждёт смесь.
Пример расчёта, подставьте свои цифры. Бригада восемь человек, ставка 400 ₽ в час, простой полдня из-за того, что кончилась сухая смесь: 8 × 4 × 400 = 12 800 ₽ за один такой день. Материал при этом дешевле простоя, и его всё равно потом купят.
Что должна уметь программа, когда объектов несколько
Требования банальные, но до покупки их почему-то редко проговаривают вслух.
Остаток должен быть привязан к объекту, а не к организации. Пятьсот метров кабеля «где-то у нас есть» — бесполезная строка. Полезная выглядит так: 500 метров лежат на объекте «Школа на Ленина», у кладовщика Семёнова, приняты 12 марта по накладной такой-то.
От списания нужно то же самое, только в обратную сторону: куда материал ушёл. Не «расход за март», а конкретная работа или участок и человек, который забрал. Иначе в конце месяца никто не объяснит, почему на стяжку ушло на треть больше смеси, чем в смете.
Приход без документа — не приход. Накладная, УПД, товарный чек из строймаркета: что-то, к чему можно вернуться через полгода, когда заказчик попросит подтвердить расход по КС-2.
Ну и права доступа. Кладовщик оформляет движение, но не правит задним числом цены. Прораб видит остатки по своему объекту и не видит чужие закупочные цены. Снабженец видит всё, потому что ему заказывать.
| Что нужно сделать | Тетрадь в вагончике | Excel у снабженца | Складской модуль системы |
|---|---|---|---|
| Принять материал | Подпись в накладной, запись от руки | Заносят в конце недели, если вспомнят | Кладовщик оформляет поступление в день приёмки |
| Узнать остаток по объекту | Пойти и посчитать | Файл отстаёт на несколько дней | Остаток пересчитывается после каждого движения |
| Списать в работу | Часто не фиксируется вообще | Одной строкой «расход» | Списание с указанием объекта и ответственного |
| Перебросить на соседний объект | Звонок и устная договорённость | Правят два файла, иногда один | Перемещение уменьшает один остаток и увеличивает другой |
| Найти, кто принимал | По почерку | Никак | В карточке движения стоит пользователь и дата |
| Свести с закупками | Вручную по папке | Сверка руками | Заявка, закупка и поступление связаны между собой |
Приход и списание: как накладная становится остатком
В STROICON склад собран из движений: поступление, списание, перемещение между объектами. Каждое движение фиксирует, что, сколько, куда и от кого. Остаток руками не вводят, он получается сам.
Кладовщик открывает поступление, выбирает объект, добавляет позиции из номенклатуры, ставит количество и цену. Если материал шёл через закупку, позиции подтягиваются из заявки, и сверять приходится только фактическое количество с заказанным. Недовоз видно сразу, а не в конце месяца, когда водителя уже не найти.
Автоматический разбор УПД у нас в разработке, пока строки заносит человек. Мобильного приложения тоже нет, склад открывают в браузере, в том числе с телефона. Пишу прямо, потому что «сфотографировал накладную — система сама всё разнесла» звучит красиво, но на сегодня это не так.
Списание — вторая половина работы, и обычно проваливается именно она. Материал приняли аккуратно, а куда он делся, не пишет никто. В системе списание привязано к объекту, поэтому расход по каждой стройке считается отдельно. Смета лежит там же, так что сравнить списанный объём с заложенным можно, не поднимая папку с бумагами. Это тот самый разговор про М-29, только без ручного переписывания цифр из тетради в форму.
Инвентаризация и материальная ответственность
Инвентаризация активов и обязательств — требование закона о бухгалтерском учёте (402-ФЗ, статья 11), а не прихоть главбуха. На объекте её и так приходится делать: перед закрытием этапа, при смене кладовщика, после того как в бытовку залезли.
Толк от инвентаризации есть только тогда, когда есть с чем сравнивать. Пересчитали по факту двести мешков, а в системе числится двести сорок — разница видна, и видно, за какой период она набежала и кто в этот период оформлял движения. Если учётной цифры нет, пересчёт превращается в новую отправную точку, а недостача растворяется.
Отсюда вторая тема. Договор о полной материальной ответственности с работником заключается по статье 244 ТК РФ, а должности, с которыми такой договор допустим, перечислены в постановлении Минтруда от 31.12.2002 № 85 — кладовщики и заведующие складами там есть. Без учёта договор работает плохо: чтобы взыскать недостачу, нужно показать, что человеку передали конкретное имущество в конкретном количестве. Карточка движений с фамилией принимавшего как раз это и подтверждает. В STROICON кадровые документы по сотруднику лежат в разделе кадров, а движения по складу — в складском, но сотрудник в обоих один и тот же.
Отдельная история — пересорт. На объект приходит «уголок 50×50», а в смете «уголок 50×50×4», и это разные позиции. Пока номенклатуру ведут два человека в двух файлах, пересорта не избежать. Общий справочник номенклатуры лечит это не полностью, но убирает случай, когда один и тот же материал живёт в учёте под четырьмя именами.
Чего программа не сделает
Она не посчитает то, что в неё не внесли. Выдал кладовщик десять мешков «на пять минут, потом оформлю» — остаток уже неверный, и никакая система этого не поймает. Дисциплина оформления держится на прорабе, а не на программе.
Вынос материала за забор она сама по себе тоже не остановит. Зато превращает пропажу в конкретную цифру с датой и фамилией. Разговор «у нас что-то расходуется много» и разговор «между инвентаризациями пропало сорок мешков, движения оформлял один человек» заканчиваются по-разному.
Бухгалтерию она не заменяет. Интеграция с 1С в разработке, автоматический обмен появится позже. Сейчас складской модуль закрывает учёт на объекте: сколько лежит, кто принял, куда ушло. Бухгалтерия ведёт свои регистры отдельно.
Видеонаблюдение и распознавание номеров машин на въезде тоже в разработке. Когда заработает, приёмку можно будет сверять с фактом заезда, но сроки обещать не буду.
Вопросы, которые задают чаще всего
Кладовщик и так загружен. Не станет ли оформление лишней работой? Одно поступление оформляется примерно за то же время, что и запись в тетрадь, только запись снабженец видит сразу, а тетрадь не видит никогда. Тяжело даётся не ввод, а первый месяц привычки. Обычно помогает простое правило: машину не разгружаем, пока приход не оформлен.
Нужен ли на объекте интернет? Да, система работает через браузер, данные хранятся не в вагончике. Обычно хватает мобильного интернета с телефона кладовщика. Отдельный сервер на объекте не нужен.
У нас всё в 1С. Придётся вести двойной учёт? Частично, до появления интеграции. Движения по объекту ведутся в системе, бухгалтерский учёт — в 1С. Смысл в том, что сегодня 1С про объект чаще всего не знает ничего: там есть накладная поставщика и нет ответа на вопрос, сколько мешков лежит под навесом на конкретной стройке.
Объект идёт уже полгода, учёта не было. С чего начинать? С пересчёта на дату. Считаете фактические остатки, заводите их первым поступлением, дальше в систему попадают только движения. Восстанавливать прошлое по папке накладных смысла нет: половина материала уже в стенах.