Пополнение в разделе «Документация» - Складской учёт, упрощённые операции

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

Тёмная тема - Прочее
Сергей: Здравствуйте! В этом окне сейчас нет настроек отображения. Цвет текста починим в новой версии. Если ещё где-то сталкиваетесь с подобным ...
Движение за период CurrentQuery - Отчёты
Сергей: Здравствуйте! Запрос в файле.
Сменный график - Общие вопросы
Константин Чилингаров: Да, список для выбора получится так поменьше. Но зато сначала то нужно будет ещё составить этот "список поменьше" из общего. Причем ...
Альтернативное обозначение отправочных марок - Отчёты
Константин Чилингаров: Здравствуйте,  Нужно в шаблоне отчёта поменять, чтобы вместо обозначения номенклатуры выводилось значение параметра этой номенклату ...
Пример создания плагина - Плагины
Константин Чилингаров: Не вижу смысла писать в таком случае свои "удалялки". Потеря времени. Проще и быстрее штатными функциями все поудалять в данном конк ...
Создание заказа на производство с учетом остатков/задела - Прочее
Константин Чилингаров: Здравствуйте, В современных версиях VOGBIT есть (где-то в прошлом году появилось впервые) "Автоматическое" заполнение (раззворачиван ...
Типовой технологический процесс - Состав и технология
Константин Чилингаров: Здравствуйте, Можно, например, создать стандартными средствами «Производственный заказ» (там как раз «разматывается» всё изделие по ...
График производства. Текущие работы - Производство
Sidneyanton: Спасибо за ответ, действительно не было связей, наверное при запуске стояла другая настройка последовательности.
Статистика - Производство
Алексей Пономарев: Благодарю за помощь все поправил.
Складской учет - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: написал: Еще бы поиск допилить в обеспеченности по заказам, чтоб искал не только номер, но и материал Будет. В ближайшем обновлении, на ...
Предварительные заявки - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Здравствуйте, Я посмотрел Ваш ролик. Спасибо! Только с обновлением это, по-моему, никак не связано.   Давайте поясню один момент: ...
Новая документация "График производства" - Прочее
Константин Чилингаров: Движок форума не разрешает напрямую Excel файлы в сообщения вставлять. Ну ладно. Понятно, в общем, о чем речь. на будущее: если нужно Excel фа ...
Ошибка отчёта "Недостаточно памяти" - Отчёты
Константин Чилингаров: Тут ещё знаете, в чем может быть дело... Не в размере даже, а во внутренностях конкретного файла с картинкой. Ошибка может озвучиваться си ...
Дублирование приходных ордеров - Прочее
Константин Чилингаров: Здравствуйте, Очень странная картина... Не сталкивались никогда с таким. Копию базы данных можете дать нам посмотреть? Если есть техни ...
Распределение работ. Дискретность настройки - Прочее
Константин Чилингаров: Здравствуйте, В этом окне, насколько я помню, сохраняется только список "постов" выбранных. При закрытии/открытии окна. Порядок сл ...
«Шаблон техпроцесса» - Состав и технология
Sidneyanton: Спасибо, за подробное разъяснение!
VOGBIT Онлайн - Общие вопросы
Владимир Белов: написал: Добрый день! Такой вопрос. Могу я установить базу данных на съемный диск и пользоваться на разных компьютерах - переставляя то ...
Создание нового производственного задания - Производство
Константин Чилингаров: Здравствуйте, написал: еперь при создании заказа в окне "Производственные заказы" этот самый заказ "дублируется" в окне " ...
Вопрос на тему "Технология подробно" - Состав и технология
Zms.komissarov: Нужно открыть, какой-нибудь (из какого удобно печатать) вариант "подробного" графика производства, там выбрать соответствующую опе ...
Не отображается выпадающий список, а также неактивна кнопка "Импорт" - Ошибки в работе
Сергей: написал: Не отображается выпадающий список при нажатии на стрелочку Напишите на mailto:info@vogbit.ru info@vogbit.ru Попробуем починить

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

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

×
Вход на сайт