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

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

Колонки Операция и Состояние - Производство
Константин Чилингаров: 19032 Илья написал: А как быстро и без лишних заморочек проставить готовность деталей без отчетности по операциям? Куда нажать? Использовать "минимальный" уровень (= "по простому, без операций"). Количество сданных деталей с ...
Применяемость материалов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Если подвести курсор к любой (практически) ячейке в окне "обеспеченность", то там появляется кнопка "Подробно" (лупа справа в ячейке). "Подробно" в колонке "Затребовано" показывает на какие заказы нужен данный ...
Пустой бланк - Демо версия
Илья: 13 Константин Чилингаров написал: Самый универсальный и верный вариант - прописать его (крепёж этот) в комплектацию в техпроцессе. Есть другие варианты, но этот базовый в плане того, что он работать будет всегда правильно. Другие варианты - с ого ...
автоматическое закрытие лимитных карт - Материалы, Комплектующие, Складской учёт
Alex-220781: Присоединяюсь к пожеланию - иногда нужно некоторые ЛЗК или заявки "выключить", чтобы они не считались в потребности.
Вопрос по расчету комплектации - Общие вопросы
Константин Чилингаров: 18996 Serge.v.astapov написал: Если бы был такой ролик, который от нуля до продажи клиенту покажет весь пусть за 15 минут Дело в том, что таких путей далеко не один. И далеко не все их впихнёшь в 15 минут. Вот у вас сборочное производство. Мн ...
Замена поставщика в приходной накладной. - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Мы подумаем на эту тему.
Оформление прихода по заявке. - Материалы, Комплектующие, Складской учёт
Alex-220781: Добрый день! Очень часто у меня бывает такая ситуация: 1) Выбираем заявку на покупку. 2) Вводим накладную, номер, поставщика. 3) И не отметив количество поступлений там где надо, нажимаем кнопку ОК. 4) Программа спрашивает: "Не указано колич ...
Новые возможности. Объединённые задания. Как пользоваться? - Производство
Alex-220781: Я имею ввиду задания, которые раньше были сами по себе, а потом вошли в группы, вот они остаются в общем списке.
Как подключить отчеты? - Общие вопросы
Serge.v.astapov: Еще раз спасибо! Почему-то для меня это не очевидно
Не входит наименование материалов в соответствующие колонки - Производство
Константин Чилингаров: Поменяйте шрифт или размер колонки в шаблоне отчёта. Рекомендую оригинальный вариант тоже сохранить на всякий случай. 1. Откройте "Администрирование - шаблоны отчётов", выберите нужный бланк, дважды щелкните на нём -> "Сохранить ...
График производства, календарный план - Ошибки в работе
Константин Чилингаров: Нет никакого подвоха. Это иллюстрация к обсуждению выше. Было пожелание, чтобы в "графике производства" (просто "график производства", не "подробно") сделать клетку со значением "где сейчас находится". Я прос ...
Прикрепление файлов к узлам, деталям, спецификациям. - Обновление
Константин Чилингаров: Здравствуйте, В текущей версии нет такой возможности. Возможно, в будущем добавим. Но не в ближайшем. P.S. тут есть и обратная сторона палки. Если будет не файл в базе, а только ссылка на него, то любое его перемещение или изменение имени на се ...
Удаление заказа - Общие вопросы
Константин Чилингаров: Сам "заказ", как запись в "Номенклатуре" остался. Подробнее, как там что устроено, можно почитать /forum/messages/forum32/topic1415/message9005/1415#message9005 вот тут . Как удалить: Откройте "Номенклатуру". Включ ...
Печать графика производства - Производство
Илья: 13 Константин Чилингаров написал: В вашей операционной системе нет компонента vcredist_VS2010_x86. Он нужен. Чтобы не искать - https://cloud.mail.ru/public/2Gen/9uTxGwcWj вот ссылка . Скачайте файл, запустите, он установится. После этого зар ...
Миграция БД - Отчёты
Константин Чилингаров: По ошибке: /forum/messages/forum26/topic2564/message15862/2564-pustoy-blank#message15862 Решение . Не нужно нажимать в этом окне (выбор шаблона отчёта, который хотите использовать) "принтер". Нужно выбрать шаблон требуемый и нажать " ...
Обновление 20.5. Задачи и файлы - Обновление
Константин Чилингаров: Вкратце про «Задачи и файлы»: Изначально данная функциональность разрабатывалась для производства «проектного» типа (с прицелом, может, ещё зачем-нибудь пригодится). То есть выпускающего нечто уникальное, в единственном экземпляре, на заказ. Когд ...
Перемещение - Прочее
Константин Чилингаров: Здравствуйте, Тут всё зависит от сути данного процесса в реальной жизни. Вариант 1. Сделали какое-то количество корпусов. Каждый, по идее должен быть со своим серийным номером. Но шильдиков не было. Пока сдали так на склад. Появились шильдики, ...
Ошибка автозаполения накладной из производства - Ошибки в работе
Константин Чилингаров: Да. Похоже, ошибка. На "максимальном" уровне получилось воспроизвести. На "высоком" всё нормально сработало. Будем разбираться.  WorkAround (пока разбираемся и чиним): 1. если сильно нужно именно так, то можно руками в этом от ...
Расчет комплектации - Производство
Константин Чилингаров: 19032 Илья написал: Единственное что в в "Проработке" остались "стандартные изделия". Причем я так понимаю они остались еще с изначального расчета комплекции. С ними что делать? Удалить. 13 Константин Чилингаров написал: ...
Удаление позиции из номенклатуры - Прочее
Илья: Спасибо за терпение. Теперь получилось

Ошибки в оборотах

- Практические приемы работы - Старые разделы форума
Страницы: 1
Ошибки в оборотах
 
Ввожу расход за прошлый год. Нацчился делать это правильно но вылезла ошибка в оборотах на материалах у которых нет расходов. Пересчет учетных карточек запускал, не помогает.
Такой эффект происходит если расход сделать раньше прихода в учетной карточке но в данном случае ошибки в позициях где только одни поступления.
Изменено: shurick - 24.01.2014 19:20:43
 
Еще такая ошибка возникает если сделать период с 01.01.13 по сегодня а если конец передвинуть на конец прошлого года то минусы пропадают. Я когда заносил расходы периодически делал проверку оборотами но период ставил тот которым на тот момент заканчивались расходы а потом случайно не сдвинул конец и получил такое... Что делать? Боюсь вводить дальше чтобы не переделывать ВСЕ потом.
Изменено: shurick - 24.01.2014 19:28:31
 
А вот тут материал которого на начало года не существовало вообще. Два поступления сделаны еще тогда, не задним числом, без переноса документа.
 
Цитата
shurick пишет:
Научился делать это правильно
Значит всё таки не научились...

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

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

Внесение каких-то изменений и корректировок задним числом доступно только администратору. Вручную. Для исправления ошибок, если таковые вдруг случаться.

Если вы проводите складские операции задним числом, то вы тем самым уже пытаетесь "обмануть" программу. "Подтасовать" данные таким образом, как будто когда-то произошло некоторое событие (открылись карточки, произошла складская операция прихода или списания и т.п.), которого на самом деле не было.  
Технически, не буду отрицать, это в принципе возможно. Непросто, но возможно.
Но при этом:

1. надо делать всё вручную (создавать документы, карточки и т.д.). Т.к. если вы будете пытаться параллельно использовать штатные модули Приход и Расход, которые «заточены» под работу в реальном времени и алгоритмы FIFO и LIFO, то как они могут и не понять такую «подтасованную» информацию. Которая не согласуется с реальным временем и последовательностью действий.

2. надо делать всё очень методично и аккуратно, в точности воспроизводя вручную алгоритм работы программы. Создавать карточки при приходе, выбирать нужные карточки при расходе, не забывать менять при этом дату везде текущую на «подложную». Не нарушать порядок.

Если вы будете делать не так, или где-то что-то упустите случайно, то потом вся такая «подтасованная» конструкция запросто может и развалиться.

Теперь к сути вопроса.

1. Учитывая вышесказанное, 99% вероятности, что дело не в ошибке в программе. Программа в данном случае с вероятностью близкой к 100% работает правильно. Проблемы в том, что ручная «подтасовка» данных, судя по всему, не совсем удалась. Вероятнее всего, где-то на каком-то этапе был нарушен один из вышеуказанных принципов. Или несколько сразу.

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

Цитата
shurick пишет:
Пересчет учетных карточек запускал
А это что значит?
Если вы самостоятельно на этой базе данных запускали какие-либо скрипты на уровне SQL сервера, то это очень плохо. Этого делать категорически не рекомендуется.

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

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

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

Как это выглядит в приложении к складскому учёту:

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

При правильной организации делать так совсем не сложно. Главная проблема внедрения заключается в том, что склад находится «в середине» бизнес процесса. К нему просто нужно подходить только в определённый момент. А не сразу (как бы не хотелось). Очень трудно и неудобно будет, например, пытаться организовать на складе учёт в программе, если производство в этой программе полноценно не работает. И наоборот – легко, если производство, которое обслуживается складом, само полноценно в VOGBIT уже работает.

Какой эффект будет если именно так выстроить работу:
Во-первых, появляется порядок. Ничего никуда не денется. Всякое движение упорядочено и учтено, а не хаотично. Во-вторых, через неделю, месяц, два у руководителя автоматически появляется полная и актуальная картина. Реальные остатки, обороты, скорость движения тех или иных позиций, «неликвиды», информация, что куда пошло и т.д. Причём, что называется, «само». То есть, если именно оперативный учёт на складе чётко организован, то дальше для получения подобных отчётов и информации уже ничего делать не надо.  Никакой головной боли. Своды за месяц/квартал/год - всё получается само собой, автоматически.

Теперь вернёмся к вопросу о «задним числом». Что это означает? С моей точки зрения то, что оперативный учёт на складе на самом деле то не организован. Не поступает оттуда ежедневно достоверная информация, что пришло и что ушло. Нет этого (иначе, откуда операции «за прошлый год»? ). То есть фундаментально в производственной системе изменений не произошло. Как всё было в этом её месте, так по сути и осталось.

То, что мы пытаемся задним числом вводить в VOGBIT, какие-то приходы и расходы на складе – это НЕ значит, что мы получаем учёт. Это, скорее, как «подгонка»  решения задачи под известный ответ, вместо настоящего «решения» этой задачи. Причём в отличие от "подгонки" в школьной задаче, в данном случае мы ещё и не знаем заранее, правильный ли тот ответ, под который мы подгоняем :) В итоге мы получаем не реальную картину как работает система, а всего лишь модель, которую сами же и построили. Получается не учёт, а модель учёта...

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

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

Запросы которые я запускал вручную я не сам придумал а Вы мне прислали:
Upd ate Stock.RegCards
Se t Stock = 0, StockSum = 0
exec Stock.RecalcAccDocs
 
Ну в общем разобравшись на свежую голову во всех случаях выявились косяки ручного ковыряния. Где-то расход раньше прихода в учетной карточке, где-то места хранения перепутаны...

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

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

Из соображения что человек главный над техникой а не наоборот все таки хочется найти причину.
Подскажите пожалуйста что-нибудь. Ну хоть намекните.
Даже если предположить что случился какой-то сбой в первом ордере как он может повторятся в том который я сделал заново?
 
Надо смотреть внимательно все учётные карточки для этой номенклатуры и всё движение по ним. По каждой.
На остатки и обороты влияет только это.
 
Снес все лишнее. Теперь только ОДНА учетная карточка, ОДНО поступление в ней и все это сделано ЗАНОВО! И вот проведение единственного документа вместе с правильной операцией делает еще остаток 2500 кг по 29 рублей на начало года. В единственной карточке единственная операция. Пересмотрел все связи и зависимости. Ничего подозрительного не нашел.
Остается только номенклатурную позицию заново сделать?
 
Ну новую номенклатуру то точно должно помочь.
По этой можно посмотреть ещё обороты по учётной карточке. Мало ли. Нет ли там какого-нибудь ненулевого начального остатка например?

По идее ничего такого быть не должно. При штатной работе. Но эта база, я так понимаю, многое пережила, включая запуск скриптов, минуя VOGBIT, напрямую в SQL...

Если и в оборотах по карточке всё чисто и красиво, то тогда по скриншотам ничего уже не скажешь. Только смотреть внутрь самой базы, и разбираться что там к чему, и почему такой результат получается.
 
Нашел причину!!! Два подряд поступления с одинаковой ценой делал на разные учетные карточки. Причем если потом вторую удалить и в приходном ордере заменить ее на первую то ошибка остается и приходится удалять материал из справочника.
Страницы: 1
Сейчас на форуме (гостей: 29)
Всего зарегистрированных пользователей: 3111
Приняло участие в обсуждении: 356
Всего тем: 804
Всего сообщений: 6067

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