«1С:Управление нашей фирмы» (1С:УНФ) — популярное решение от «1С», призванное помочь с автоматизацией учета в небольших производственных компаниях. Возможности этого программного продукта позволяют не только оптимизировать производственные процессы, но и вести учет закупок, продаж, складских операций и пр.
Тем не менее, у компаний, которые работают с этим решением, периодически возникают потребности, удовлетворить которые типовая 1С: УНФ не может. В этой статье мы расскажем историю одного из наших клиентов, которому понадобился расширенный партионный учет, реализовать который помогли специалисты «Гигабайт».
Проблемы партионного учета в «1С УНФ»
Партионный учёт — метод учёта товарных запасов, при котором каждая партия — однородные товары, поступившие от одного поставщика по одному документу либо по нескольким документам, но одновременно, а также товары, поступившие от одного поставщика одним видом транспорта — учитывается обособленно.
Партионный учет позволяет отслеживать четкую дату и время закупки, поставщика, место закупки, фактический остаток товара на складе. Это важно при ведении интенсивной торговли или реализации товаров с коротким сроком годности.
Однажды к нам обратилась компания, занимающаяся производством медицинских препаратов, которой требовалось не только вести очень тщательный учет произведенных партий, так как согласно требованиям законодательства, у контролирующих органов должна быть возможность определить где, когда и кем был произведен конкретный препарат, но и облегчить труд своих сотрудников по отслеживанию этих самых партий.
Партией в данном случае считался товар, произведенный в рамках одной рабочей смены. Ему присваивался определенный номер, который обязательно фиксировался в отгрузочных документах.
Проблемы партионного учета в этой истории состояли в том, что в «1С УНФ» партии приходилось выбирать вручную, что уже составляло определенный дискомфорт, и при этом при подборе товаров не были видны остатки по партиям.
Менеджер, который принимал заявки и формировал расходные документы в «1С УНФ», номер партии в заказе покупателя не указывал, оставляя это на кладовщика. Последний же, в свою очередь, должен был, исходя из объема и ассортимента, подобрать партии, контролируя при этом остатки по каждой из них. Причем все эти подборы должны были производится быстро и оперативно, чтобы минимизировать простой транспорта заказчика.
Например, менеджер формировал заказ покупателя (названия препаратов условны) на 10 коробок аспирина. А кладовщик должен был отгрузить и учесть все по партиям: 1 коробка аспирина с остатков партии 1501, 6 коробок с партии 1502, 3 коробки с партии 1503.
Ситуация усугублялась тем, что в процессе сбора заказа менеджер мог менять его состав (произошла замена транспорта от заказчика, или просто поменялись планы на закупку), в итоге кладовщику приходилось в сжатые сроки переформировывать в «1С УНФ» заказы покупателя, помня про партии, сроки годности и прочие нюансы работы с медпрепаратами.
Еще один нюанс проблемы состоял в том, что в рамках партионного учета в «1С УНФ» можно было включить контроль остатков по партиям, но тогда система не позволяла продать в минус. То есть, менеджер не мог сформировать документ реализации на 10 коробок аспирина, так как в вакантной партии 1501 была только одна коробка.
Партии в 1С УНФ: решение
Представители заказчика предполагали решить эту задачу следующим образом: реализовать возможность отражения остатков по партиям в расходных документах «1С УНФ». Но наши специалисты отговорили их от такого подхода, так как это повлекло бы неоправданно большой объем работ по переделке типового функционала, и последующие сложности с обновлениями.
«Если сделать такой документ, то придется полностью повторить все движения по записям базы данных, которые сейчас есть от заказа в накладную, - поясняют наши специалисты. - Это очень трудоемко, так как требует переделку одного их основных механизмов 1С. Создание заказа, а на его основе накладной — это базовый процесс. В эту связку лучше не влезать».
Второй вариант — обратиться к отчету по партиям в «1С УНФ», в котором можно будет смотреть все остатки. Но в этом случае, не решается проблема с оперативностью обработки заказов покупателей, ведь постоянное обращение к отчету — это неудобно, и создает условия для ошибки при копировании номера партии из отчета в заказ.
Наши специалисты предложили свой вариант, который удовлетворил заказчика и позволил решить проблему с минимальными затратами.
Новый документ для менеджера и кладовщика в «1С УНФ»
Так как вносить какие-либо изменения в типовой функционал не самое лучшее решение, специалисты «Гигабайт» предложили создать новый документ, в котором бы фиксировались все операции с заказом, которые производились менеджером и кладовщиком.
«Мы сделали документ, который создавался параллельно накладной и заполнялся на основании заказа, сверяясь с ним и уведомляя об отклонениях».
В результате нововведения, схема работы с заказом стала следующей:
-
Менеджер комплектовал заказ покупателя в «1С УНФ».
-
На основании заказа он же создавал документ Сборки для склада.
-
Кладовщик формировал отгрузку на основании Сборки для склада.
Идея состояла в том, что новый документ (Сборка для склада) состоял из 2-х частей: за первую отвечал менеджер, за вторую кладовщик. Каждый из них мог видеть изменения, произведенные коллегой, но не мог вносить в них правки.
Например, менеджер заполнил на основании заказа документ, в котором зафиксировалось требуемое количество товара. Далее он может вносить изменения (если заказчик потребовал что-то поменять), но первоначально указанные цифры остаются неизменными. А новые значения подсвечиваются. То есть, незаметно изменить первоначальную потребность менеджер уже не может.
Кладовщик, в свою очередь, так же не мог корректировать данные введенные менеджером. Он мог редактировать только свою часть документа. При этом при заполнении каждой строки происходила проверка ассортимента по складским остаткам по каждой партии. Все отклонения подсвечивались.
Кроме того, для списка документов были настроены флажки, которые указывали на статус заказа: скомплектован, готов к отгрузке, скомплектован частично, не скомплектован.
Таким образом, если менеджер что-то меняет в заказе, то кладовщик это сразу узнает, так как документ меняется в статусе. Открыв список, он может сразу увидеть все подсвеченные документы и скорректировать отгрузку.
А при выписке документа, даже если менеджер добавил новый товар в заказ, кладовщику уже не надо ходить по складу и искать, есть ли данный товар, достаточно открыть список партий и увидеть остатки по каждой из них.
Плюсом было то, что в этом новом документе отражалась информация о последнем редактировании, то есть, всегда было понятно, кто вносил крайние правки.
Положительным моментом являлось и то, что кладовщик не получал доступа к редактированию накладных. Как отмечают наши специалисты, это важный момент, на котором настаивают многие заказчики: работники склада не должны иметь доступ к документам, относящимся к финансам.
В результате внесенных доработок, помимо оптимизации процесса создания и обработки заказа, а также учета партий, компания-заказчик получила определенный контроль за работой менеджеров и кладовщиков. Так как права доступа оказались разграничены, стало возможно в некоторой степени отслеживать качество работы сотрудников. В частности, теперь можно было примерно понять, сколько времени у кладовщика и менеджера занимает работа с измененными заказами, и насколько оперативно они решают эти задачи.
Читайте также:
Остались вопросы?
