AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.05.2012, 14:16   #41  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Alexius Посмотреть сообщение
Ну раз пошла такая пьянка

Отмена закрытия склада при отключенном ключе двух-валютного склада пропускает удаление проводок SummedUp со всеми вытекающими вкусностями

Class / InventCostClosingCancel_WorkInvent / deleteVirtualTransfers
X++:
...
    while select forupdate inventTrans order by InventTransId
    where inventTrans.ValueOpen             == InventTransOpen::Yes
       // <GEEU>
//       && inventTrans.ValueOpenSecCur_RU    == InventTransOpen::Yes 
       && inventTrans.ValueOpenSecCur_RU    == (isConfigurationKeyEnabled(configurationkeynum(InventClosingSecCur_RU)) ?
                                                    InventTransOpen::Yes : InventTransOpen::No) 
       // </GEEU>
...
На SQL по закрытому ключом полю уходит условие 1=0 и ...

PS. Интересно, много ли еще таких мест ?
Почему в MS никто не сообщает? Прав нет или просто лень?
В RU8 ошибка старательно перенесена в метод \Classes\InventCostClosingCancel_End\deleteVirtualTransfers
Старый 16.05.2012, 15:10   #42  
Bega is offline
Bega
Участник
Аватар для Bega
 
382 / 444 (15) +++++++
Регистрация: 18.08.2005
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
Почему в MS никто не сообщает? Прав нет или просто лень?
В RU8 ошибка старательно перенесена в метод \Classes\InventCostClosingCancel_End\deleteVirtualTransfers
Я размещал при помощи Навикона 2-ю и 3-ю проблему в марте 2011 года, дальнейшую их судьбу не знаю, там была длительная переписка м/у сотрудником МС и сотрудником Навикона. Потом сотрудник Навикона уволился. В ru7/ru8 я не обнаружил никакого решения.

Проблема 2 - номер инцидента 111030950770658
Проблема 3 - номер инцидента 111030954402573

1-ю проблему в МС воспроизвести не удалось - она появляется у нас в большой цепочке производственных заказов, с несколькими связанными цехами. У нас до 16 уровней вложенности. Свою базу я отдать не мог, потому что коммерческая тайна (рецептуры и т.п.), а всю эту цепочку воспроизвести у меня времени не было.
Старый 17.10.2012, 14:24   #43  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
В завершение темы про ошибки в средней себестоимости:
Вот как работает рассчет средней себестоимость в западном приложении:
1. Для каждого закрываемого периода система создает фиктивный перенос. (Все последующие рассуждения относятся к модели "Средняя за период". В модели "Средняя на дату" система фактически разбивает месяц по датам каждого прихода и периоды между приходами трактует как отдельный период в модели "Средняя за период").
2. Система суммирует все приходы открытые на начало прихода и все приходы за период и присваивает рассчитанную себестоимость и количество в проводки фиктивного переноса.
3. Все расходы периода сопоставляются с приходной проводкой по фиктивному переносу, все приходы периода (и незакрытые приходы на начало периода) сопоставляются с расходной проводкой по переносу.
4. Система имеет специальный режим восстановления после сбоев. Если при обработке периода был найден уже существующий фиктивный перенос с нужной датой, система просто повторно использует его, не меняя суммы и количества.
5. Если закрытие склада отменяется, система удаляет все фиктивные переносы периода и все связанные с ними складские сопоставления и корректировки стоимости.

Если приглядется на код локализованного метода InventCostClosingCancel_WorkInvent.deleteVirtualTransfers() (или InventCostClosingCancel_End.deleteVirtualTransfers() - в зависимости от версии rollup), то можно найти следующий замечательный код:
X++:
   while select forupdate inventTrans order by InventTransId
        where inventTrans.ValueOpen             == InventTransOpen::Yes
           && inventTrans.ValueOpenSecCur_RU    == InventTransOpen::Yes
           && inventTrans.Voucher               == cancelClosing.Voucher
           && inventTrans.TransType             == InventTransType::SummedUp
Если у вас разрешена российская функциональность, но запрещен двухвалютный склад (а учитывая его качество - он у 95% пользователей запрещен), то условие inventTrans.ValueOpenSecCur_RU == InventTransOpen::Yes вернет false и никакие записи не будут обработаны (и, соответственно, никакие фиктивные переносы не будут удалены). Дальше - интереснее. Если вы закрыли склад, потом отменили закрытие, запостили парочку новых приходов и расходов, то следующее закрытие, наткнувшись на болтающиеся старые фиктивные переносы, с радостью примет их за результаты сбойного закрытия и попытается повторно их использовать. Правда, поскольку закрытие ничего плохого не подозревает, оно не поменяет стоимость и количество в этих переносах. А потом не проверяя, сопоставит со всеми приходами и расходами. В результате у фиктивного переноса может получиться пересопоставление - типа в qty стоит 100 штук, а в qtySettled - 120. Ну и конечно вся себестоимость едет и накрывается медным тазом...

Рекомендую поменять указанный выше код на что-нибудь типа
X++:
   while select forupdate inventTrans order by InventTransId
        where inventTrans.ValueOpen             == InventTransOpen::Yes
           && (!isconfigurationKeyEnabled( configurationkeynum(InventClosingSecCur_RU)) || inventTrans.ValueOpenSecCur_RU    == InventTransOpen::Yes)
           && inventTrans.Voucher               == cancelClosing.Voucher
           && inventTrans.TransType             == InventTransType::SummedUp
Еще очень рекомендую сначала попробовать предложенные мною и участником Bega правки на тестовой базе и потом пару месяцев попробовать позакрывать склад и посмотреть за результатами. А то один мой польский клиент сначала исправил ошибку, а потом, когда новые закрытия стали налетать на изуродованные складские проводки старых закрытий, получил не мало проблем...
Старый 17.10.2012, 14:33   #44  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Теперь отдельным постом, почему метод удаления фиктивных переносов переехал из класса InventCostClosingCancel_WorkInvent в класс InventCostClosingCancel_End(Это было исправлено в RU8 или RU7).
Отмена закрытия (также как и закрытие) обращаются с разноской следующим образом: Сначала система создает кучу записей в inventSettlement, потом (в самом конце закрытия или отмены закрытия), система вызывает класс разноски (InventAdjustPostClosing/InventAdjustPostClosingCancel). Как я уже сказал, НОРМАЛЬНОЕ поведение отмены закрытия по складу подразумевает удаление и фиктивных переносов. При удалении проводки из inventTrans, система автоматически удаляет и связанные сопоставления. Так что в старых роллапах, некоторые отмены сопоставления в inventSettlement не доживали до разноски в ГК, поскольку их родительские переносы удалялись классом InventCostClosingCancel_WorkInvent, который отвечает за отмену закрытия по отдельной номенклатуре. К большим проблемам, это обычно не приводило, поскольку в 99% случаев, сопоставления фиктивных переносов не разносятся в ГК. (Разноска в ГК сопоставлений фиктивных переносов может случаться только в случае если это не сопоставление в строгом смысле слова, а списание округления или ошибки по исчерпанию числа итераций при закрытии). Однако же в последних Rollupах эту проблему выловили и вылечили. Проверьте - если в вашей версии метод InventCostClosingCancel_WorkInvent.deleteVirtualTransfers не пустой, попробуйте перенести все класса InventCostCancel* с более позднего roll up.

Кроме того - с используемым подходом, БЕСПОЛЕЗНО после отмены закрытия пытаться выверить само закрытие или его отмену. Поскольку отмена закрытия гарантировано удаляет складские сопоставления, в общем случае обороты по ГК ваучера закрытия или отмены НЕ БУДУТ соответствовать оборотам по inventSettlement с тем же номером ваучера.
Теги
баг, закрытие склада, ошибка, ошибка при закрытии склада, себестоимость

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Завышенная себестоимость по расходам после закрытия склада в DAX2009 Bega DAX: Функционал 13 14.02.2011 12:55
Не хватает фин. аналитик при пересчете и закрытии склада Geo DAX: Функционал 7 23.10.2010 00:24
Проблема с журналом спецификаций при закрытии склада CDR DAX: Функционал 2 24.05.2010 10:50
Denis Fedotenko: Себестоимость и закрытие склада Blog bot DAX: База знаний и проекты 44 29.03.2010 14:54
Финансовые проблемы при Закрытии склада Владимир Ю. DAX: Функционал 6 28.06.2005 20:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:24.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.