Проблемы при закрытии склада DAX2009 SP1 RU5/RU6

[EVGL]

Цитата:

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

Ну раз пошла такая пьянка

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

Class / InventCostClosingCancel_WorkInvent / deleteVirtualTransfers

...
    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

[Bega]

Цитата:

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

Почему в MS никто не сообщает? Прав нет или просто лень?
В RU8 ошибка старательно перенесена в метод \Classes\InventCostClosingCancel_End\deleteVirtualTransfers

Я размещал при помощи Навикона 2-ю и 3-ю проблему в марте 2011 года, дальнейшую их судьбу не знаю, там была длительная переписка м/у сотрудником МС и сотрудником Навикона. Потом сотрудник Навикона уволился. В ru7/ru8 я не обнаружил никакого решения.

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

1-ю проблему в МС воспроизвести не удалось - она появляется у нас в большой цепочке производственных заказов, с несколькими связанными цехами. У нас до 16 уровней вложенности. Свою базу я отдать не мог, потому что коммерческая тайна (рецептуры и т.п.), а всю эту цепочку воспроизвести у меня времени не было.

[fed]

В завершение темы про ошибки в средней себестоимости:
Вот как работает рассчет средней себестоимость в западном приложении:
1. Для каждого закрываемого периода система создает фиктивный перенос. (Все последующие рассуждения относятся к модели "Средняя за период". В модели "Средняя на дату" система фактически разбивает месяц по датам каждого прихода и периоды между приходами трактует как отдельный период в модели "Средняя за период").
2. Система суммирует все приходы открытые на начало прихода и все приходы за период и присваивает рассчитанную себестоимость и количество в проводки фиктивного переноса.
3. Все расходы периода сопоставляются с приходной проводкой по фиктивному переносу, все приходы периода (и незакрытые приходы на начало периода) сопоставляются с расходной проводкой по переносу.
4. Система имеет специальный режим восстановления после сбоев. Если при обработке периода был найден уже существующий фиктивный перенос с нужной датой, система просто повторно использует его, не меняя суммы и количества.
5. Если закрытие склада отменяется, система удаляет все фиктивные переносы периода и все связанные с ними складские сопоставления и корректировки стоимости.

Если приглядется на код локализованного метода InventCostClosingCancel_WorkInvent.deleteVirtualTransfers() (или InventCostClosingCancel_End.deleteVirtualTransfers() - в зависимости от версии rollup), то можно найти следующий замечательный код:

   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. Ну и конечно вся себестоимость едет и накрывается медным тазом...

Рекомендую поменять указанный выше код на что-нибудь типа

   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 правки на тестовой базе и потом пару месяцев попробовать позакрывать склад и посмотреть за результатами. А то один мой польский клиент сначала исправил ошибку, а потом, когда новые закрытия стали налетать на изуродованные складские проводки старых закрытий, получил не мало проблем...

[fed]

Теперь отдельным постом, почему метод удаления фиктивных переносов переехал из класса InventCostClosingCancel_WorkInvent в класс InventCostClosingCancel_End(Это было исправлено в RU8 или RU7).
Отмена закрытия (также как и закрытие) обращаются с разноской следующим образом: Сначала система создает кучу записей в inventSettlement, потом (в самом конце закрытия или отмены закрытия), система вызывает класс разноски (InventAdjustPostClosing/InventAdjustPostClosingCancel). Как я уже сказал, НОРМАЛЬНОЕ поведение отмены закрытия по складу подразумевает удаление и фиктивных переносов. При удалении проводки из inventTrans, система автоматически удаляет и связанные сопоставления. Так что в старых роллапах, некоторые отмены сопоставления в inventSettlement не доживали до разноски в ГК, поскольку их родительские переносы удалялись классом InventCostClosingCancel_WorkInvent, который отвечает за отмену закрытия по отдельной номенклатуре. К большим проблемам, это обычно не приводило, поскольку в 99% случаев, сопоставления фиктивных переносов не разносятся в ГК. (Разноска в ГК сопоставлений фиктивных переносов может случаться только в случае если это не сопоставление в строгом смысле слова, а списание округления или ошибки по исчерпанию числа итераций при закрытии). Однако же в последних Rollupах эту проблему выловили и вылечили. Проверьте - если в вашей версии метод InventCostClosingCancel_WorkInvent.deleteVirtualTransfers не пустой, попробуйте перенести все класса InventCostCancel* с более позднего roll up.

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