неправильная мгновенная себестоимость составила 10 в 14 степени- что делать

[Aquarius]

Уважаемые господа!
Подскажите, пожалуйста, какие есть решения следующей задачи.

В Ax 3.0 Sp3 я выполнила следующие настройки:
1. Группа складских аналитик:
1.1 активный включено аналитики склад, партия, паллета, ячейка-
1.2. физ. наличие включено для аналитик склад, партия, паллета, ячейка,
1.3 .первичные аналитики -склад
1.4. финансовый склад включен для аналитик склад.

Настройки Группа складских моделей:
1.1. Складская модель ФИФО
Включены настройки:
1.2. Отрицательный физ склад,
1.3. Отрицательный фин склад,
1.4. Заказ на отгрузку,
1.5. Разносить физ операции,
1.6. Разносить фин операции,
1.7. Резервирование- контроль по дате.

постоянно есть отрицательный склад.
В поле "цена" группы "стоимость" установлена цена для всех номенклатур.
в руководстве пользователя MBS указано,что если нулевой или отрицательный уровень по выбранной комбинации "финансовых аналитик", то себестоимость будет списываться по стандартной себестоимости указанной в поле "цена" группы "стоимость" справочника номенклатуры.
Однако обнаружено что в складских проводках заказов,транспортировок, переносов себестоиомость перестала подставляться из поля цена при отрицательном складе, стала внезапно расти, и достигла приблизительно в некоторых случаях 10 в 14 степени .
Пересчет себестоимости исправляет только часть складских проводок.
т.к. для части расходных проводок сопоставлений нет из -за отрицательного склада.
а мгновенная себестоимость растет как снежный ком.
Что делать в такой ситуации?

[fed]

Цитата:

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

Уважаемые господа!
Подскажите, пожалуйста, какие есть решения следующей задачи.

В Ax 3.0 Sp3 я выполнила следующие настройки:
1. Группа складских аналитик:
1.1 активный включено аналитики склад, партия, паллета, ячейка-
1.2. физ. наличие включено для аналитик склад, партия, паллета, ячейка,
1.3 .первичные аналитики -склад
1.4. финансовый склад включен для аналитик склад.

Настройки Группа складских моделей:
1.1. Складская модель ФИФО
Включены настройки:
1.2. Отрицательный физ склад,
1.3. Отрицательный фин склад,
1.4. Заказ на отгрузку,
1.5. Разносить физ операции,
1.6. Разносить фин операции,
1.7. Резервирование- контроль по дате.

постоянно есть отрицательный склад.
В поле "цена" группы "стоимость" установлена цена для всех номенклатур.
в руководстве пользователя MBS указано,что если нулевой или отрицательный уровень по выбранной комбинации "финансовых аналитик", то себестоимость будет списываться по стандартной себестоимости указанной в поле "цена" группы "стоимость" справочника номенклатуры.
Однако обнаружено что в складских проводках заказов,транспортировок, переносов себестоиомость перестала подставляться из поля цена при отрицательном складе, стала внезапно расти, и достигла приблизительно в некоторых случаях 10 в 14 степени .
Пересчет себестоимости исправляет только часть складских проводок.
т.к. для части расходных проводок сопоставлений нет из -за отрицательного склада.
а мгновенная себестоимость растет как снежный ком.
Что делать в такой ситуации?

Возможно, вы столкнулись с багой в рассчете мгновенной себестоимости списания, которая существовала где-то начиная со 2-3 service pack для Axapta 3.0 и была вылечена в каком-то из rollupов для Axapta 4.0sp1. Срабатывает ТОЛЬКО при включенной галке "Включать физическую стоимость" в настройках складской модели. Так что выключите эту галку и пересчитайте склад пока не поздно. Если не успеете пересчитать склад во время - в момент закрытия склада Аксапта попытается запостить в ГК сумму, которая не влезет в разрядную сетку Numeric. Тогда без трудоемкой ручной коррекции данных проблему будет не исправить...
Гм. Посмотрел по внимательнее - вы ничего не пишете про значение этой волшебной галочки. Может она у вас все-таки ВКЛЮЧЕНА ?

[oip]

https://mbs.microsoft.com/partnersou...rintpage=false - возможно это (ссылка на закрытый партнерский ресурс). Хотфикс имеется для приложения начиная 3.0 SP5 с Inventory Closing Rollup 2 и выше. Начиная с некой версии 4.0 SP1 - исправлено. fed, как я понимаю, говорил именно об этом.

[Guntis]

Добрий день!
Тоже несколько раз встречался с подобнои ситуациеи но решил что причиной является - включенная галка "физический негативный склад". Немогли ли вы поделится опитом и более точной информацией

[fed]

В принципе - ты прав. Это завязано на отрицательный физический склад. Но сама ошибка срабатывает ТОЛЬКО если физический склад отрицательный и галка "Включать физические операции" включена. Если посмотреть на код рассчета себестоимости списания (inventMovement.financialIssueCostValue()), в старых версиях можно найти такой код:

value       = inventSum.postedValue;
 qty         = inventSum.postedQty;
 if (this.inventModelGroup().inclPhysicalValueInCost)
    {
        value += inventSum.physicalValue;
        qty   += inventSum.received - inventSum.deducted;
    }
...
return Currency::amount(value / qty * _inventTrans.qty);

Теперь представь себе картину: Оприходовали (физически и финансово) 100 КГ по цене 10000 рублей за КГ. Потом списали (физически) 199.9999 КГ. Теперь первое физическое списание списываем финансово. По формуле:
Qty=100
Value = 1000000
Deducted= 199.9999
Received=100
PhysicalValue - скорее всего равно нолю. ПОскольку первые 100 штук списывали со правильной физической себестоимостью, последующие - по себестоимости из карточки (допустим - незаполненной)
Получаем:
Qty=100+100-199.9999=0.0001; Value=1000000
Сбестоимость списания 1000000/0.0001=1E9. Такие дела

В более поздних sp эту формулу заменили на:

 inventSum   = _inventOnhand.inventSum();

    if (inventSum.PostedValue * inventSum.PostedQty > 0)
    {
        value       = abs(inventSum.postedValue);
        qty         = abs(inventSum.postedQty);
    }

    if (inventSum.PhysicalValue * (inventSum.Received - inventSum.Deducted) > 0 && this.inventModelGroup().inclPhysicalValueInCost)
    {
        value += abs(inventSum.physicalValue);
        qty   += abs(inventSum.received - inventSum.deducted);
    }

    if ((value * qty) <= 0 || qty <= 0)
    {
        value = _inventTrans.costAmountPhysical;
        qty   = _inventTrans.qty;
    }
...
return Currency::amount(value / qty * _inventTrans.qty);

[Aquarius]

Цитата:

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

Возможно, вы столкнулись с багой в рассчете мгновенной себестоимости списания, которая существовала где-то начиная со 2-3 service pack для Axapta 3.0 и была вылечена в каком-то из rollupов для Axapta 4.0sp1. Срабатывает ТОЛЬКО при включенной галке "Включать физическую стоимость" в настройках складской модели. Так что выключите эту галку и пересчитайте склад пока не поздно. Если не успеете пересчитать склад во время - в момент закрытия склада Аксапта попытается запостить в ГК сумму, которая не влезет в разрядную сетку Numeric. Тогда без трудоемкой ручной коррекции данных проблему будет не исправить...
Гм. Посмотрел по внимательнее - вы ничего не пишете про значение этой волшебной галочки. Может она у вас все-таки ВКЛЮЧЕНА ?

галка "Включать физическую стоимость" отключена была всегда.
У нас часто бывают разнесенные заказы, переносы завтрашним числом.
В них чаще всего вылазит гигантсткая себестоимость.
например в транспортировке 2880 штук фин. себестоимость 5603476036662,690 , т.е 1 штука 2001241441,66, хотя цена 1 штуки 7,31.
пересчет мы каждый день делаем сегодняшним числом.
Дело дошло до того,что мы теперь не смогли делать обновление в Гк по пересчету, у нас выдавалось сообщение о неправильной корреспонденции почему-то.
Приходится делать каждый день пересчет без обновления в ГК.
Все вылезшие большие суммы пересчетом корректируются. Но остаются висеть большие суммы документов, проведенных завтрашним числом.
Аксапта у нас используется для оперативного учета взаиморасчетов с клиентами, по счетам ГК пока данные нам не особо нужны. Нашу проблему мы пока не решили.

[AlGol]

Цитата:

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

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

После установки упомянутого выше хотфикса, должно исправится возникновение новых проводок с гигантскими суммами.

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

[Guntis]

[QUOTE=Aquarius;217640]
Дело дошло до того,что мы теперь не смогли делать обновление в Гк по пересчету, у нас выдавалось сообщение о неправильной корреспонденции почему-то.
Приходится делать каждый день пересчет без обновления в ГК.
Все вылезшие большие суммы пересчетом корректируются. Но остаются висеть большие суммы документов, проведенных завтрашним числом.
Аксапта у нас используется для оперативного учета взаиморасчетов с клиентами, по счетам ГК пока данные нам не особо нужны. Нашу проблему мы пока не решили.

Что делать,
1) Подправить БП и
2) Отключить – негативный физический склад

[bobski]

Доброго времени суток. Возникла серьезная проблема при коррктировке себестоимоси. Ситуация сложная и запущенная. Прошу помощи.
Ax 4.0 sp2, международный функционал на MSSQL 2005.
Учет в системе ведется более года.
Складская модель - взвешенное среднее. Вторичная валюта не выбрана. Склады ни разу не закрывались - пока нет возможности.

Однажды столкнулись с тем, что перестали разноситься заказы на продажу, ссылаясь на разницу во вторичной валюте. В результате выяснилось, что для некоторых номенклатур в разрезе отдельных складских аналитик себестоимость выросла до предельных порядков (увидели по inventTrans и InventSum). Аксапта не смогла с ними корректно работать, оттого и стали появляться глюки в разноске.
Спохватились, нашли и использовали HotFix 946804, который решил проблему роста себестоимости у номенклатур.

Запустили пересчет, который работал около месяца. Пройдя максимальные 100 итераций, пересчет отказался делать разноску в ГК, опять же ссылаясь на расхождения во вторичной валюте. Тот же глюк. Завершили пересчет без разноски в ГК.

Как можно решить подобную проблему? Возможно даже хирургическим путем?

[b_nosoff]

Цитата:

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

Нашу проблему мы пока не решили.

Хочу поинтересоваться у уважаемого топикстартера, удалось ли таки ее решить? Пробовали ли ставить хотфикс 946804?

[b_nosoff]

Цитата:

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

Как можно решить подобную проблему? Возможно даже хирургическим путем?

Хочу поинтересоваться, нашлось ли решение по прошествии нескольких месяцев? Мы тоже с этой фигней столкнулись. Ничего не нашел лучше, кроме как обнулить себестоимость. Хорошо, что проводок было совсем немного. Закрытие склада скорректировало себестоимость до нормальных цифр.