Хотфикс для 2009ой с большими граблями - не ставьте!

[fed]

Привет !

У меня клиенты имели неосторожность поставить микрософтовский хотфикс KB2804719, после чего я уже вторую неделю разргребаю последствия. Выяснилось что:
1. Капитально сломан рассчет налогов по журналам. Функция TaxLedgerJournal.init(), если стоит галочка "сумма по журналу включает налог" начала подспудно и без объявления войны рассчитывать налог не только по текущей строке, но и по всему ваучеру (который в западном учете может быть многострочным с разными налогами по разным строкам). В итоге, заметная часть кода, которая этот класс использовала не для разноски налога, а просто для рассчета суммы налога по строке - стала сходить с ума. Просто напросто теперь taxWorkTrans внезапно стал содержать налоги по более чем одной строке и их тупое суммирование, стало возвращать в несколько раз больше налогов чем ожидалось. Например - при разноске по типу счета Проект, система уходит в дизбаланс, поскольку оно нечаянно вычитает из сумы по строке в три раза больше налогов чем потом реально на налоговые счета разносит. В итоге при разноске строки с сумой 118 на налог идет 18 а на себестоимость (118-18*3) (если у нас три строки с налогом).
2. Сломана коррекция налогов по заказам/закупкам и текстовым накладным. По идее- коррекция привязана к документу и налоговому коду (не к конкретной строке документа). Это всегда так было. В данном хотфиксе разработчики попытались привязать ее к строке. Правда мысль добавить в таблицу коррекций новое поле для этого дела им в голову не пришла. Напомню, что в налоговых таблицах (типа tmpTaxTrans) есть две ссылки - одна на строку документа SourceRecId/SourceTableId, другая на его шапку (headingRecId/headingTableId). В простых случаях - типа строки журнала - обе ссылки совпадают. В заказах/закупках и текстовых накладных - они разные. В результате того что разработчики сравнивают taxWorkTrans.SourceRecId с taxRegulation.headingRecId, случается грандиозный облом при работе с многострочными документами. С журналами коррекция как-то еще работает (точнее - иногда работает - см ниже), но с заказами и закупками - ни в жизнь.
3. В результате противоестественных манипуляций с TaxLedgerTrans, разработчики начали терять ссылку на headingRecId. То есть - в процессе пробега по всем строкам ваучера, они присваивают headingRecId ссылки на очередную строку журнала, но в конце забывают восстановить оригинальное значение. В итоге - если мы пытаемся по журналу скорректировать налоги, то коррекция срабатывает (вроде бы - не уверен до конца) только если последняя строка ваучера имеет тот же налоговый код, что и корректируемый налог. Дело в том что в форму коррекции налогов попадает уже измененный и поломанный headingRecId, в результате чего коррекция налога подспудно происходит только для последней строки ваучера.
4. Судя по всему сломаны сопоставления в режиме Use Cash Discount. До конца не разбирался - но у нас внезапно при сопоставлении ушли проводки из custTransOpen, хотя в custTrans эта пара проводок помечена как открытая. Мы пока решили просто этим режимом не пользоваться, но скрипт для починки данных мне все равно писать придется.

Выводы - регрессионного тестирования патча не было. Тестировали только для наиболее очевидных случаев (одна строка в ваучере) и только для журналов (но не для закупок или заказов). Кроме того - цель патча в целом непонятна...
Рекомендация - не ставьте ни в коем случае !

[romanab]

Все ошибки связанные с налогами были исправлены в последующих исправлениях. Рекомендую установить обновление KB2855780, которое включает исправление всех упомянутых проблем. Плюс можно поставить KB2754392 для исправления похожей проблемы с проектами.
Здесь я привожу список подобных критических обновлений - Important application hotfixes

[EVGL]

См. также DAX2009 SP1 RU8 Перестал правильно считаться НДС

[mnt_dx]

Коллеги, где вы сейчас берете хотфиксы с учетом того, что https://mbs2.microsoft.com/ не работает?

Цитата:

We are currently transitioning to a new Knowledge Base system to provide you a better experience. During the transition period, access to Knowledge Base articles from within CustomerSource and PartnerSource will be unavailable. During this transition period, Knowledge Base articles can be found by utilizing the search functionality located on the Microsoft Support Website.

[gl00mie]

Исправления давно уже перекочевали в LCS. Зная номер KB, исправление можно скачать с сайта поддержки, минуя LCS, по ссылке, подобной этой.