Изменение цен на лицензии - С 01 мая 2024 г. изменятся цены на лицензии ПО VOGBIT

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

Нормы расхода на окраску - Состав и технология
Lyovushkin: Спасибо буду пробовать
Ошибка печати отчета - Отчёты
Константин Чилингаров: Здравствуйте, В версии VOGBIT 23.1.8 (последнее обновление на сегодня, которое недавно вышло) заменены шаблоны отчётов "приходный ордер" ...
VOGBIT Онлайн - Общие вопросы
Константин Чилингаров: Здравствуйте, Клиентское приложение VOGBIT в данном случае ставится не на ваш конечный компьютер, а на сервер. А вы работаете с ним через и ...
Планирование производства - Демо версия
Константин Чилингаров: API есть. Описания базы данных нет (и вряд ли будем делать в ближайшее время). Есть /forum/forum35/ раздел на форуме . Там примеры использования AP ...
Как отслеживать все детали, входящие в заказ? - Прочее
Константин Чилингаров: Чуть добавлю: Ответ кратко: Да, можно будет продолжать работать с тем, что ввели в "демо-версии". Дополнение к предыдущему сообщен ...
Ошибка при открытии спецификации - Прочее
Константин Чилингаров: Здравствуйте! Версия программы старовата. Хорошо бы обновить. Когда-то, давным-давно, кажется, была такая ошибка, но её быстро починил ...
Учет материалов - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Вкладка меню "Складской учёт" -> Алгоритм списания -> FIFO.
Обороты по складу - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Это какими-то настройками или ещё как-то самостоятельно не решается, к сожалению. Нужно форму экранную саму поменять нем ...
Удаление позиции из номенклатуры - Прочее
mansur: Доброе утро, спасибо, все сделал по второму варианту. 
Ошибка при входе в Vogbit - Прочее
Григорий Клеков: написал: Здравствуйте. ...
Установка Демо версии - Демо версия
Amg: Спасибо большое за ответ. Демо-версию установил на ноутбук, если руководство решит перейти на ваш продукт, то думаю видеоконференция буд ...
Хранение файлов в БД - Общие вопросы
Константин Чилингаров: Если при этом вы хотите потом использовать штатные возможности VOGBIT (например, просматривать эти прикрепленные к операциям файлы в окне ...
Предварительные заявки, ЛЗК, Требования - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте! Периодически возникают похожие вопросы по "Предварительным заявкам", "ЛЗК", "Требованиям". В чём разница, ...
Конструктор фильтра - Прочее
Kochurova.av: Спасибо Вам большое!  Всё как всегда оказалось проще простого)
Свои поля для справочников и вывод их в список. - Общие вопросы
Константин Чилингаров: Здравствуйте, В "Номенклатуре" стандартно есть свойство "Комментарий" и соответствующая колонка в современных версиях VOGBIT ( ...
Список работников поста - Общие вопросы
Константин Чилингаров: Пожалуйста! Пользуйтесь)) Нет. Ссылку не нужно выкладывать. Потом, когда общее обновление соберем, выложим его на сайт, и все смогут ска ...
Вопрос по импорту - Экспорт импорт данных
mansur: Нашел, залил и все работает теперь, спаибо.
Ошибка при запуске приложения - Прочее
Сергей: написал: Если на другое железо переставить Вогбит, как лицензию нам перекинуть? на mailto:info@vogbit.ru info@vogbit.ru  напишите со ссылкой на эту тем ...
Пример создания плагина - Плагины
Сергей: Здравствуйте! Перетащите мышкой из "команд" (рис.3) в нужное место на панели инструментов
Помощник мастера - Установка
Trudovaya-21: Спасибо Вам ОГРОМНОЕ за работу и понимание!!!

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

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

×
Вход на сайт