Прекращение поддержки работы VOGBIT на оборудовании x86 - В 2025 г. мы планируем прекратить поддержку работы VOGBIT в 32-битных (x86) операционных системах

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

Новая документация "График производства" - Прочее
Константин Чилингаров: Движок форума не разрешает напрямую Excel файлы в сообщения вставлять. Ну ладно. Понятно, в общем, о чем речь. на будущее: если нужно Excel фа ...
Ошибка отчёта "Недостаточно памяти" - Отчёты
Константин Чилингаров: Тут ещё знаете, в чем может быть дело... Не в размере даже, а во внутренностях конкретного файла с картинкой. Ошибка может озвучиваться си ...
Дублирование приходных ордеров - Прочее
Константин Чилингаров: Здравствуйте, Очень странная картина... Не сталкивались никогда с таким. Копию базы данных можете дать нам посмотреть? Если есть техни ...
Распределение работ. Дискретность настройки - Прочее
Константин Чилингаров: Здравствуйте, В этом окне, насколько я помню, сохраняется только список "постов" выбранных. При закрытии/открытии окна. Порядок сл ...
«Шаблон техпроцесса» - Состав и технология
Sidneyanton: Спасибо, за подробное разъяснение!
VOGBIT Онлайн - Общие вопросы
Владимир Белов: написал: Добрый день! Такой вопрос. Могу я установить базу данных на съемный диск и пользоваться на разных компьютерах - переставляя то ...
Создание нового производственного задания - Производство
Константин Чилингаров: Здравствуйте, написал: еперь при создании заказа в окне "Производственные заказы" этот самый заказ "дублируется" в окне " ...
Вопрос на тему "Технология подробно" - Состав и технология
Zms.komissarov: Нужно открыть, какой-нибудь (из какого удобно печатать) вариант "подробного" графика производства, там выбрать соответствующую опе ...
Не отображается выпадающий список, а также неактивна кнопка "Импорт" - Ошибки в работе
Сергей: написал: Не отображается выпадающий список при нажатии на стрелочку Напишите на mailto:info@vogbit.ru info@vogbit.ru Попробуем починить
Вывод DXF или моделей в отдельную папку - Терминалы
Константин Чилингаров: Здравствуйте, Обычно, непосредственно с терминала выгружают управляющие программы какие-нибудь, к заданию, которое берется в работу. Н ...
График производства. Выполнение (по выделенным) - Производство
Zms.komissarov: Спасибки.
Комментарий к операции - Состав и технология
Zms.komissarov: Спасибо.
Пример создания плагина - Плагины
Bochik_88: С этим вопросом разобрался, спасибо)
Состав изделия - Состав и технология
Константин Чилингаров: К сожалению, проблема хронического отсутствия времени пока не позволила сделать. Лежит заготовка под второй ролик с лета. Пока отложена ...
График производства. Не отображает ТТП. - Производство
Константин Чилингаров: написал: Честно говоря, "средний" уровень как-то никогда не рассматривали для работы. Всё меняется... 10 лет назад там действитель ...
Множитель - Состав и технология
Константин Чилингаров: написал: Можно, пожалуйста, выложить скрины, как это реализовано Пожалуйста: Рис.1 - Параметры в справочнике. Которые я использовал, ка ...
Ошибка программы после обновления - Общие вопросы
Константин Чилингаров: Здравствуйте! Да, встречали такую ситуацию. Но, к сожалению, пока никак не можем научиться её стабильно повторять. Не можем пока найти к ...
Календарный план - Прочее
Veruz: Благодарю за ответ.
Установка - Установка
Константин Чилингаров: Здравствуйте, На совсем понял, если честно вопрос в Вашей терминологии. Давайте попробуем ещё раз разложить всё по полочкам…   Вы ...
Обновление тестовой базы - Обновление
Glavtech: Спасибо, проблема устранена

склад

Всё, что связано с расчётами и учётом материалов, покупных изделий, комплектующих и др. ТМЦ - Материалы, Комплектующие, Складской учёт - Работа с программой
Страницы: Пред. 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 След.
Сейчас на форуме
Всего зарегистрированных пользователей: 4125
Приняло участие в обсуждении: 426
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт