Способы отражения производства в 1С:УНФ

Возможности конфигурации 1С:Управление нашей фирмы многогранны: от стандартного ведения учета по покупке и продаже готовых товаров до виртуальных ассистентов, интеграций с телеграмм-ботами, ведение розничной торговли и многое-многое другое. Однако основным и одним из самых объемных блоков программы является производство продукции и оказание работ.

На первый взгляд кажется, что производственный блок достаточно простой, содержит лишь парочку документов и основной задачей является грамотное заполнение спецификаций. Но настройка спецификаций может серьезно изменить процесс отражения производства в программе. Разные настройки могут как облегчить работу для конкретного пользователя, так и наоборот – усложнить и увеличить вероятность возникновения ошибок в учете.

Именно поэтому в данной статье рассмотрим различные варианты оформления спецификаций, каким образом настройки повлияют на процесс создания документов производства, а также выделим плюсы и минусы каждого конкретного варианта заполнения спецификаций.

1.  Постановка задачи

Для начала нужно смоделировать ситуацию, чтобы на конкретном примере разобрать несколько вариантов производства (при этом спецификация к номенклатуре будет содержать одни и те же материалы, отличаться будет только сам механизм оформления производства в программе). Рассматривать будем классическую схему: покупатель сформировал заказ (“Заказ покупателя”) и на основании этого заказа необходимо произвести указанный товар. Но задачи с производством в один этап достаточно просты в оформлении, поэтому предлагается рассмотреть производство в несколько этапов.

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

2. Стандартная схема через дерево спецификаций

Для начала рассмотрим классический вариант оформления производства, а именно через так называемое дерево спецификаций. Оформляем стандартно документ “Заказ покупателя”:

Сама спецификация состоит из деталей, на которые имеются собственные спецификации, а также из операции сборки модулей:

При этом спецификации для деталей практически идентичны, за исключением требуемого количества материала для каждой детали:

Теперь, когда все спецификации к необходимым материалам заполнены, можем пойти двумя путями:

1. Сформировать подчиненные документы вручную (вариант трудоемкий, но зато помогает наглядней отследить логику формирования каждого документа):

После первого создания заказа на производство мы отразили потребность в материалах для производства именно готовой продукции (в нашем случае стола классического). Поэтому чтобы обеспечить производство деталей, из которых будет собираться сам стол, необходимо создать документ “Заказ на производство” уже на основании только что созданного заказа. Таким образом мы получим некую иерархию заказов, по которым можно отследить, какие материалы из заказов используются для производства следующего уровня материалов/товаров (более сложных, и близких к готовому изделию):

Получаем итоговый заказ на производство:

Теперь необходимо обеспечить закупку необходимых материалов для производства наших столов. Сделать это удобно можно через обработку “Закупки – Планирование – Расчет потребностей”.

В появившемся окне обработки переходим на вкладку “Фильтры”, добавляем в отбор фильтры по заказам на производство и выбираем созданные нами заказы. Затем нажимаем кнопку “Рассчитать”.

После проделанных пунктов обработка покажет материалы, которые на данный момент находятся в дефиците и необходимо их заказать у поставщиков.

Примечание: необходимый поставщик выбирается из карточки номенклатуры, если в реквизитах указан способ пополнения “Закупка”, а также указан основной поставщик (при этом всегда можно заказать у произвольного поставщика вручную). Также обращаем внимание на вкладку “Управление запасами” в том же справочнике “Номенклатура”, т.к. если в данной таблице нет записей, то тогда программа будет создавать поступления на количество дефицита товара, однако если записи в таблице есть, тогда при уменьшении количества товара до минимального обработка “Расчет потребностей в запасах” автоматически создаст заказы поставщикам для пополнения количества запасов до максимального значения.

После выбора необходимых материалов в обработке переходим на вкладку “Планирование” и формируем заказы.

После того, как заказы сформированы, проверяем на заполненность (проверяем, чтобы заказ клиента был заполнен) и проводим документы.

После этого можем перейти в сам заказ покупателя и проверить структуру подчиненности документа (для документов “Заказ поставщику” были вручную созданы приходные накладные, чтобы формировать в дальнейшем документы производства без ошибок):

Теперь наглядно отображается вся последовательность действий, необходимая для производства товара по заказу покупателя. Можно было автоматизировать создание заказов на производство (особенно актуально, если заказов покупателя достаточно много), для этого воспользуемся вторым путем обеспечения потребностей:

2. В данном случае сразу после создания “Заказов покупателя” нужно перейти во вкладку “Фильтры” и сделать отбор по необходимым заказам, а также установить “Пополнение” как “Производство”. В таком случае обработка сама предложит создать нужный заказ на производство. Но повторять процедуру нужно до тех пор, пока не будут созданы все “слои” заказов на производство, а только затем “пополнять закупки”.

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

Связные документы заказа будут выглядеть примерно следующим образом:

Как нетрудно заметить, заказы на производство не имеют подчиненной связи при создании автоматически. Кому-то это удобно, ну а кто-то привык видеть связь между заказами, поэтому удобный вариант выбирает сам пользователь, который ведет учет.

После того, как все планирование сделано, можно создавать сами документы производства и сдельных нарядов. Мы не будем уделять этому много времени, поэтому сразу представим готовые варианты и сформируем расходные накладную для отражения продажи товара.

Собственно, так выглядит стандартная схема производства через дерево спецификаций. Сразу видны очевидные минусы:

1. Приходится создавать много документов “Заказ на производство” и если дерево спецификаций достаточно объемное, то это может вызвать трудности при отражении самого факта производства.

2. Нельзя сразу рассчитать количество запасов, которое потребуется для производства готовой продукции. Да, можно воспользоваться специальными отчетами, к примеру, “Нормативный состав изделия”, но это не так удобно, если бы нам были сразу известны все материалы, которые потребуются в производстве, чтобы формировать заказы поставщикам.

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

3. Схема производства через этапы

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

Для того чтобы вести учет используя данную схему, необходимо создать новую спецификацию. В спецификации обязательно нужно заполнить вид производства и занести этапы, на которое данное производство будет разделяться. В нашем примере достаточно будет использовать 3 этапа:

• Распил (формирование деталей из ДСП);

• Сборка (непосредственно сборка самого стола);

• Завершение производства (отражает, что продукция была произведена и дальнейших работ не требуется).

После того, как этапы производства заполнены, необходимо заполнить состав номенклатуры и операции, которые будут использоваться. При этом обязательно нужно указывать, на каком этапе будет производиться списание материалов в производство, или же когда будет проводиться определенная операция.

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

После создания спецификации создадим новый заказ покупателя, укажем нашу спецификацию и создадим заказ на производство.

В заказе на производство все материалы и операции заполнились автоматически, поэтому можно оформить заказы покупателям, в случае дефицита запасов (этот момент мы пропустим, т.к. все действия были описаны в предыдущей схеме). Пришло время заняться производством. Переходим в обработку “Выполнение этапов”.

В обработке можно задать дополнительные фильтры, чтобы не выводить информацию из всех заказов. Нас интересует сам процесс выполнения этапов и что при этом будет происходить в программе.

После установки галочки в соответствующем этапе необходимо выбрать подразделение, которое будет производить данный этап, а также бригаду или сотрудника, которые будут задействованы в этапе. После заполнения этих данных нажмем кнопку “Выполнить этапы” и по завершению обработки получим сообщение об окончании выполнения обработки, а также вместо указанных нами подразделения и работников получим ссылки на созданные документы.

Произошло автоматическое создание документов “Производство” и “Сдельный наряд”, где указан пройденный этап производства и отражены используемые запасы и операции.

После установки следующего этапа можно заметить, что новые документы производства и наряд созданы не были, при этом в пройденном этапе указываются ранее созданные документы. Посмотрим, что в них изменилось:

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

Ну и после выполнения последнего этапа (“Завершение производства”) в базе создастся новый документ производства, который отразит поступление готовой продукции на склад.

По итогу иерархия подчиненных документов будет выглядеть следующим образом:

Сразу заметно, что иерархия стала более компактной, по сравнению с первой схемой. Также сразу из плюсов стоит подметить удобство использования. Нам не нужно вручную сильно менять документы, по сути работа осуществляется полностью двумя обработками: “Расчет потребностей в запасах” (для формирования заказов на производство по заказам покупателя, а также для формирования заказов поставщикам, в случае дефицита запасов) и “Выполнение этапов”.

Из минусов стоит отметить, что производство в данном случае четко и твердо регламентировано, т.е. нельзя выполнять этапы непоследовательно или вообще их пропускать. Таким образом мы не можем отражать параллельное производство товаров (как было описано в предыдущей схеме), если они находятся в одном заказе в нескольких количествах. Ну а также можно отметить, что нельзя производить товар частично, т.е. если в заказе покупателя было 10 номенклатур, то мы обязаны произвести эти 10 номенклатур, иначе производство не закроется. Но зачастую в несложных схемах производства эти ограничения могут оказаться несущественными, что позволит значительно упростить задачу учета для пользователей 1С.

4. Схема производства через сборку

Последняя схема, которую хотелось бы рассмотреть – это схема сборки. Эта схема является неким гибридом предыдущих схем.

Сама спецификация практически идентична спецификации из первого способа, за исключением того, что полуфабрикаты (запчасти) у нас будут являться не “Материалом”, а “Узлом”:

Что происходит непосредственно в программе и что означает “Узел”? Если говорить простым языком, это просто указание номенклатуры, материалы которой потребуются в производстве. Т.е. если мы в схеме через этапы под определенными этапами подразумевали производство каких-то запчастей для итогового изделия, то здесь мы напрямую указываем, какое изделие нам понадобится, но при этом мы не будем выносить сам процесс производства запчасти в отдельные документы.

Таким образом, если мы сформируем новый “Заказ клиента” и “Заказ на производство”, то заметим, что табличная часть материалов не содержит запчасти, а содержит материалы, которые указаны в спецификациях к узлам.

Из плюсов сразу можно вынести, что сразу рассчитывается количество материалов, которое потребуется для производства, следовательно, после создания “Заказа на производство” можно проверить потребность через обработку “Расчет потребностей в запасах”. Также есть возможность производить готовую продукцию частично, но только в разрезе готовой продукции (т.е. можем производить часть заказа).

Из минусов:

1. Нет контроля над этапами производства, т.е. мы не можем отследить, сколько было создано деталей по данному заказу (зачастую в качестве отражения этапов пользователи заводят несколько произвольных статусов именно заказа на производство и устанавливают их по определенным условиям).

2. Нет возможности хранить произведенные запчасти. Эта проблема вытекает из предыдущей, т.к. если нет возможности отслеживания производства запчастей, то программа не будет отражать готовые запчасти на складе, что может быть неудобно в определенных ситуациях.

Подробно рассматривать весь алгоритм создания документов производства по данной схеме мы не будем, т.к. она практически идентична первой схеме, за исключением, что нет необходимости создавать дополнительные “Заказы на производство”.

Как и все продукты 1С:Управление нашей фирмой предоставляет большую вариативность применения и различные подходы для автоматизации нужных бизнес. Нет единого универсального, подходящего под потребности всех пользователей механизма отражения производства в данной программе. Но вместо универсальности, программа предлагает на выбор несколько вариантов, которые можно комбинировать между собой и подстраивать под конкретные бизнес-процессы каждого из клиентов, что позволяет сделать учет проще и удобней для каждого. Успехов в развитии бизнеса!