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

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

О номенклатуре и технологии - Состав и технология
Vdovin-g: Здравствуйте! Спасибо, Вы подтвердили мои мысли
Пустой бланк - Демо версия
Константин Чилингаров: Да, судя по картинке, какая-то проблема с самим Excel'ем. VOGBIT создаёт при формировании отчёта Excel файл в папке "Документы", а Excel (ну и ...
Экспорт в Vogbit - Состав и технология
Константин Чилингаров: Здравствуйте, Если речь про стандартный модуль импорта из Excel, то нет. Не зависит. Можно использовать на нескольких рабочих местах. Нет ...
Расчёт потребности - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, В контексте данной задачи не нужно "заказных спецификаций" на входящие компоненты. "Заказная спецификация" ну ...
Задать место хранения - Материалы, Комплектующие, Складской учёт
Петр Свиридов: Нашли. Очень хорошо, что ее приделали. Полезная вещь. Благодарим!
Приход по заявке - изменение единиц измерения - Интерфейс программы
Константин Чилингаров: Здравствуйте, Спасибо за замечание, Да, знаем, что там не очень в этом месте, когда разные единицы измерения параллельно используются.  ...
Плагин на форму отчета - Новые возможности
Константин Чилингаров: Отправили ещё раз. Если нет, посмотрите в "Спаме". Туда значит попадает, наверное.
Смена участка и поста в окне Технология подробно. - Интерфейс программы
Константин Чилингаров: Здравствуйте, Пожелание понятно. Пока запишем в список пожеланий.
Вопрос по коэффициентам пересчета - Состав и технология
Sgrekhv: Большое спасибо. Все получилось.
Группировка постов по подразделениям в загрузке - Общие вопросы
Константин Чилингаров: 19314 nemyheim написал: Поколдую пока с названиями Да, пока так. В список пожеланий записал.
Эскизы при просмотре остатков - Интерфейс программы
Константин Чилингаров: Ну... Надеюсь, скоро))) Тестируем. Вам конкретно, если сильно нужно, можем и сейчас дать.
Карта раскроя - Общие вопросы
mansur: Добрый день, я понял свое упущение - нужно позиции переводить на "высокий"уровень, у нас по умолчанию стоит "максимальный". В пр ...
Приемка ОТК - Производство
Константин Чилингаров: Ответ, на самом деле, в предыдущем сообщении: 13 Константин Чилингаров написал: Чтобы была возможность применять такую систему не повс ...
Редактирование минимальных остатков в окне. - Интерфейс программы
Константин Чилингаров: Здравствуйте, 3520 Alex-220781 написал: Чтобы отредактировать значение минимального остатка Я, когда хочу отредактировать "неснижаемый ...
Комментарии в "Технология подробно" - Состав и технология
Kip.prombez: Спасибо :) Помогли
Колонка комментарий в заявке на покупку. - Интерфейс программы
Константин Чилингаров: Технически в следующей версии такая возможность предусмотрена. Успеем или нет её подключить в графический интерфейс (колонка чтобы поя ...
Вопрос по расчетам - Общие вопросы
Константин Чилингаров: В заказной спецификации (дереве) указывается количество на единицу того, что делаем. Если меряется это, что делаем, метрами, то на 1 м "и ...
Учет комплектующих изготовленных по фактическому количеству материала. - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: 19032 Илья написал: изначально втулки делают именно под конкретный  заказ Тут у нас с вами некоторое терминологическое расхождение. П ...
Внеплановое задание - Производство
Константин Чилингаров: Я так понимаю, «подгонка толкателей» в данном случае это не заранее предусмотренная технологией операция, а некая дополнительная работ ...
Удаление позиции из номенклатуры - Прочее
Константин Чилингаров: Судя по сообщению, данная позиция используется в складском документе (в спецификации учётного документа). Немного странно, что "где и ...

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

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

×
Вход на сайт