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

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

Приход по заявке - изменение единиц измерения - Интерфейс программы
Константин Чилингаров: Здравствуйте, Спасибо за замечание, Да, знаем, что там не очень в этом месте, когда разные единицы измерения параллельно используются.  ...
Расчёт потребности - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Тут зависит от задачи. Если нужно, например, посчитать нормативные затраты (себестоимость) на "изделие А" (или N шт "изделий А") ...
Экспорт в Vogbit - Состав и технология
Константин Чилингаров: Здравствуйте, В приложенном архиве описание и примеры файлов для импорта.
Плагин на форму отчета - Новые возможности
Константин Чилингаров: Отправили ещё раз. Если нет, посмотрите в "Спаме". Туда значит попадает, наверное.
Смена участка и поста в окне Технология подробно. - Интерфейс программы
Константин Чилингаров: Здравствуйте, Пожелание понятно. Пока запишем в список пожеланий.
Вопрос по коэффициентам пересчета - Состав и технология
Sgrekhv: Большое спасибо. Все получилось.
Группировка постов по подразделениям в загрузке - Общие вопросы
Константин Чилингаров: 19314 nemyheim написал: Поколдую пока с названиями Да, пока так. В список пожеланий записал.
Эскизы при просмотре остатков - Интерфейс программы
Константин Чилингаров: Ну... Надеюсь, скоро))) Тестируем. Вам конкретно, если сильно нужно, можем и сейчас дать.
Карта раскроя - Общие вопросы
mansur: Добрый день, я понял свое упущение - нужно позиции переводить на "высокий"уровень, у нас по умолчанию стоит "максимальный". В пр ...
Приемка ОТК - Производство
Константин Чилингаров: Ответ, на самом деле, в предыдущем сообщении: 13 Константин Чилингаров написал: Чтобы была возможность применять такую систему не повс ...
Редактирование минимальных остатков в окне. - Интерфейс программы
Константин Чилингаров: Здравствуйте, 3520 Alex-220781 написал: Чтобы отредактировать значение минимального остатка Я, когда хочу отредактировать "неснижаемый ...
Комментарии в "Технология подробно" - Состав и технология
Kip.prombez: Спасибо :) Помогли
Колонка комментарий в заявке на покупку. - Интерфейс программы
Константин Чилингаров: Технически в следующей версии такая возможность предусмотрена. Успеем или нет её подключить в графический интерфейс (колонка чтобы поя ...
Вопрос по расчетам - Общие вопросы
Константин Чилингаров: В заказной спецификации (дереве) указывается количество на единицу того, что делаем. Если меряется это, что делаем, метрами, то на 1 м "и ...
Учет комплектующих изготовленных по фактическому количеству материала. - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: 19032 Илья написал: изначально втулки делают именно под конкретный  заказ Тут у нас с вами некоторое терминологическое расхождение. П ...
Внеплановое задание - Производство
Константин Чилингаров: Я так понимаю, «подгонка толкателей» в данном случае это не заранее предусмотренная технологией операция, а некая дополнительная работ ...
Удаление позиции из номенклатуры - Прочее
Константин Чилингаров: Судя по сообщению, данная позиция используется в складском документе (в спецификации учётного документа). Немного странно, что "где и ...
добавление и удаление деталей в заказ - Состав и технология
Константин Чилингаров: Можем. Напишу на почту. До конца этой недели.
Обороты по складу - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: 19136 Promob321 написал: как и где правильно выбрать подразделение, чтобы можно было посмотреть Обороты по складу В меню (ленте) выбрать "Р ...
Артикулы как правильно привязать к деталям? - Состав и технология
Константин Чилингаров: Про параметры: [VIDEO TYPE=YOUTUBE WIDTH=1280 HEIGHT=720 //www.youtube.com/embed/ve2rwhx6JM4?feature=oembed[/VIDEO

сумма в учетной карточке

- Практические приемы работы - Старые разделы форума
Страницы: 1
сумма в учетной карточке
 
В учетной карточке при нулевом количестве в остатке сумма получилась не нулевая да еще и отрицательная. Что-то с округлением?
 
Количество не нулевое.
Остаток на карточке = -0.004 (просто на экране в этом месте, судя по всему, только 2 знака показывается).

Проверяем по движению на вашем скриншоте:

31.03.14 после всех операций остаток на карточке был 259,566
01.04.14 был (вручную) сделан расход в количестве: 259,57

Итого остаток = -0,004

-0,004 * 30,59 = -0,12236

Всё сходится :)
 
а вот еще интересней, движений нет а остаток с суммой есть.
 
Фильтр не стоит? (может, просто не показывается из-за этого?)
 
Фильтра нет.
Спасся заменой вручную учетных карточек а эти больные удалил. Но может быть есть какое-то объяснение и решение?
Изменено: shurick - 27.11.2014 21:33:33
 
Дело тёмное...

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

При использовании только штатных функций программы остатков без движения никак получиться, по идее, не должно.
 
Да, похоже на это.
Изменено: shurick - 28.11.2014 18:34:12
 
Вы запросы запускаете для пересчёта?
Тогда 100% из-за этого.
Что-то не сбросили, не обнулили и т.п.

Подобные процедуры - это не инструмент для пользователя.

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

Указанная выше ошибка из-за того, что для пересчёта все карточки должны быть открыты. А они не открыты.

Совет: восстановите базу с резервной копии до того, как начали запускать эти процедуры.
 
К сожалению, восстановить из копии возможности нет так как сломалось давно и за это время добавилось много данных. Нельзя ли каким-нибудь запросом это вылечить? Пока что приходится вручную делать дубликат учетной карточки и подключать ее в учетные документы.
 
Кстати, в учетной карточке может быть несколько приходов если они по одной цене? Похоже что мы заносили данные инвентаризации не через складской учет а вручную и создавали учетные карточки с ценой как в предыдущей. В таких позициях и появляется ошибка. Если переключить в приходном ордере учетную карточку на уже существующую то результат считается правильно.
Получается в движениях по карточке:
+ 123
- 23
- 45
+100

Это не нарушает логику расчетов остатков?
 
Цитата
shurick пишет:
Нельзя ли каким-нибудь запросом это вылечить?
Вряд ли.

Чудес не бывает.
Если база была "сломана" путём ручного вмешательства, то невозможно как-нибудь чудесным образом её автоматически раз, и починить. Только восстановить с резервной копии, до того, как её сломали.
В противном случае - разбирательство с такой базой - это рутинная ручная работа без гарантии успешного исхода.

Лучший вариант с точки зрения корректности работы ПО в такой ситуации, конечно, создать новую базу, работать с ней и не ломать её.

Если продолжать работать с этой, то:
- найденные косяки править вручную;
- никогда больше не запускать самостоятельно в базе никакие процедуры за исключением [health].[UpdateStatistics] и [health].[RefreshDependencies].
 
Цитата
shurick пишет:
в учетной карточке может быть несколько приходов если они по одной цене?
Стандартный модуль "Складской учёт - Приход" так не делает. Он всегда создаёт на новый приход, новую учётную карточку.

Вручную, через "Учётные документы" - можно.
Просто сделать руками приход несколько раз на одну и ту же карточку.

Дальше, если честно, я не понял.

Цитата
shurick пишет:
Это не нарушает логику расчетов остатков?
Если, как говорит один из моих коллег, "разобрать на атомы", то "Логика расчёта остатков" предельна проста. Приход = остаток на карточке увеличивается. На величину указанную в документе. На какой карточке - тоже указано в документе. Расход = обратная операция, т.е. остаток на указанной в документе карточке уменьшается на указанную величину. Вот и всё. Общий остаток номенклатуры = сумма остатков по открытым учётным карточкам.

А вся работа программы на уровне бизнес-логики дальше сводится к тому, какую карточку при проведении очередной складской операции ставить в соответствующий учётный документ. Т.е. на какую добавлять кол-во или с какой списывать.

Всё элементарно.
Если только не лезть руками (запросами) внутрь базы. Если полезть, то можно, не зная, случайно натворить там делов.
 
Почти все исправили но локализовалась проблема с которой справиться не могу.
Есть материал Гайка.
У нее одна учетная карточка и одно поступление 1 апреля - 200шт.
Обороты 1.04-30.06 выдают начальный остаток 300 штук почему-то.
Делаю:
Распровожу приходный ордер.
Создаю новую учетную карточку.
Меняю в спецификации ордера у этой Гайки уч. карточку на новую.
Старую удаляю.
Провожу ордер.
Обновляю Обороты. Остаток на 1.04 = 0. Правильно.
Потом запускаю пересчет остатков запросами которые Вы давали. Это для проверки корректности работы так как эту процедуру периодически приходится запускать пока восстанавливаем данные и ковыряемся в учетных карточках.
И после этой процедуры остаток на 1.04 опять становится 300.
Причем остаток в самой уч. карточке правильный, в движениях правильно, но отчет Обороты все равно находит эти непонятные 300шт по непонятной цене.

Без Вашей помощи не справлюсь уже.
Совсем удалить Гайку не могу так как она участвует в ТП изделий.
И таких "гаек" штук 8 всего.
Изменено: shurick - 03.12.2014 12:43:15
 
Цитата
Константин Чилингаров пишет:
- найденные косяки править вручную;
- никогда больше не запускать самостоятельно в базе никакие процедуры за исключением [health].[UpdateStatistics] и [health].[RefreshDependencies].

Цитата
shurick пишет:
Потом запускаю пересчет остатков запросами которые Вы давали
Зачем вы это делаете?
 
При исправлении косяков в учетных карточках вручную результат не всегда получается без запуска пересчета.
Сейчас в этом необходимости нет но я запускаю пересчет чтобы выяснить будет ли он корректно работать. Если это понадобиться еще через месяц и он испортит остатки как сейчас то ситуация еще усугубится.
Я конечно буду стараться не лазить руками в базу но мало ли что.
 
Нашел решение.
Перенес "больные" гайки в новый приходный ордер, пересчитал остатки и в оборотах все стало правильно.
Выходит что проблема была не в учетных карточках а в приходном ордере.
Непонятно только как его мы могли испортить.
Страницы: 1
Сейчас на форуме (гостей: 9)
Всего зарегистрированных пользователей: 3289
Приняло участие в обсуждении: 374
Всего тем: 804
Всего сообщений: 6067

×
Вход на сайт