Учет остатков на производственном участке

Здравствуйте!

Если речь идёт о том, чтобы ,бороться с необоснованным перерасходом материала, то в организационном плане существует, как минимум, два варианта решения.

1. Запретить оставлять что-либо на участке. Обязать то, что осталось, сдавать обратно на склад.

2.Вести на участке реальный  учёт остатков материала, делового отхода, комплектующих и т.п. Можно на бумаге в виде журналов. Можно в программе, например, в VOGBIT. И корректировать нормы, лимиты и выдачу по ним с учётом этой информации.

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

Что касается программной реализации.

По варианту 1:
Технически решается оформлением в VOGBIT учётного документа на приход материалов из цеха обратно на склад. Можно вручную создавать этот документ, можно через стандартный модуль Складской учёт - Приход.
Для начала, нужно физически организовать сам процесс возврата, и любым из указанных способов просто фиксировать его в системе. Чтобы реальное движение и остатки отражались в программе. Дальше при желании можно развивать. Например, придумать какую-нибудь функцию возврата не просто, вручную заполняя список, а отталкиваясь от того же документа основания, по которому получали то, что возвращают. Типа, как сейчас сделано в Складской учёт – Расход, только наоборот (правда, не уверен пока, нужно ли это вообще в таком виде или нет, удобно ли будет пользоваться? пробовать надо). Ещё не так давно на форуме поднимался вопрос учёта "возврата" в режимах типа "фактические затраты". Тоже можно, в принципе, сделать, но есть ряд вопросов логического плана. Да и ажиотажа никакого вокруг этого вопроса не возникло. Поэтому пока стоит в плане, как перспективный с непонятным сроком реализации.

По варианту 2:
Решается  заведением в программе ещё одного «склада». Где вести учёт движения материала в цехе. Что и сколько пришло (с главного склада), сколько реально потратили (ушло).
При создании лимитно-заборной карты, в текущей версии программы, в качестве подразделения, где получать материал, автоматически берётся последнее, куда такой материал поступал.
Такая логика действительно не сказать, что очень «заточена», под сложную систему учёта с центральными складами, отдельно цеховыми складами и т.д. Лучше всего она подходит для варианта, когда материал или покупные изделия соответствующего типа лежат на предприятии где-то в одном месте, и при запуске очередного заказа на производство создаётся лимитно-заборная карта на получение необходимых для этого заказа материалов и комплектующих в этом самом месте. На текущий момент, в подавляющем большинстве случаев наших заказчиков устраивает именно такой вариант. Без излишних «наворотов».
Но при желании можно и «с наворотами». Как минимум, помимо лимитно-заборных карт есть в VOGBIT такая штука, как Заявки. Создаются точно так же и там же, где и лимитные карты. По содержанию - то же самое, но с одним отличием – в них вообще не написано изначально, где получать. Можно потом приписать хоть цех, хоть склад, хоть что. Самому можно назначить (выбрать), где получать.
Ну и есть ещё «ручной» вариант оформления учётных операций. Через Расчётные и Учётные документы. Более трудоёмко, конечно, и квалификации пользователя требует повыше, но зато можно вариант учёта любой сложности воспроизвести. Как говориться, было бы желание.

Что касается направлений для доработки программы, то их в этом направлении возможных и вовсе масса. Например:

- можно подумать над тем, как лучше организовать формирование лимитно-заборных карт, в случае, когда несколько складов с одним и тем же. Например, можно добавить для материалов, что-нибудь типа «места получения по умолчанию» или «главного места хранения» (или для сочетания получатель/материал?).

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

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

- можно приделать какой-нибудь упрощённый интерфейс для оформления «перемещения» материалов из одного подразделения в другое;

- и так далее.

По перечисленным возможным доработкам:
Все описанные действия (передача материала со склада в цех, списание в цехе, перемещение обратно) при желании в программе технически можно сделать и сейчас. Правда не все так легко и непринуждённо, как, к примеру, простой приход и расход. Но можно. Доработки выливаются в создание более удобных интерфейсов пользователя для выполнения указанных функций. В некоторых местах могут быть вопросы логического характера, которые чтобы решить, желательно иметь хоть как-то организованный сам процесс подобного учёта на участке.

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

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