Изменение цен на лицензии - С 01 мая 2023 г. изменяется стоимость лицензий VOGBIT

Последние темы на форумах VOGBIT

Unable to cast object of - Ошибки в работе
Владимир Белов: написал: Теперь у меня есть хобби - в свободное время пытаюсь запустить vogbit на новом компьютере. Базу данных удалял потому что восстано ...
Терминал - Терминалы
Balukov: Здравствуйте! Проверьте пожалуйста у сервера и самого терминала настройки питания и спящего режима. Возможно какое то из устройств отк ...
Расчет потребности и ЛЗК - Общие вопросы
Yzolotukhin: написал: написал: А для чего тогда состав изделия в конструкторской документации, если все берется из технологии? Тут так в двух сло ...
Автозаполнение Тшт в технологии - Состав и технология
Trudovaya-21: Большое спасибо! Очень помогли!
Папки - Общие вопросы
Владимир Белов: А пока мы исправляем ошибку - вместо крестика можно использовать кнопку сворачивания.
Настройка столбцов в Номенклатура - Основная - Состав и технология
Yzolotukhin: написал: написал: То есть нельзя сделать чтобы этот столбец появился в основной таблице? Немного устарел ответ (сообщение #4). Актуал ...
График производства - Прочее
Veruz: Спасибо, получилось.
Передача остатков склада из 1с склад - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Сделать реально. Есть API. Можно из внешнего приложения законнектиться к базе данных VOGBIT и в нужный момент вытащить нужну ...
Ошибка создания отчета - Отчёты
Abdrahimov: Спасибо, решено
Предварительные заявки и Лимитные карты не попадают в папки - Ошибки в работе
Alex-220781: Я, наверное, с группировкой перепутал. А как идею можно рассмотреть. Чтобы созданные документы сортировались по папкам.
И снова про брак... - Материалы, Комплектующие, Складской учёт
Kovyrkin: Здравствуйте, Константин. написал: Вообще, в большинстве случаев определение и фиксация брак или не брак - это компетенция не оператора, ...
Сменное задание - Производство
Константин Чилингаров: Здравствуйте, Да, можно так сделать. Шаблон отчёта нужно соответствующий настроить. Пришлите, пожалуйста, на почту, какие этикетки дол ...
Задания - Общие вопросы
Константин Чилингаров: Здравствуйте, Дело в том, что демо-пример "/support/19454/ Движение заказа " сделан полностью на "/articles/5286/ среднем " уровне, и в данном ...
Удаление операции из техпроцесса - Состав и технология
Константин Чилингаров: Здравствуйте, Существуют задания для производства, которые ссылаются на эту операцию (на основе неё созданные). Они не дают удалить опе ...
Проблема с подключением к базе данных - Установка
Константин Чилингаров: Здравствуйте, написал: После первой установки все работало нормально и где то через месяц работы все поломалось. Обновление ОС пост ...
Создание заказа на производство с учетом остатков/задела - Прочее
Константин Чилингаров: В целом, проблема понятна. Будем думать, конечно, как улучшить. По мере наличия времени. К сожалению, не получается всем одновременно зан ...
Чистка базы - Прочее
Константин Чилингаров: Здравствуйте, написал: Хотим почистить базу для того что бы ускорить работу Вогбит, есть много позиций в номенклатуре, которые... Име ...
Статистика производства - Производство
Константин Чилингаров: Здравствуйте! написал: При открывании статистики появляется окно ошибки см.скрин Это где-то в задании один и тот же работник указан 2 ...
Удаление ошибочно внесенных позиций, восстановление данных после удаления заданий. - Прочее
Константин Чилингаров: Небольшой совет по теме: Никогда не храните созданные файлы резервных копий базы данных там же (на том же компьютере/диске), где и сама ...
Планирование, загрузка производства - Прочее
Константин Чилингаров: Поскольку этот старый модуль считает долго, там технология была такая: Расчёт выполнялся на какой-то момент времени. На актуальных на эт ...

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

- Общие вопросы - Старые разделы форума
Страницы: 1
Учет остатков на производственном участке
 
Добрый день!
Столкнулись с проблемой учета остатков на производственном участке. В программе на вкладке "Складской учет" есть конечно функция "Затраты план-факт", но ее не достаточно т.к. этот перерасход нигде не учитывается.
Возможно конечно самому учитывать этот остаток, но опять же не понятно куда его приписать... Если мы создадим к примеру что-то похожее на склад при участке, к примеру назовем его "Производственные остатки 41" возможен ли такой вариант?
Каким образом будет формироваться лимитная карта? Ведь получится, что например "крышка жф5.890.453" будет числиться и на "складе комплектующих 81" и на "производственные остатки 41", либо какой-нибудь лист металла и т.д.
 
Здравствуйте!

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

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

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

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

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

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

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

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

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

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

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

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

- и так далее.

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

Заниматься перечисленными доработками мы, в принципе, готовы. Но при наличии спроса. Например, если будет кто-то этими задачами реально у себя на предприятии заниматься, именно в таком разрезе, и регулярно оплачивать поддержку. В таком раскладе можем хоть все из вышеперечисленных дополнительных возможностей реализовать. Принципиальным вопросом является то, что нужен кто-то, кто будет реально этим пользоваться. На практике, а не в теории. Пока из тех пользователей, с кем мы плотно общаемся, и кто, я знаю, активно работает в нашей программе каждый день, пока никто подобными вопросами не интересовался ещё.
 
Здравствуйте, Константин!
Для нас наиболее приемлемый вариант был бы с учетом остатка на производственном участке. Таких участков к примеру у нас на предприятии, может набраться около 15. Каждый из которых будет закреплен за мастером на данном производственном месте.
Например за мастером Ивановым И.И. закреплено 3 участка:
№1 Сборочный участок ЛЭМ-3
№2 Сборочный участок ТЭДК-07
№3 Сборочный участок МТ10М
Все остатки которые есть на этих трех участках должны числится к примеру вот так:
«Производственные остатки 41» Иванов И.И.
Ну и т.д. по за каждым мастером…
«Производственные остатки 42» Петров А.А.
«Производственные остатки 43» Сидоров В.В.
В программе за этими мастерами должен учитываться перерасход который был им выдан со склада сверх ЛЗК.
При формировании ЛЗК на производственный заказ, программа должна определять «Производственные остатки 41» Иванов И.И. как первичный источник для формирования ЛЗК, а если вдруг данных остатков будет не хватать для исполнения заказа, то дополучить необходимую комплектацию еще и с основного «Склад комплектующих 81» Петрова А.А.
Таким образом мы получим ЛЗК под двумя номерами:
ЛЗК 187545 «Производственные остатки 41» Иванов И.И.
ЛЗК 187546 «Склад комплектующих 81» Петрова А.А.
При выдаче со «Склад материалов 82» Сидорова А.А. например произошел перерасход материала. К примеру затребовано было 1 кг Пластиката ИЩ45-12 ГОСТ5960-72, а на деле кладовщик отпускает не 1 кг а к примеру целый мешок фасовкой в 50 кг.
Таким образом у нас получился перерасход в 49 кг!
Хотелось бы конечно, чтобы программа могла учесть этот перерасход и учесть его на остатках к примеру на «Производственные остатки 41» Иванов И.И.
Не плохо может было бы делать приход, как вы уже сказали по подобию «Склад ГП». Таким образом мы получим четко подсчитанный остаток по позициям с перерасходом материала и нам останется только создать этот приход.
Вот как программа должна понять, что данный перерасход должен числиться на «Производственные остатки 41» Иванов И.И. это конечно вопрос…
Возможен ли какой-нибудь вариант исполнения с учетом выше сказанного?
 
С моей точки зрения, в изложенной вами логике есть несколько серьёзных ошибок. Будет время, напишу подробнее.
 
Начал писать длинный подробный ответ, почему так  работать не будет. Получается нереально длинно. Бросил…

Лучше напишу, как будет работать.

Сначала по вашему предложению:

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

Вот в таком виде «трёхуровневая» система будет работоспособна. Наверное...
Вот только оно вам надо? У вас же не холдинг, я так понимаю, а одно предприятие, причём не очень большое.

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

Кроме того, такая «трёхзвенка» сама по себе не решит вашей проблемы. Ведь рассчитать по норме 1 кг, а получить 50 кг ибо «1 мешок», легко можно, как с «главного» склада, так и точно так же и с «промежуточного»… То есть, если отталкиваться от вашей проблемы, то она никуда не делась, несмотря на все усложнения. Она точно так же и осталась, просто "передвинулась" в другое место.

Теперь по поводу, как мне кажется, надо делать.

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

А уж если вы это сумеете наладить, то дальше есть варианты в разы более действенные и простые. Зачем создавать такую сложную систему с лимитками туда, лимитками сюда? Зачем Иванову лимитно-заборная карта на получение материала Ивановым у Иванова для Иванова? И отмечание, что Иванов выдал со склада Иванова материал Иванову по ЛЗК такой-то. Для чего это всё?
Уж если будет информация по остаткам в цехе, то:

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

б) если вести учёт не по каким-то виртуальным промежуточным складам, а прямо по местам потребления материалов/комплектующих, то можно сделать элементарную вещь. Чтобы при выдаче по ЛЗК, например, показывался текущий остаток соответствующего материала не только  там, откуда выдаётся, но и текущий остаток  там, куда выдаётся. И если это будет сразу видно, то масса вопросов может отпасть сама собой.

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

Есть, просто, у меня смутное подозрение, что вы как-то не так себе это представляете.
Страницы: 1
Сейчас на форуме
Всего зарегистрированных пользователей: 3804
Приняло участие в обсуждении: 403
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт