Хотфикс для 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 эта пара проводок помечена как открытая. Мы пока решили просто этим режимом не пользоваться, но скрипт для починки данных мне все равно писать придется.

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