Цикл «Вопросы и ответы». Загрузка данных склада

Нам регулярно поступают различные вопросы по программе, ей применению, порядку работы с ней, как от начинающих пользователей, так и от тех, кто пока только «присматривается» к программе. Какие-то из них появляются на форуме и сразу попадают в «публичную плоскость», но далеко не все. Периодически сам вопрос бывает ёмкий, но ответ на него требуется достаточно развернутый, с пояснениями, чтобы было понятно, почему так. Иногда в одном «вопросе» реально собирается сразу множество разных соприкасающихся вопросов. Причем, многие их них, можно сказать, «типовые» для многих начинающих или пока ещё «потенциальных» пользователей VOGBIT. Мы решили начать понемногу публиковать некоторые вопросы и ответы на них. Возможно, это будет интересно и другим пользователям и просто интересующимся программой. Возможно, кто-то найдёт здесь именно то, о чём он сам как раз собирался спросить.

У нас около трех тысяч нaименований изделий и материалов на складе. Забивание каждой позиции склада вручную – занимает очень много времени. Есть ли какой-то механизм для переноса данных по складу из таблиц Excel в базу склада программы VOGBIT?

Такой штатной встроенной функции, как загрузка данных из Excel в VOGBIT нет. Но есть дополнительные модули (из «стандартных» – 2 штуки разных на сегодня), которые продаются отдельно, предназначенные для загрузки данных из файлов Excel. Но не любых данных. Эти модули ориентированы, в первую очередь, под загрузку номенклатуры, и состава изделий из некоего внешнего источника «конструкторской» информации. Один из этих модулей умеет в т.ч. загружать данные в виде «документа» (некоей условной «заявки» - список номенклатуры с количеством и единицей измерения). Эту возможность люди используют, в том числе, как раз для загрузки (разовой) первоначальных остатков на складе. Однако смысл в данном случае не в загрузке номенклатуры, как таковой – она то как раз в этой всей процедуре берется из базы VOGBIT, уже существующая там, а именно в корректировке «остатков». К этому чуть позже подробно вернемся. Сначала пару слов про «склад» в VOGBIT, в общем.

Дело в том, что «склад» в VOGBIT, это не «таблица склада» (по аналогии таблице в Excel), в которой просто меняются руками значения «текущих остатков».

Если говорить про остатки, то это величина динамическая, изменяются они в результате проведения в программе «учётных операций» - приход, расход, возврат и некоторые другие.

Если говорить, например, про приход, то при правильной организации работы с программой, кладовщику ничего вводить то не надо в этот момент. Сам список пришедшего - номенклатура, количество - у него уже есть готовый, ему остаётся только подтвердить, что он это получил. Максимум – ввести суммы (стоимость, можно, но не обязательно).

Список этот (на приход) есть у «кладовщика» из «заявки на приобретение», которую ранее в системе создал «снабженец». В тот момент, когда зафиксировал в VOGBIT, что он оформил заказ на приобретение этой номенклатуру в таком-то количестве у такого-то поставщика.

Снабженец в свою очередь руками тоже ничего особо не вводит, кроме разве что корректировки количества.

Ему в качестве входящих вводных поступает в программе готовый список номенклатуры, что нужно заказать, с минимально необходимым количеством. Ему остается уже «раскидать» этот список по заявкам конкретным поставщикам1 – что у кого он заказал, и (обычно) поправить количество – минимально необходимое на то, сколько он реально заказал (и желательно поставить срок, когда ожидается).

Список что нужно заказать: номенклатура, минимальное количество (для «снабженца») формируется программой автоматизированным образом, исходя из текущих остатков, планируемых потребностей производства и информации от снабжения, что уже заказано на текущий момент – это, так называемый, «расчёт дефицита» (режим «Обеспеченность»).

Планируемые потребности производства – это заявки на получение со склада, т.е. список номенклатуры и количество, что нужно выдать со склада (так называемые «Предварительные заявки» или «ЛЗК»). Этот список (документ на получение со склада, номенклатура и количество) также в штатном варианте формируется программой автоматизированным способом, исходя из состава заказа на производства (что изготавливать), техпроцессов (что нужно по нормативам, чтобы указанное изготовить). За это отвечает режим «Расчёт потребности».

По тому же самому списку (ЛЗК, предварительная заявка – номенклатура и количество, что нужно выдать со склада производству) кладовщик производит «Расход». То есть, опять же, при оформлении штатным образом выдачи со склада вводить руками ему ничего не нужно. Список номенклатуры – что выдавать, и количество у него уже есть заполненные в программе. Ему нужно только физически это собрать, желающему отдать, и в программе подтвердить, что он выдал. Возможно, внести корректировки руками по количеству, если выдаёт он сейчас не всё по списку или, например, по факту выдаёт больше, чем было запрошено.

Состав заказа на производство (из которого далее формируется список, что брать со склада) формируется в общем случае (при более-менее сложных изделиях) также автоматизированным образом. Исходя из внесенной конструкторами информации о составе изделий и вводных от руководства, каких изделий и сколько нужно сейчас запустить (и в некоторых случаях, опять же, с учётом свободных остатков на складе ранее изготовленных деталей и узлов).

И вот тут мы добрались до начальной точки в этой всей цепочке – состав изделия, техпроцессы. Вот это, конечно нужно вводить (штатный базовый вариант - руками). Ни откуда оно само не возьмется в программе. Ну или можно при определенных дополнительных вложениях «загрузить», если оно есть в каком-то хорошем качестве от конструкторов. Хотя бы саму номенклатуру узлов, деталей, стандартных и прочих изделий и спецификации (кто в кого входит, в каком количестве). Вот тут колотить руками муторно, конечно. Поэтому есть «стандартные» загрузчики (дополнительные модули, стоимость 15 000 рублей за штуку, два разных) номенклатуры и спецификаций из файлов Excel – недорогие, но с ограничениями существенными. А также регулярно мы разрабатываем «персональные» загрузчики для предприятий под заказ. Это несколько дороже (цена вопроса около 100 000 рублей обычно выходит), но зато можно сделать максимально удобно и автоматизировано под конкретный случай. Данные для загрузки, чаще всего, берутся из неких файлов, которые конструкторы предприятия создают средствами своей САПР (SolidWorks, Inventor, КОМПАС, Tecla и др.). В целом, эти все «дополнения» рассчитаны на импорт в базу данных VOGBIT именно изначально исходной информации – номенклатура, состав сборочных единиц. Возможно, какие-то дополнительные связанные вещи (вес, размеры, чертежи/развертки, материал заготовки и т.п.)

А что касается дальнейшего, то там уже одно из другого дальше получается «по цепочке»:

Из списка изделий и данных об их составе – состав производственного заказа – что изготавливать, какие узлы, детали, сколько.

Из состава производственного заказа и технологии – список что получать со склада (потом, через несколько шагов, на основании этого же списка кладовщик будет оформлять расход).

Из списка, что получать со склада и текущих остатков (упрощенно, там ещё штук 5 переменных участвует реально) – «дефицит» для снабжения (номенклатура, количество) – что купить.

Из «Дефицита» (общий список, что купить) – заявки поставщикам, что у кого заказали и в каком реально количестве – т.к. список по поставщикам, что от кого и когда придёт.

Из заявки поставщику, когда по ней пришло то, что было заказано, список пришедшей номенклатуры с количеством попадает кладовщику – он по нему оформляет приход на склад, остатки увеличиваются.

Далее в какой-то момент физически приходит из производства тот товарищ, которому в итоге соответствующие ТМЦ нужны, и у него (и у кладовщика) уже есть в программе электронная заявка на получение их со склада (которую мы уже сделали на 4 шага ранее, она уже есть в базе данных) – список номенклатуры с количеством – что выдавать. Кладовщик по этому списку оформляет расход. Остатки уменьшаются. Круг замкнулся.

И так далее (появляются новые заказы, потребности и поехали по новой).

И, как видите, в штатной ситуации, никакой номенклатуры тут уже никто не вводил из всех участников. Только определенные действия с количеством, может, на своём этапе. Не считая «конструктора», конечно, от которого соответствующая номенклатура изначально в базе данных и появилась.

Где тут вмешивается «чисто ручной ввод» во этой всей цепочке:

1. Расходники (в случае, если их учёт ведется в VOGBIT, что совсем не обязательно). Которые запрашиваются и выдаются со склада не «по капле» - некое расчётное количество на конкретное изделие, а берется, условно, «бочка», ставится в цех, и берем из неё, пока не закончится. Как закончится, выписываем требование и берем на складе следующую «бочку».
   Отличие от всего выше расписанного тут только в том, что «требование» - список номенклатуры с количеством, что нужно получить со склада, в данном случае составляется не программой, а просто руками. Остальное всё - то же самое, что выше. Составленное вручную «Требование» «вливается» в общую цепочку: учитывается в расчёте «дефицита» (если того, что запрошено, нет, то снабженец это видит и закупает), по этому «требованию» кладовщик оформляет «расход». Возможна в данном случае и автоматизация в VOGBIT подсветки «дефицита» (информация, что пора покупать) таких условных «бочек» для снабжения, если задать для них в программе минимальный складской остаток, какой нужно поддерживать (есть такая штатная возможность).
2. Примерно похожая ситуация и с инструментом и СТО обычно, если их учёт ведется в VOGBIT. Чаще всего, как-то автоматизировано сформировать корректный запрос на выдачу со склада в данном случае невозможно, и составляется «требование» вручную. Или просто оформляется упрощенным образом выдача из того, что есть на остатках по факту, без всякого предварительного оформления «требования».
3. Незапланированные затраты ТМЦ, когда требуется по факту то, что никакими нормативами не было изначально заложено. Но по факту оказалось, что нужно. Решение аналогичное. Вручную составляется в программе «Требование» - список номенклатуры с количеством, что дополнительно хотим взять со склада. Дальше всё по стандартной цепочке. Несколько похожая ситуация с «заменами». Когда выдается не то, что изначально планировалось, а нечто, что есть в наличии и, в принципе, допустимо использовать в данном конкретном случае. Отличие здесь только в том, что не создаются (обычно) новые запросы на получение со склада, а корректируются уже существующие. Дальше там есть нюансы, но технически суть сводится к ручной (или полу-ручной) корректировке номенклатуры и количества в документах – запросах на получение со склада.
4. Какие-то разовые затраты на текущие нужды, в т.ч. и не связанные непосредственно с изготовлением (ремонт в цехе и т.п.). В этом случае – аналогично предыдущему. «По правильному» - составляется вручную документ «требование» на получение необходимого со склада, и дальше по стандартной цепочке. В упрощенном варианте – просто «списывается» вручную с остатков на складе какое-то количество из того, что есть.

Ну и наконец, существует задача первоначального ввода текущих остатков в программу (именно первоначального, однократного, т.к. дальше уже остатки в VOGBIT затем меняются в результате тех действий, что описаны выше). Но в данном случае НЕ стоит задача вносить в базу данных номенклатуру.

Номенклатура то, по-хорошему, уже вся есть в VOGBIT к этому моменту, которую нужно «учитывать». Ибо, если вдруг это не так, то это означает, что указанной номенклатуры, которую мы хотим «учитывать» у нас нет в базе данных ни в спецификациях (составе изделий), ни в техпроцессах, ни в производственных заказах – нигде. Получается мы просто «зальём» в базу данных некую новую номенклатуру, которой вообще нигде в этой базе нет, кроме как некий «остаток». А значит – никакие «заказы», «запросы», «заявки» - всё, что описано выше – этого всего НЕ будет. Вся цепочка, где одно получается из другого, работать не будет. А будет просто гора номенклатуры, ни к чему не привязанной, и некие «текущие остатки» по ней (актуальные к тому же только на тот момент, когда «залили», а завтра они уже и устареть могут). И что с этим всем при таком раскладе дальше делать? Чисто руками дальше эти «остатки» править в VOGBIT? Не имея ровно никаких возможностей, кроме как их править и на них смотреть? А зачем тогда так сложно? Если это и вся задача, и всё решение, то тогда намного проще это просто делать руками в Excel в обычной табличке.

Смысл вести остатки именно в VOGBIT – это если нужно, чтобы все «работало, как предусмотрено» (ну хотя бы в какой-то части всего процесса, а лучше весь), т.е. «дефицит» сам считался программой, «обеспеченность» высвечивалась, снабжение понимало, глядя в VOGBIT, что ему к какому сроку и сколько нужно заказывать, производство понимало, что у него обеспечено полностью, где чего не хватает и когда оно будет полностью обеспечено, где «проблемные позиции» (не заказно или не успевает приехать), чтобы каждый следующий получал готовый список номенклатуры с количеством по своей части, а не вводил его, и т.д. и т.п. А для этого всего начало идёт от конструкторских спецификаций, техпроцессов и т.д. по цепочке (см. выше). То есть уж как минимум номенклатура вся давно в базе уже есть. И должен быть налажен уже сам процесс, откуда исходная информация получается: в базу поступают от конструкторов и технологов исходные данные по новым (старые уже есть в базе) изделиям (состав, ТП), формируются, как минимум, заказы на производство в программе, по ним корректно рассчитываются потребности (формируются документы-запросы на получение со склада в нужный момент и с правильным содержанием). Последующие участники (снабжение, кладовщик), которые по понятным причинам пока ещё не включены в этот момент в «цепочку» в программе, должны быть по крайней мере морально и технически готовы к тому, чтобы сразу «включиться». Должны понимать, что он них требуется, что они будут видеть, условно говоря «с завтрашнего дня», в программе, что и как они будут делать в программе, они должны быть готовы технически это делать. И вот в этот самый момент как раз и пора «загружать» начальные остатки. И сразу «запускать» после этого всю «цепочку».

Таким образом, на момент, когда реально нужны «остатки», сама номенклатура в VOGBIT давно уже есть. Иначе, если нет на этот момент времени не то что налаженного «процесса» (для которого нужны «остатки» в программе), но и даже элементарно номенклатуры в базе данных (не говоря уже о производственных заказах, запросах на получение со склада и т.д.), то зачем тогда «остатки» уже в этот момент иметь в программе? Что с ними дальше делать? При таком подходе, 100% через какое-то время всё это «загруженное» будет просто вычищаться и удаляться. Проверено.

Если же реально пришло время ввести в программу «начальные остатки» (т.е., как мы определились, номенклатура и т.д. – всё есть, вопрос только в том, чтобы массово оприходовать какое-то количество этой номенклатуры на склад - сколько там чего реально прямо сейчас есть), то технически это решается следующим образом:

Берется вся номенклатура из БД VOGBIT (или выбранная) и сохраняется в файл Excel (такая штатная функция есть). Потом идём с этим файлом (или распечаткой) на склад, считаем, проставляем реальное количество в наличии.

Дальше полученное вводится в VOGBIT, как некая условная «заявка поставщику» (обычно, в этом случае используют условного «поставщика», например, с названием «Корректировка остатков») – список номенклатуры с количеством. И потом на основании этой «заявки» двумя нажатиями кнопки штатным образом оформляется «приход» всего по указанному списку на склад.

Готово. Задача решена. Текущие остатки есть. Запускаем работу по «цепочке» (как мы определились ранее, мы к этому организационно и технически готовы, иначе не стоило и начинать с «остатками»).

Само получение в VOGBIT «заявки на закупку» из Excel файла, можно при желании автоматизировать. Цена вопроса – 15 000 рублей. Один из «стандартных» дополнительных модулей для загрузки в VOGBIT конструкторских спецификаций из файлов Excel умеет загружать в т.ч. и, так называемые, «расчётные документы». А как раз «заявка поставщику» технически в программе таковым «документом» и является. Можно данный дополнительный модуль купить и использовать для того, чтобы загрузить «заявку» из Excel файла (по которой потом сделать приход на склад). Сам этот дополнительный модуль не имеет ограничений ни по времени, ни по количеству рабочих мест, где он используется, и кроме того, умеет загружать не только «документы», но и «спецификации сборочных единиц», номенклатуру, параметры и даже некоторые отдельные вещи из технологии при определенных условиях. В общем, может быть, потом и ещё зачем-нибудь пригодится. Если же нет желания тратить 15 000 рублей, но тогда можно просто посадить кого-нибудь, кто введёт такую «заявку на приход» один раз руками. Перед глазами Excel или распечатка. В нем ровно вся та же самая номенклатура и в том же самом ровно порядке, что перед глазами в открытом рядом окне «Номенклатура» в VOGBIT. Перетаскиваем номенклатуру в VOGBIT мышкой из «Номенклатура» открытое окно «Заявки» и проставляем руками количество из открытого рядом распечатки/Excel’я. Задача – не бог весть что. Даже огромный список номенклатуры можно так «обработать» за несколько часов – максимум день/два, если уж ну совсем очень-очень много. Вводить то, опять же, саму номенклатуру не нужно. Нужно мышкой её перетащить из одного окна в другое и количество только проставить. Можно частями делать. Например, сначала все «болты» условно подбить, потом все «гайки» и т.п.