Поле Кол-во и Остаток Кол-во

[art06]

Добрый день.

Возникла следеующая ситуация.
В настройках "РАЗРЕШИТЬ ОТРИЦАТЕЛЬНЫЙ ОСТАТКИ" - стоит в полложение FALSE.

В стандартном 22 Кодюните - нет доработок.


Для пользователей седеланно так - о том какое кол-во товара на складе они видят по сумме столбца Кол-во, а не ОстатокКол-во.

Раньше - поля в ТоварКнигаОперации - Кол-во и ОстатокКол-во - совпадало (имееется ввиду - если просумировать эти столбцы для одного товара на одном складе).

Сейчас сумма этих столбцов не совпадает !!!

Ситуация в основном такая - Кол-во меньше, чем ОстатокКол-во. Например: Кол-во 100, ОстатокКол-во 200

Пользователь не заглядывая в карточку товара - делает ПродажаЗАказ - Отгрузить. Отгружает 150. Система разрешает отгрузить. В результате пользователь видит что у него на складе -50.

Вопрос в следующем :
1. Можно ли считать нормальной ситуацию - Расхождение Сумм поле Кол-во, и ОстатокКол-во ?????
2. По какому полю необходимо правильно судить об остатках на складах ?????
3. Что может приводить с Расхождению данных в этих столбцах ???

[rmv]

1. Нет нельзя.
2. Текущие остатки - можно и по тому и по другому. Остатки на дату - поле Кол-во.

Вопросы:
1. Сервер и версия Нава?
2. Используете ли единицы измерения, кол-во в которых отлично от 1?

Посмотрите 339 таблицу и проанализируйте на каких операциях возникают неправильные применения.

[RedFoxUA]

Цитата:

Сообщение от art

Возникла следеующая ситуация.
В настройках "РАЗРЕШИТЬ ОТРИЦАТЕЛЬНЫЙ ОСТАТКИ" - стоит в полложение FALSE.

В стандартном 22 Кодюните - нет доработок.
Для пользователей сделанно так - о том какое кол-во товара на складе они видят по сумме столбца Кол-во, а не ОстатокКол-во.

не очень до конца понятно как было сделано (но мне кажется, что не очень правильно).

Цитата:

Раньше - поля в ТоварКнигаОперации - Кол-во и ОстатокКол-во - совпадало (имееется ввиду - если просумировать эти столбцы для одного товара на одном складе).

Сейчас сумма этих столбцов не совпадает !!!

Ситуация в основном такая - Кол-во меньше, чем ОстатокКол-во. Например: Кол-во 100, ОстатокКол-во 200

Кол-во обычно (если не сделано доработок) будет НЕ меньше, чем ОстатокКол-во (из-за того, что остаток не может превышать исходное значение).
В 32 нет приходов с отрицательными кол-вами?
Вы уверены, что никаких доработок по товароному дижению не было?
Если хотите, то вышлите мне пример таблицы несовпадений то по одному из товаров на мыло (всю таблицу по фильтру)

Цитата:

Пользователь не заглядывая в карточку товара - делает ПродажаЗАказ - Отгрузить. Отгружает 150. Система разрешает отгрузить. В результате пользователь видит что у него на складе -50.

Вопрос в следующем :
1. Можно ли считать нормальной ситуацию - Расхождение Сумм поле Кол-во, и ОстатокКол-во ?????
2. По какому полю необходимо правильно судить об остатках на складах ?????
3. Что может приводить с Расхождению данных в этих столбцах ???

Ответы:
1. Сотуация нормальная, когда Кол-во >= ОстатокКол-во
2. В зависимости от того, что нужно получить в итоге. Можно судить и по Кол-во, и ОстатокКол-во (с признаком Открыто)
3. Предполагаю в Вашем случае (Кол-во < ОстатокКол-во), что либо доработка, либо Заказы/Возвраты (с отрицательными значениями в строках)

[art06]

Цитата:

Сообщение от rmv

1. Нет нельзя.
2. Текущие остатки - можно и по тому и по другому. Остатки на дату - поле Кол-во.

Вопросы:
1. Сервер и версия Нава?
2. Используете ли единицы измерения, кол-во в которых отлично от 1?

Посмотрите 339 таблицу и проанализируйте на каких операциях возникают неправильные применения.

1. Nav 3.7 - MSSQL2000
2. Возможно не совсем правильно понял ваш вопрос: в ТКО есть кол-во не целое - например Кол-во сахар 3,5 кг

[rmv]

RedFoxUA - не стоит вводить art'a в заблуждение. Лучше почитайте доку.

1. Открываем 32 таблицу, жмем F1 на поле остаток и читаем.читаем читаем.

2. Далее лезем в стандартный Кронус и замечаем - на большинстве отрицательных операций поле Остаток Кол-во = 0. Что это означает - значит отрицательная операция (расход) была применена к положительной (приход). И все же есть отрицательные количества в поле Остаток - это значит была продажа в минус и расход в приходу пока не применился.

3. Лезем в 339 таблицу и изучаем что же такое применения.

4. Путем несложных умозаключений получаем, что сумма по полю Кол-во всегда должно равнятся сумме по полю Остаток.

[randrews]

Цитата:

Сообщение от RedFoxUA

1. Сотуация нормальная, когда Кол-во >= ОстатокКол-во

Цитата:

Сообщение от rmv

RedFoxUA - не стоит вводить art'a в заблуждение. Лучше почитайте доку.

Да, ладно... Не стоит сразу всех отправлять читать доку Просто человек не обратил внимание на фразу Расхождение Сумм

[Sitizen]

1. Не нормально и более того - это очень плохо.
2. Ориентироваться все равно по какому полю, т.к. их суммы должны быть равны. Но Navision остатки считает по полю "Остаток количество"
3. Если ничего не переписывали, значит товарные операции удаляли руками.

Можете проверить, если не работает "Корекция себестоимости операций", то точно удаляли.

[RedFoxUA]

Цитата:

Сообщение от Sitizen

3. Если ничего не переписывали, значит товарные операции удаляли руками.

Можете проверить, если не работает "Корекция себестоимости операций", то точно удаляли.

Возможно удалена либо покупка (которая далее была применена нормально), либо положительный приход (транзит) на склад, к которому были применены продажи.

[rmv]

Если в применениях ничего не грохали, можно найти косячные операции и сузить область поиска.
Прогоните цикл по 339:
with t339 do begin
setcurrentkey("Inbound Item Entry No.");
if find('-') then repeat
setrange("Inbound Item Entry No.", "Inbound Item Entry No.");
calcsums(Quantity);
t32.get("Inbound Item Entry No.");
if t32."Remaining Quantity"<>Quantity then begin
temp32:=t32;
temp32.insert;
end;
find('+');
setrange("Inbound Item Entry No.");
until next=0;
end
form.runmodal(0, temp32);

[Галина]

Цитата:

Сообщение от randrews

Да, ладно... Не стоит сразу всех отправлять читать доку Просто человек не обратил внимание на фразу Расхождение Сумм

Хм... а где была эта фраза? Расхождение сумм? Я не увидела.
rmv-на мой взгляд ответ RedFoxUA-вполне правильный.
В карточке товара остаток считается положительный операции минус отрицательные операции.
А вот в документах-в применении - используются положительные операции с Остатком Кол-во <>0.
И насколько я понимаю RedFoxUA-это и описывал.
Поэтому к документации тоже не стоит отправлять.

[randrews]

Цитата:

Сообщение от Галина

Хм... а где была эта фраза? Расхождение сумм? Я не увидела.

В первоначальном сообщении пункт 1.

Цитата:

Сообщение от Галина

И насколько я понимаю RedFoxUA-это и описывал

Если я правильно понял, то RedFoxUA пропустил слово "сумм" и прочитал
"Расхождение полей Кол-во, и ОстатокКол-во"
Поэтому и ответил "1. Сотуация нормальная, когда Кол-во >= ОстатокКол-во", имея ввиду значения поле по одной операции Item Ledger Entry.

И тогда его ответ разумен. А суммы этих полей должны быть равны !!!

[rov_imported]

Согласен с ответом Sitizen

1. Суммы по полю Кол-во и Остаток кол-во - должны быть ВСЕГДА равны(на текущую дату).
Если они не равны - это действительно плохо.
2. Судить по кол-во можно по обоим полям: опять же если смотришь на дату в прошлом -
то надо использовать поле "Кол-во".

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

[Галина]

Цитата:

Сообщение от randrews

В первоначальном сообщении пункт 1.
Если я правильно понял, то RedFoxUA пропустил слово "сумм" и прочитал
"Расхождение полей Кол-во, и ОстатокКол-во"
Поэтому и ответил "1. Сотуация нормальная, когда Кол-во >= ОстатокКол-во", имея ввиду значения поле по одной операции Item Ledger Entry.

И тогда его ответ разумен. А суммы этих полей должны быть равны !!!

Не поняла. а что такое суммы полей??????? Кол-во и ОстатокКол-во?

[art06]

Всем спасибо за помощь.
На данный момент пока мне так и не удалось найти причину по которой произошло расхождения Кол-во и ОстатокКол-во.
Пытаюсь проанализировать 339 и ТКО и найти причину.

[Sitizen]

Цитата:

Сообщение от art

Всем спасибо за помощь.
На данный момент пока мне так и не удалось найти причину по которой произошло расхождения Кол-во и ОстатокКол-во.
Пытаюсь проанализировать 339 и ТКО и найти причину.

Проанализируй номера операций в 32-й таблице. Они должны идти по порядку без пропусков. Если есть пропуски, значит удаляли операции.

[Галина]

Цитата:

Сообщение от art

Всем спасибо за помощь.
На данный момент пока мне так и не удалось найти причину по которой произошло расхождения Кол-во и ОстатокКол-во.
Пытаюсь проанализировать 339 и ТКО и найти причину.

Слушайте объясните еще раз. В чем был у вас вопрос? Только пожайлуста сформулируйте более грамотного.
А то вот мне интересно. Но я так и не пойму про что вы писали и остальные похоже тоже.
Толи про суммы полей Кол-во и ОстатокКол-во (хотя я так и не понимаю что под этим имеют ввиду)
Толи про значение этих полей. Если про поля 32 таблицы-то конечно они должны расходиться для приходных операций. Как впрочем и для расходных операций.
И почему вы решили-что такого не должно быть-я например не понимаю.

[RedFoxUA]

Цитата:

Сообщение от Галина

Слушайте объясните еще раз. В чем был у вас вопрос? Только пожайлуста сформулируйте более грамотного.
А то вот мне интересно. Но я так и не пойму про что вы писали и остальные похоже тоже.
Толи про суммы полей Кол-во и ОстатокКол-во (хотя я так и не понимаю что под этим имеют ввиду)
Толи про значение этих полей. Если про поля 32 таблицы-то конечно они должны расходиться для приходных операций. Как впрочем и для расходных операций.
И почему вы решили-что такого не должно быть-я например не понимаю.

Если я правильно все понял, то по 32 таблице получается, что по 1 конкретному товару итоговые суммарные значения полей Кол-во и ОстатокКол-во не совпадают (хотя итоги суммирования всех строк в Excel должны совпадать. Пример - наложить фильтр ТОЛЬКО по любому товару, перенести в Excel и подсчитать итоги).
Далее "усложняется" задача путем введения фильтра по складам. Точно так же я бы и продолжал анализировать для поиска места проблемы (если не хочется проверять 32 на "дырчатость" или это ничего не дало).

А вот теперь пусть меня поправит art в не корректном месте.

[Wizard_imported]

Галина, суммы по полям Кол-во (12) и Остаток Колво (13) в разрезе "товар-склад-ячейка-вариант" (опционально ещё и "сер.но" или "лот.но", а так же в разрезе номера транз. перемещ. для транз. склада) должны совпадать. Это обусловлено логикой применения товарных операций при учете (22 юнит, ф-я ApplyItemLedgEntry). Несовпадение этих сумм означает только одно - РУКИ! удалили проводку (скорее всего расходную), а применение тов. операций не откатили (грамотно это сделать несложно, но надо понимать...)
Теперь надо искать эту самую причину, восстанавливать правильное значение поля "остаток кол-во" в нужных записях 32 книжки. Сумму по полю "кол-во" - а это и есть остаток на складе - следует проверить инвентаризацией.
Способ поиска RedFox правильно подсказывает.

[Галина]

А все поняла наконец то.
Точно я же сама так периодически проверяю - товары. Ответ однозначный полазили ручками. Искать проблематично.

[RedFoxUA]

Цитата:

Сообщение от Wizard

удалили проводку (скорее всего расходную), а применение тов. операций не откатили (грамотно это сделать несложно, но надо понимать...)

Я все-таки думаю, что грохнули приходную (так как Кол-во меньше, чем ОстатокКол-во), хотя накрутить могливсе, что угодно. Предлагаю дождать официального ответа "виновника торжества" ;-)