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

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

Создание отчета. - Отчёты
Сергей: Если верить доке, то:  Формат строки вызова запроса: «UserQuery» + пробел + Наименование запроса + пробел + Служебная информация В служебной и ...
Формирование отчета по возврату материалов на склад - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Нужно для этого  сделать такой отчёт (настроить шаблон отчёта, услуга платная). Если интересно, то пришлите, пожалуйста, ...
Возможность разграничения записей. - Общие вопросы
Константин Чилингаров: Выходите на связь (телефон, почта, telegram, whatsapp, skype), сделаем, чтобы были  :) 
Последовательность операций в справочнике Номенклатура - Состав и технология
Константин Чилингаров: написал: Как в справочнике Номенклатура На картинке в сообщении #2 - это не в "Номенклатуре", а в техпроцессе операции связаны. Так ...
Импорт данных - Экспорт импорт данных
Константин Чилингаров: Пришлите, пожалуйста, такой файл нам на почту (на общий адрес). Посмотрим на него для начала...
Отсутствие кнопки "Учётный документ" - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Думаю, нужно тем, у кого нет, таки добавить через "Присоединённые формы". Форму выбирать, которая показана на рис.1. ...
Разграничение доступа в справочниках учётных документов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Может. Например, посмотреть "обороты" (движение) по своему складу, там по интересующей позиции движение её, какие были приходы, рас ...
Не загружается график производства - Обновление
Balukov: Здравствуйте!  Для закрытия  необходимо зайти во вкладку "Производство- Производственные заказы: текущие " выделить те заказы, ко ...
Приемка ОТК - Производство
Константин Чилингаров: Ролик по функции "Контроль": [VIDEO TYPE=YOUTUBE WIDTH=1280 HEIGHT=720 //www.youtube.com/embed/RT7mVtAL-F0?feature=oembed[/VIDEO
Автоматизация обновления - Обновление
Константин Чилингаров: Ещё, может быть, можно было бы написать какую-то специальную одноразовую приладу, конкретно для вашего случая, чтобы массово всё деактив ...
Проблема с обновлением шаблона - Установка
Константин Чилингаров: Здравствуйте, На ночь оставьте загружаться этот шаблон. Он такой один специфический... Конкретно этот шаблон может ну ООООчень долго з ...
Настройка вкладки "Подразделение" - Прочее
Pakhunov: Спасибо
Оформление полуфабриката - Состав и технология
Pakhunov: Спасибо  :) 
Завершение клиента - Прочее
Константин Чилингаров: Здравствуйте, Починить что-либо, не обновляя программу, если дело в самой этой программе, невозможно. Если только дело не в VOGBIT, а в чем- ...
Отчеты Статистика производства - Отчёты
Константин Чилингаров: Здравствуйте, написал: а если работа выполняется быстрее чем указано в плане? "Полоска" в "Графике производства" показыва ...
Логи - Прочее
Константин Чилингаров: Здравствуйте, Клиент локально сохраняет только настройки (расположение колонок, размеры, расцветка пользовательская в окнах и т.п.) и в ...
Обслуживание БД - Прочее
Владимир Белов: Павел, время доброе! На Linux можно так установить количество файлов логов  с помощью консоли: 1. Изменить в настройках количество errorlog- ...
Активация - Установка
Константин Чилингаров: Здравствуйте, Владимир! Странная ошибка, вообще говоря. Такая появляется при попытке запустить версию новее 1.1.32 (а это год 2015 где-то п ...
Технологическая карта заказа - Общие вопросы
Beavis900: Понял, благодарю! 
Заявки на закупку - Прочее
Константин Чилингаров: Здравствуйте, написал: Оформляя приход, накладная поставщика была добавлена не к той заявке Технически можно, конечно, залезть в сп ...

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

- Практические приемы работы - Старые разделы форума
Страницы: 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
Сейчас на форуме (гостей: 12)
Всего зарегистрированных пользователей: 3642
Приняло участие в обсуждении: 393
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт