Новая версия VOGBIT 20.5 - Новая платформа: быстрее, надёжнее, удобнее. Новая подсистема управления приоритетами в производстве. Новые возможности для участков ЧПУ. Улучшенные «цеховые терминалы». Новые возможности для совместной работы менеджеров, инженеров и производства при изготовлении уникальной продукции под заказ. И многое другое…

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

Систематическая ошибка - Ошибки в работе
Алексей Батраков: Во время работы в программе, периодически (раз в 2-3 дня) возникает ошибка. И еще, при распределении работ (высокий уровень) по сменам, ооооочень долго стали переносится задания. 
Пропадают спецификации и техпроцессы - Прочее
Наталья Захарова: Здравствуйте. Прошу помочь разобраться в чем может быть проблема. Работаем в программе уже больше года. Заполняем номенклатуру изделий, для изделий вносим спецификацию и создаем техпроцессы. С прошлой недели начали замечать, что некоторые спецификац ...
Аналоги в материалах - Материалы, Комплектующие, Складской учёт
Илья: Еще вопрос: можно ли списывать материал без оформления заказа? Просто что бы учет был: пришло-ушло. Без привязки куда.
Календарный план - Прочее
Alex-220781: Система Win 10
Не отображается место хранения - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: 19032 Илья написал: Хотя  данный параметр добавлен в связанные компоненты Вот это вы зря время потратили. Не нужно было так прицеплять. Нигде не написано, что нужно так делать. "Место хранения" берётся из складской картотеки. По умо ...
Последовательность операций - Производство
Константин Чилингаров: 3938 Алексей Пономарев написал: если эта кнопка не нажата то деталь должна появляться в первой операции Если кнопка не нажата, то колонка "Операция" вообще смысла не имеет. Нужно убрать её. Настройки колонок в режимах "просто Граф ...
Пустой бланк - Демо версия
Илья: 13 Константин Чилингаров написал: /forum/user/19032/ Илья написал: Про стандартный крепеж так и не понял. 1. Если указываю его в тех процессе то он попадает в производственный заказ. Это как? Каким образом то, что указано в техпроцесс ...
Как лучше описать технологию? - Состав и технология
Константин Чилингаров: Здравствуйте, Думаю, нет смысла в данном случае изобретать велосипед. Просто делать разные изделия (контроллер с одной платой - одна номенклатурная позиция, с другой платой - другая), копировать и заменять, что отличается Трудоёмкость такого дейс ...
Экспорт/Импорт данных - Экспорт импорт данных
Константин Чилингаров: Чтобы перенести базу с LocalDB на SQL server, сделайте с помощью Management Studio /support/380/#__backup резервную копию . Потом на SQL сервере из этого файла (бэкапа) разверните базу. Если сервер не на том же компьютере, то нужно будет, наверное,  ...
Дополнительные колонки в составе изделия - Состав и технология
Константин Чилингаров: куда все делось? Вы всю группу колонок "Компонент" удалили с экрана. 19032 Илья написал: Как вернуть то что было по умолчанию? Обратно перетащите.
Свяванные объекты - Прочее
Константин Чилингаров: Нужно для этого пользователя /support/474/#763_1232331032 настроить доступные "зависимые окна" (зайти под этим пользователем и настроить). Форму нужно выбрать: Csdn.Vogbit.Mail.LinkedObjectsForm  Связанные объекты (рис.1). Дальше выб ...
Установка программы для терминалов. - Установка
Константин Чилингаров: RFID нужен для авторизации. Чтобы подошёл рабочий к терминалу, и ему не нужно было ничего вводить (типа Имя, Пароль), ничего выбирать. Просто приложил свой "пропуск" (брелок, браслет), терминал понял, что это "Иванов" пришёл, и в ...
Очень долго открываются обороты - Прочее
Константин Чилингаров: Здравствуйте, Какая версия программы? Базу (копию) можете дать посмотреть?
Прошу помощи в установке - Установка
Владимир Белов: Ок, спасибо, проблема стала понятна.
Создание, удаление, и создание вновь заданий - Производство
Константин Чилингаров: 19032 Илья написал: Не удается создать задание на среднем уровне /support/552/#_Toc400385408 Наиболее типичные причины . Сообщение с вашей картинки - первое по списку. 19032 Илья написал: Это может быть связано с отсутствием норм времени? ...
Сортировки в сменном задании - Интерфейс программы
Алексей Батраков: Спасибо, будем очень благодарны. 
Ошибка при создании отчета "Заказ на производство (цвет)" - Ошибки в работе
Алексей Батраков: Работает, спасибо
Сортировка производственных заказов - Производство
Константин Чилингаров: Понятно. Это из-за того, что в смене есть "внеплановое" задание. Это оно не может "передвинуться". "Нормальные" задания, связанные с какой-нибудь деталью (позицией заказа на производство), сдвигаются, раздвигаются, п ...
Проблема со справочником "Номенклатура" - Общие вопросы
Константин Чилингаров: Предупреждение! [B Нарушение /forum/rules/ правил форума , п.6.[/B ответ /forum/messages/forum39/topic2591/message15964/2591-sortirovka-papok-po-alfavitu#message15964 здесь
Сортировка папок по алфавиту - Интерфейс программы
Константин Чилингаров: В этой версии по умолчанию отключено, как редко используемая функция. Поскольку можно самому расставлять папки в любом удобном порядке, чем, в основном, все и пользуются. Кроме того, в 20.5 появилась возможность быстрого поиска папки по Ctrl+F. (ещ ...

склад

Всё, что связано с расчётами и учётом материалов, покупных изделий, комплектующих и др. ТМЦ - Материалы, Комплектующие, Складской учёт - Работа с программой
Страницы: Пред. 1 2 3 4 5 6 След.
[ Закрыто ] склад, приход материала на склад
 
Цитата
Нина Аленцова пишет:
К чему вести в программе производственный процесс, если в результате выполненной работы невозможно предоставить отчет за выполненные заказы?
Классическая подмена понятий.

Целью производства является создание добавленной стоимости. Т.е. по возможности максимально быстрое и с минимальными потерями превращение материалов и комплектующих на входе в продукцию, нужную заказчику на выходе. А не создание отчётов.
Больше и быстрее продукции сделаете – больше денег. Меньше – меньше денег.
А за отчёты, которые вы делаете внутри предприятия, вам заказчик денег не даст. Ни за какие. Нисколько. Вообще.
Это к вопросу о том, зачем вообще программа.

Цитата
Нина Аленцова пишет:
Требование бухгалтерии таково, что склады должны предоставлять ежемесячные, ежеквартальные позаказные отчеты по движению материалов в бухгалтерию
Ага  :)
А дальше будет вот так (100%):

Списали некий материал на деталь «А», на заказ «123». Отдали отчёт в бухгалтерию.  А потом через 2 месяца выяснится, что деталь «А», на которую уже посчитали этот материал на заказ «123», на самом деле поставили в узел для заказа «345», потому что он сейчас нужнее…
И что?
Правильно... Будем переписывать всё задним числом. «Переносить затраты с заказа на заказ...
Знаем, знаем…. Плавали  :)

А потом еще через месяц окажется что узел этот целиком поставили в изделие на заказ «789», потому что он в этот момент стал самым важным.
Отлично! Опять начинаем всё переписывать… И так до бесконечности. И главное с нулевым смыслом. Зачем первые то 2 раза вообще записывали эти затраты сначала на заказ «123», а потом на заказ «345»? Если в итоге оказалось, что и то, и другое – все равно не так.
Очень полезно провели время...

Отметим также к тезису в начале этого сообщения: в плане основной деятельности производства (откуда берутся деньги), мы всей этой своей многомесячной деятельностью не сделали НИЧЕГО. Мы вообще никак ей не повлияли на создание добавленной стоимости. Зато поработали… Позаписывали, попереписывали...

Я выше писал своё мнение. Что по уму эту задачу, если уж и решать, то лучше вообще по-другому. С другой стороны.

Цитата
Нина Аленцова пишет:
данные для бухгалтерии по количеству использованного на каждый заказ материала
Приложив определённые усилия сделать такое можно. Но точно не через оформление на складе выдачи одного куска материала, якобы 10 частями на разные заказы.

Можно теоретически задаться целью (может, доработать где-то что-то, если потребуется), и сделать автоматическое формирование некоей «ведомости» - сколько в теории потрачено "на заказ". Хотя это будет просто бумажка "потому что требуют". Смысла в ней от этого не появится...
Ну да Бог с ним...
Что сделано, якобы "по заказу", как-то добыть (ввести) можно. Материалы и количество брать по нормативам. Цену определять, как в модуле «себестоимость»: по цене последней покупки, по средней цене на складе, или по заданной (какой сами скажете).
И печатать "ведомость затрат".

Но тут помимо трудозатрат на это мероприятие есть 2 принципиальных вопроса:

1. А готово ли реально ваше производство снабдить вас данными для этого?

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

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

Цитата
Нина Аленцова пишет:
ждать именно от складов ежемесячного отчета из Вогбита, сколько каких материалов было выдано на определенный заказ
Даже если оставить за скобками саму осмысленность такой задачи, то всё равно возникает некий когнитивный диссонанс.

Я еще как-то могу понять, требовать отчитываться, куда потратил материал, от того, кто его, собственно, потратил. Но почему отчитываться о том, на что конкретно потрачен материал, должна служба, которая отвечает за хранение этого материала? От момента его поступления до выдачи тому, кому он нужен. А когда материал из склада выехал за ворота, откуда склад знает, что дальше произошло с этим материалом? Как он может за это отчитаться?
 
Все, что Вы описали - абсолютно верно и мне понятно, но никто из руководства читать то, что Вы написали и, тем более вникать, не будет. А будет ждать, что когда мы все дружно заработаем в программе, мы сразу поймем сколько чего израсходовано на каждый заказ в любой момент времени.  Я, понимая, что данная программа, если не извращаться и не придумывать каких-то отчетов, как Вы сказали, этого сделать не может, в ней можно вести складской учет, но не создавать отчетность по затратам на каждый заказ. Хочу объяснить своему руководству, чтоб не ждали чудес.То есть ответ нет?
 
Если вопрос ставится как: будет ли программа "автоматически разносить затраты по заказам" в момент выдачи материала со склада?
То ответ - Нет. Не будет.
Выше - 2 страницы объяснений, почему.
 
Цитата
Нина Аленцова пишет:
данная программа, если не извращаться и не придумывать каких-то отчетов, как Вы сказали, этого сделать не может, в ней можно вести складской учет, но не создавать отчетность по затратам на каждый заказ
Еще раз на всякий случай отмечу:
Проблема не в том, чтобы создавать отчётность на каждый заказ. А в том как это делать.

Да. Бывают действительно такие производства, где не то, что в момент выдачи – уже в момент покупки материала точно понятно, куда он пойдёт. Бывает такое. Но не так часто.
И это не ваш случай.

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

Это не проблема программы – это производство у вас так устроено.
Оно так работает. И это правильно. Ибо если вы будете его заставлять по одной штуке отдельно на каждый заказ делать каждую деталь, вы вообще никогда так ничего не отгрузите. Учёт будет супер! Только заказчиков не будет. Нечего станет учитывать...

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

И ещё один интересный момент:
Цитата
Нина Аленцова пишет:
мы сразу поймем сколько чего израсходовано на каждый заказ в любой момент времени
Ваше руководство ставит такую цель. Но не учитывает того, что если вы таки сможете наконец этой цели достичь тем или иным способом, то затраты общие на выполнение заказов у вас не уменьшаться в результате. А возрастут.
 
Спасибо за развернутый ответ. Переслала нашу переписку, начиная с 11 страницы, гл. бухгалтеру - она не поверила, что затраты по дробям она в ближайшую пятилетку не получит.
 
Добрый день. Производственники начали выписывать ЛЗК на комплектацию продукции.Возникла непонятная ситуация:  кладовщик получает покупное комплектующее изделие и ставит его на приход с привязкой к номеру группы. Когда ПРО выписывает расходный документ на это изделие, цепляя позицию из номенклатуры, то программа выдает информацию, что этого изделия нет на складе - остаток "0", хотя на складе это изделие есть. Мы подумали, что дело в том, что кладовщик при постановке на учет создал группу учета, а производственники, при выписке требования не указали на какой заказ берут это изделие, но говорят, что указывают на какой заказ. У меня такое чувство, что они все-таки не привязывают получение этого изделия  к группе учета. Указывают где-то № заказа, но к группе учета - не привязывают. Кстати, эта номенклатурная позиция в базе одна. Задвоения точно нет - проверено словом "задвоение", которое я ввела в первую номенклатурную позицию для проверки задвоения и оно тут же самопроизвольно появилось во второй строке. Это видно на скриншоте - и в первой и во второй строке есть слово "задвоение". На производственном складе тоже такая ситуация была. Кто чтоделает не так?
 
Здравствуйте,
Цитата
Нина Аленцова пишет:
Мы подумали, что дело в том, что кладовщик при постановке на учет создал группу учета
Да, дело в этом.

Если учётные группы используются (это включено в настройках), то имеет значение, где именно лежит та или иная позиция (остаток). Просто на складе – это одно. В какой-то учётной группе на этом складе – это другое.
И запрос (документ-основание, т.е. ЛЗК или Требование) должен быть на получение из конкретного места.
Если в документе основании написано получить с «просто склада», то и будет смотреться остаток на «просто складе», ни в какой группе (ваш случай, судя по всему).
Если вы хотите получить из остатков по какой-то конкретной учётной группе, то и в документе основании должно быть указано, что из этой группы получать (рис.1). И при получении по такому документу важны именно остатки в этой указанной группе.
В этом смысл данного механизма (учётных групп).
1.png (82.01 КБ)
 
Проблема в том, что остаток не лежит нигде: мы его переносим из TSC по  определенным позициям после того, как нам приносят требования-накладные, через вкладку "создать приход", как было сказано Вами ранее.
По предыдущему вопросу выяснилось, что кладовщик задвоил группу учета, поэтому получилось, что группа учета, вроде, одна, но на самом деле их было две одинаковых. После того, как это выяснилось, я попробовала удалить приходные накладные, которые были созданы с привязкой к задвоенным группам учета, но программа, даже после их удаления, не дает удалить задвоенные группы учета, говорит, что нельзя удалить используемые группы учета.  Что на них может еще висеть, что я не удалила? ведь я удалила расчетные, учетные документы, карточки перенесла на другие группы - это первый вопрос. И второй - можно ли сделать так, чтоб номера учетных групп могли заносить, только определенные люди, например - конструктора? Где поставить галочку в настройках?
 
Цитата
Нина Аленцова пишет:
Проблема в том, что остаток не лежит нигде: мы его переносим из TSC поопределенным позициям после того, как нам приносят требования-накладные, через вкладку "создать приход"
Без разницы.
В данном случае не важно, в какой момент и руководствуясь чем вы оформили «приход» в VOGBIT. Остаток есть в результате. Если используются учётные группы, то этот остаток попал либо в какую-то группу, либо просто на склад, без группы (в соответствии с тем, куда приход оформляли). Соответственно, там он и «лежит».

Цитата
Нина Аленцова пишет:
кладовщик задвоил группу учета
Ставьте группам учёта обозначения. Они уникальные. «Задвоить» не получится.

Цитата
Нина Аленцова пишет:
Что на них может еще висеть, что я не удалила?
Учётные карточки пустые.
При оформлении прихода в базе данных появляется расчётный документ, учётный документ и новые карточки (подробнее). Можно разоприходовать и удалить документы. Но карточки останутся после этого (пустые, соответственно). И они связаны с учётной группой (учётная карточка -> связанные объекты).

Если лень/сильно сложно искать/удалять, то просто переименуйте «неправильную» учётную группу и снимите у неё галочку «активна». И всё. Она спрячется и не будет вам мешать. Можно не удалять.

Цитата
Нина Аленцова пишет:
можно ли сделать так, чтоб номера учетных групп могли заносить, только определенные люди
Добавлять/редактировать учётные группы может пользователь со статусом «Администратор». Это единственное ограничение.
 
Добрый день. У меня вопрос по внедрению программы в  отдел закупок. Мы пытались, но ничего не нашли. Подскажите, пож., ссылкой, где можно найти эту инфу. Мы не можем понять:
1 - в каком месте процесса этот отдел вступает в "игру", т.е. что должно быть уже занесено в программу до них, чтоб отдел закупок смог выполнить свою часть работы в программе?
2 -какую конкретно информацию они должны заносить в программу, чтоб внести свой вклад в "общее дело"?
 
Здравствуйте,

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

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

Остальным от этого польза в том, что видно, какие дефицитные позиции уже заказаны, а какие ещё нет. Когда заказано, у кого, сколько.

Используются для этого режимы «Обеспеченность» (расчёт дефицита – что, собственно, покупать нужно) и «Заявки на закупку» (всё остальное из перечисленного выше). Немного об этом есть здесь.

Чтобы снабжение могло реально в своей работе всё перечисленное использовать, должно чётко и отлаженно работать всё остальное. В первую очередь производственная часть, которая является источником информации, что реально требуется, и склад, который является источником информации, что есть в наличии. Без этого просто не будет актуальной информации исходной. И толком пользоваться чем-то в части снабжения будет невозможно.
 
Спасибо за ответ.
Возникла еще одна проблема по перенесению остатков из программы TCS в Вогбит. Мы переносим их, как ранее Вы и говорили, в момент поступления на склад продукции по приходным и в момент выдачи со склада по расходным документам. И вот что получается: на склад приходит покупная продукция, кладовщик ставит ее на приход на определенную группу учета, т.е. на тот заказ, на который эта продукция была закуплена. В момент оприходования, он переносит полностью остаток по этому наименованию из TCS в Вогбит. Но проблема состоит в том, что весь остаток, который он перенес, автоматически падает на тот же заказ (группу учета), на который он оприходует поступившую накладную (кладовщик при этом, оприходовал весь перенесенный остаток на  другую карточку).
После этого, когда на склад поступает расходный документ на какой-то другой заказ, т.е. документ априори привязан производственным отделом к другой определенной группе учета, кладовщик открывает его и понимает, что взять что-то из перенесенного из TCS остатка на другой заказ он не может - программа не позволяет.Что делать в такой ситуации? Мы уже перенесли таким образом очень много остатков и сейчас выясняется, что все они повисли на тех группах учета, которые были указаны в приходных накладных.
 
Второй вопрос:
На склад межзаводской кооперации (МЗК) поступили детали из производства для отправки их на доработку в стороннюю организацию.  Производство создало накладную и предало детали на склад МЗК. Кладовщик отправил их на сторону. Детали доработали и вернулись обратно на предприятие. Какая-то часть из них сразу же пойдет на дальнейшую обработку в наш цех, а какая-то ляжет на склад готовых деталей, т.к. это была для них последняя операция. Мы не можем договориться с производством, кто должен брать детали со склада МЗК и класть детали на склад готовых деталей. Они утверждают, что они будут брать по требованию только те детали, которые должны далее пойти в производство, а кладовщик МЗК, получивший эти детали после доработки на стороне должен сам переместить оставшееся количество на склад готовых деталей, т.е он должен создать в программе на оставшееся количество накладную на внутреннее перемещение на другой склад, а принимающий склад в программе эти детали примет. Я настаиваю на другом варианте: что производственный отдел формирует в программе требования-накладные и на производство, и на склад готовых деталей, т.е. они решают, что ляжет на склад после последней операции, а что пойдет в производство. Как правильно?
 
Добрый день. Высылаю Вам накладную, по которой производство кладёт на склад готовых деталей свою продукцию. По сути в накладной должно быть всего 2 позиции: 1. Ниппель - ......шт. и 2. Корпус - 1 шт. Но на бумаге и в программе это выглядит так. В действительности же на склад детали сдаются навалом в двух коробках. Кладовщики сначала на калькуляторе подсчитывают суммарное количество по накладной, а только потом пересчитывают детали в коробке. Что нужно сделать производству, чтоб накладная получалась именно в такой форме, как сдаются на склад детали: с суммарным количеством по каждой позиции, без разбивки по заказам?
 
Прошу удалить предыдущее сообщение с фото. Оно было отправлено по ошибке.
 
Фото, которое было описано выше, я пыталась отправить с телефона, но не прошел формат. прошу прощения. Посылаю скрин-шот другой накладной: здесь наименование детали другое и позиция всего одна, но проблема, описанная выше тоже видна.
0000.jpg (396.77 КБ)
 
По поводу остатков и учётных групп:

Подозреваю, что между разговорами про перенос остатков непосредственно при приходе и расходе и разговорами об учётных группах была очень большая разница, как во времени, так и в контексте…

Начнём с того, что механизм ввода остатков при приходе и расходе появился задолго до того, как появилось само понятие «учётных групп».  В своё время он был успешно обкатан (ещё в TCS, кстати) на предприятии с очень большой номенклатурой и 12-ю складами и очень хорошо себя там зарекомендовал. Поэтому, когда речь о вводе остатков, я обычно, упоминаю, что есть такая возможность.
Соответственно, и придумана, и опробована в реальных условиях данная штука была при «котловом» методе учёта. Без всяких «групп».

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

Но при учёте по группам надо учитывать специфику. Когда вы делаете приход в конкретную группу (или расход из конкретной группы), то вы оперируете с остатками только по этой группе.
Соответственно, если вы в этот момент (прихода "в группу" или расхода "из группы") делаете на лету «ввод остатка», то программа воспринимает это, как остаток в этой конкретной группе. Что логично.

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

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

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

Так?

Если так, то могу сказать по сути что делать.
Есть 2 варианта.

1.
Вы, когда получаете детали после обработки, сразу точно знаете, сколько нужно для производства из них, а сколько нужно на склад ГП отвезти.
В этом случае логично сразу их физически поделить и отправить часть на один склад, часть на другой.
В программе, соответственно, так и приходовать. Сколько нужно на один склад, сколько нужно на другой.
И дальше выдавать по мере надобности с того склада, с которого нужно.

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

Это по сути вопроса. Какие действия в программе делаются (они, собственно, соответствуют самому процессу в обоих случаях).

А кто именно у вас будет технически эти действия выполнять (какой отдел/сотрудник) – это чисто ваш внутренний организационный вопрос. Это вам нужно самим между собой решить.
 
Про накладные:

Я пока не очень понял, в чём суть вопроса/проблемы?
Деталей на склад приносят кучу одинаковых, а по накладной – это множество разных мелких партий таких деталей из разных производственных заказов?
Или что?

А делают они их как реально? Эти детали

Запускают кучу партий по несколько штучек, делают их так партиями мелкими, а потом где-то их копят, в одну коробку складывают, и потом в какой-то момент приносят все сразу?
Или они реально делают этих деталей сразу целую коробку (большую партию), и так и приносят её всю на склад?
 
Доброе утро. По поводу переноса остатков из TCS и привязки их к одной группе учета:
когда переносится остаток через оприходование или расходный документ, то его нельзя занести несколько раз, т.е. на каждую группу отдельно. На сколько я помню из руководства, остаток в таком варианте заносится только один раз?
 
Исправьте пож. информацию представленную в руководстве пользователя по складскому учету, чтоб не вводить в заблуждение других пользователей программы.
"Обратите внимание:
Ввести текущий остаток для позиции можно только один раз. Если остаток уже был внесён, то кнопка «Ввести остаток» при выборе соответствующей строчки документа автоматически становится недоступной (Рис. 139). Если остаток был внесён ошибочно, то отменить это действие или откорректировать значение может только администратор.
Такая реализация функции ввода остатков выбрана неслучайно и основана на опыте практической эксплуатации программного обеспечения. Подобный подход значительно затрудняет намеренное искажение (корректировку задним числом) или сокрытие информации недобросовестными сотрудниками."
И далее:
"Рис. 139. Кнопка Ввести остаток неактивна.
Таким образом, информация вносится не по всем складским остаткам сразу, а только по тем позициям, которые непосредственно в текущий момент пришли или выдаются, и прямо в процессе оформления соответствующего документа в VOGBIT (при составлении приходного ордера или расходной накладной). Это не сложно, как правило, занимает немного времени, и вполне можно сделать без какого-либо ущерба для потребителей (производства). В итоге, очередной приходный ордер или расходная накладная уже распечатывается из программы, а по всем перечисленным в документе позициям в базе данных уже присутствует информация по реальным текущим остаткам на складе.

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

Описанная методика не раз применялась авторами в условиях реального складского учёта в производстве и неизменно позволяла добиться хороших результатов. Внедрение новой технологии учёта проходило быстро, безболезненно и главное, без приостановки работы складов."
 
Начала просматривать создание ЛЗК и наткнулась на инф-ю, которая не совсем мне понятна. В складском учете сказано, что остатки складов целесообразнее переносить при поступлении на склад приходных и расходных документов(см. выше), а здесь - что эти расходные документы (ЛЗК) формируются программой, только если определено место хранения материалов. Как программа может определить, где должны храниться материалы, если остатки вводятся только после поступления на склад расходного документа?
"Лимитно-заборные карты предназначены для получения материалов и комплектующих производственными подразделениями на складе. Информация о месте хранения (на каком складе что получать) является необходимой для формирования ЛЗК. При создании лимитных карт все требуемые материалы и комплектующие сразу же автоматически распределяются программой в разные карты в зависимости от того, что на каком складе нужно получать3. Позиции, для которых место хранения неизвестно, не попадают в лимитно-заборные карты. Если таковые встречаются в общем списке, то при запуске функции Сформировать Лимитные карты программа предупреждает пользователя от этом (Рис. 5).
Позиции с неизвестным местом хранения (первая группа в списке, без названия) не попадут в ЛЗК.
Информация о месте хранения берётся программой автоматически из подсистемы VOGBIT Складской учёт (на каком складе находится материал). Появляется эта информация в момент поступления соответствующего материала на склад4."
 
Цитата
Нина Аленцова пишет:
когда переносится остаток через оприходование или расходный документ, то его нельзя занести несколько раз, т.е. на каждую группу отдельно. На сколько я помню из руководства, остаток в таком варианте заносится только один раз?
Да, остаток по идеологии должен заноситься таким образом только один раз.
Чтобы не было почвы для злоупотреблений (произвольной корректировки остатков в любой момент времени под видом "ввода первоначального остатка".

Так задумано.
И в изначальном варианте (без «учётных» групп) ровно так всё и работает.

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

В текущей версии, собственно, сам «ввод остатка» работает правильно.
В т.ч. и при включённых «группах». Всё вводится, в каждую группу отдельно.
Вот только блокировка неправильно, получается, работает при включённых учётных группах (т.к. не рассчитана на это была просто). В некоторых случаях не включается, когда должна, и наоборот, включается в некоторых случаях, когда не должна. Но только, когда "учётные группы" включены.

В общем, надо будет исправить работу блокировки функции «ввод остатков» при «приходе» и «расходе» в случае, когда «учётные группы» включены.
А в остальном – нормально всё работает.
 
Цитата
Нина Аленцова пишет:
Исправьте пож. информацию представленную в руководстве пользователя по складскому учету
А что не так?
 
Про ЛЗК:

Раньше, если на складе не было ещё ни разу такой номенклатуры (в программе), приходилось либо заранее создавать для этой номенклатуры (материалов) "пустые" учётные карточки сначала, чтобы таким образом указать, на каком складе это хранится, и соответственно, создалась нормально ЛЗК, либо сначала (первый раз) использовать не ЛЗК, а "предварительную заявку", которая и без места хранения создаётся.

В современной версии эти ухищрения не нужны.
Если "место хранения" не указано, то можно прямо в окне "расчёт потребности" его и указать. И сформируется ЛЗК сразу.

Причём, вроде бы, даже можно настроить, список подразделений, откуда выбирать это "место хранения", и он может быть свой для каждого участка (когда разные участки получают материалы на разных складах). Что-то такое делали в последней версии.
 
P.S. Большая часть документации будет в следующем году обновляться. Всё описанное в старой документации, в принципе, работает в современной версии. Но очень много новых моментов и возможностей просто в старой документации не описаны.
Сейчас перерабатываем постепенно.
 
"Нина Аленцова пишет:
Исправьте пож. информацию представленную в руководстве пользователя по складскому учету
А что не так?"
В руководстве не указано, что этот метод подходит только без включенных групп.А при включенных нужно переносить остатки с каждой группы отдельно. Мы уже, кстати это поняли.
Если пользователи будут, вносить весь остаток, который висит на разные заказы полностью через поступивший на склад приходно-расходный документ,то остаток будет падать на учетную группу, указанную в нем . А потом, они будут, как и мы офигевать от того, что таким образом, перенесли огромное количество остатков, и чесать репу, как теперь это исправить))). Кстати, как нам теперь это исправить? Куда упали эти перенесенные нами через прих.-расх. документы остатки? В какой документ нам нужно войти, чтобы испарвить полностью перенесенный остаток на то количество, которое числится на каждой группе учета?
 
Цитата
Нина Аленцова пишет:
А при включенных нужно переносить остатки с каждой группы отдельно
По-моему, это вполне очевидно.

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

Логично, что нужно в таком случае по каждой группе отдельно остаток вводить.

P.S. В документации допишем. Но только не в этом руководстве. Есть отдельное руковоство по использованию учётных групп. Вот туда и допишем. Когда до него очередь обновления дойдёт.
 
Цитата
Нина Аленцова пишет:
В какой документ нам нужно войти, чтобы испарвить полностью перенесенный остаток
Открываете "Обороты". Примерно за тот период, когда вы это вводили.
Выбираете (группировка или фильтр) нужную учётную группу (куда вы по ошибке больше, чем нужно оприходовали).
Выбираете интересующую номенклатуру. Два раза щёлкаете по ней (рис.1).
Открывается окно с подробной информацией по движению этой позиции.
Смотрите там приход по документу "ввод остатков". Два раза щёлкаете на нём.
Открывается справочник с документами. Курсор на нужном документе стоит (рис.2).
1.png (47.39 КБ)
2.png (125.67 КБ)
 
"Если вы хотите вести учёт (приход, расход, остаток) не общий на складе, а по разным группам, по каждой отдельно, то вводя общее полное количество при приходе, вы думаете, оно как-то волшебным образом "само" разделится на несколько разных частей что ли?"
1. Мы ничего не думали, мы делали, как написано в руководстве. И после нас кто-то может сделать так же, а потом сидеть и менять количество;
2. Занос остатка через прих.-расх. документы совсем не означает, что внесенный остаток по этой позиции должен упасть на номер заказа, указанного в  документе. Где это написано?
Страницы: Пред. 1 2 3 4 5 6 След.
Сейчас на форуме (гостей: 22)
Всего зарегистрированных пользователей: 3139
Приняло участие в обсуждении: 361
Всего тем: 804
Всего сообщений: 6067

Полезные ссылки:
Себестоимость Видео-презентация подготовка производства Демонстрационный режим VOGBIT Обновление VOGBIT технологическая подготовка График производства производственный учет складской учет Создание новой базы данных VOGBIT управление данными Полная версия VOGBIT Планирование мелкосерийного производства Техническая Подготовка Производства электронный архив управление качеством деактивации VOGBIT активация VOGBIT управление производством Производственный заказ Установка VOGBIT управление ремонтами Трудоёмкость базы данных VOGBIT Деактивация VOGBIT планирование производства Начало работы инструкция Расчёт комплектации Складской учёт загрузка оборудования расчет себестоимости ТПП Сменное задание Задания для производства Тип нормирования производство металлоконструкций Нормирование Заказ на производство пост руководство администраторов VOGBIT Планирование производства разработчика отчетов vogbit состав изделия демоверсия технология Состав изделия Обзор обновления Генератор отчетов склад Метод по отдельным деталям улучшения выполнение операции заказ Поизводственное задание подключение нового шаблона отчёта
×
Вход на сайт