Изменения в лицензионном соглашении - Согласно условиям действующего Лицензионного соглашения уведомляем Вас об изменениях в Лицензионном соглашении, которые вступят в силу, начиная с версии VOGBIT 20.8 (1.1.54861). Согласно условиям действующего Лицензионного соглашения, обновление пользователем своей программы до версии VOGBIT 20.8 (1.1.54861) будет означать его полное согласие с условиями новой редакции Лицензионного соглашения

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

Ошибка при замене материала - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: 19032 Илья написал: автоматически бывает оприходование? Да нет, вроде. Если говорить про ЛЗК/Требование. Не "оприходуется" там расч ...
Ошибка в формировании потребности материалов - Ошибки в работе
Mariska17-17: Спасибо, получилось!
Сменное задание - Производство
Константин Чилингаров: Здравствуйте, У Вас на картинке, задания созданы на "максимальном" уровне. Применение "максимального" уровня в данном случае ...
Ошибка при планировании производства - Демо версия
Iglin1503: Спасибо. все заработало
Удаление категории номенклатура - Прочее
Константин Чилингаров: Здравствуйте, "Удалить из папки" (см. рис.)
Ошибка на экране после получения задания - Терминалы
Константин Чилингаров: Ок. Спасибо. Посмотрим. 
Поменять технологию - Производство
Илья: 13 Константин Чилингаров написал: И придется как-то сжиться с тем, что она есть. По другому не получится. Понятно, будем тогда сначала п ...
Изменение временных интервалов на терминале. - Терминалы
Константин Чилингаров: Здравствуйте, Пока не настраивается. Со временем нужно будет делать какие-то настройки, да. Уже накапливаются потихоньку всякие пожел ...
Вопрос на тему "Технология подробно" - Состав и технология
Константин Чилингаров: Здравствуйте,   Можно теоретически заморочиться с «объединёнными» заданиями. Недавно на форуме где-то обсуждалось про них (объедине ...
Упрощенная сдача на склад - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Время, которое затрачивается на обновление, зависит от размера базы данных, сервера, компьютера, с которого выполняется, и соединения ме ...
Совместная обработка - Производство
Константин Чилингаров: Со сборкой - сваркой - окраской, то всё понятно. В плане технологии - тут всё просто. Есть Балка. Есть техпроцесс на неё. Три операции: с ...
Плагин на форму отчета - Новые возможности
Константин Чилингаров: Здравствуйте, Пока нет, к сожалению.
Календарный план - Производство
Константин Чилингаров: Не очень понятно, что вы имеете в виду под словами "сделать планирование по номенклатуре в соответствии с уровнями". Вообще, как я ...
Учет комплектующих изготовленных по фактическому количеству материала. - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Не совсем… 19032 Илья написал: для контроля "задела" необходимо создать свою заказную спецификацию Нет. Никакую специальную «за ...
Нажатие Enter в поле поиска при поступлении по заявке. - Ошибки в работе
Константин Чилингаров: Ок. Принимается. По мере возможности посмотрим, что там можно сделать.
Удаление позиции из номенклатуры - Прочее
Константин Чилингаров: Если она нигде не используется (в заказах, спецификациях, документах и т.п.), то есть утилита "Генератор удаление" (в меню "Настройк ...
Копирование спецификаций с комментариями - Интерфейс программы
Константин Чилингаров: Здравствуйте, Записал в список пожеланий.
Экспорт в Vogbit - Состав и технология
Константин Чилингаров: Здравствуйте, Понятно. Проблема из-за того возникла, что папку с файлами сложили прямо в C:\Program Files\VOGBIT. Откуда файлы добавляли. Програм ...
Пустой бланк - Демо версия
Константин Чилингаров: Бывает такой эффект, говорят, когда по какой-то причине завис в Windows в процессах Excel. Если так, то соответственно, перезагрузка помогает.
Не могу создать технологию подробно - Состав и технология
Minicnc14: Отбой, настройки поправил и заработало

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

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

×
Вход на сайт