Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ )

[AP-1055D]

Добрый день,

Коллеги, извиняюсь за оффтоп, но хотелось бы узнать какой уровень, по вашему мнению, должен быть у разработчика, чтобы установить данное обновление на сильно модифицированное приложение 3-ей или 4-ой версии?

[axalex]

День добрый, вопрос, возвращающий не на долго в начало.
Как я понимаю KB2620178 встает только на DAX 2009 AX2009 SP1 EE RU7?
Т.к. на DAX 2009 RU6 Kernel / Appl. version: 5.0.1500.3761; Solution version: RU HRP 5.0.1500.2116.1 не встает. Куда смотреть, что менять?
P.S.: Накатываю hotfix 1й раз. Help.
Заранее спасибо.

[Tarrash]

Коллеги, доброго времени суток!

Вопрос: кто-нибудь уже переносил корректирующие счета-фактуры на версию 4.0?

[Tarrash]

Если точнее, корректировочные счета-фактуры.

[Zabr]

В переданном партнёром XPO - ровно 100 объектов АОТ. Пока поостерегся переносить...

[Flomik]

Делаю возврат по Заказу на продажу, указываю ссылку на возвращаемую накладную и СФ.

После разноски получаю формирую печатную форму (см. вложение). Я так понимаю, форма некорректна, т.к.в блоке А должна быть корректируемая строка исходной накладной, а в блоке Б остаток после возврата?!

Кто-нибудь сталкивался с этой проблемой?

[Daiver]

Цитата:

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

Делаю возврат по Заказу на продажу, указываю ссылку на возвращаемую накладную и СФ.

После разноски получаю формирую печатную форму (см. вложение). Я так понимаю, форма некорректна, т.к.в блоке А должна быть корректируемая строка исходной накладной, а в блоке Б остаток после возврата?!

Кто-нибудь сталкивался с этой проблемой?

Точно с такой же проблемой столкнулся В поле CustInvoiceTrans.RefAdjustedInvoiceTrans_RU попадают не верные RecId. Ссылаются на ту же номенклатуру, но совершенно не на ту накладную с которой связывали при разноске Накладной. Причем странный эффект, когда я помогаю разносить Накладную и СФ с коррекцией, всё нормально, а у пользователей получается не верная связка в строчках. Вроде делают то же самое.

То что касается производительности. Индекс по полю CustInvoiceTrans.RefAdjustedInvoiceTrans_RU не помог Посмотрел план запроса через SQL, больше всего времени тратится на выборку из таблиц SalesParmLine (у нас в ней 4 300 000 записей), SalesParmTable ( 800 000 записей). Добавление индекса по полю RefAdjustedInvoiceTrans_RU в SalesParmLine не принесло положительного результата. Вот думаю, либо запрос этот переписывать, либо заняться чисткой SalesParmLine. Что посоветуете?

[Raven Melancholic]

Интересно, кто придумал завязывать функционал на SalesP arm* многие эти таблицы безжалостно чистят.

[Logger]

Цитата:

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

Вот думаю, либо запрос этот переписывать, либо заняться чисткой SalesParmLine. Что посоветуете?

Чистка табличек точно должна помочь.

[Logger]

Цитата:

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

Причем странный эффект, когда я помогаю разносить Накладную и СФ с коррекцией, всё нормально, а у пользователей получается не верная связка в строчках. Вроде делают то же самое.

Я при тестировании видел похожий эффект. По-моему это может получаться из-за некорректного прерывания разноски накладной, когда мусор остается в salesParmTable/Line

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

см. также.
Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ )

[vanokh]

Цитата:

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

Точно с такой же проблемой столкнулся В поле CustInvoiceTrans.RefAdjustedInvoiceTrans_RU попадают не верные RecId...

То что касается производительности. Индекс по полю CustInvoiceTrans.RefAdjustedInvoiceTrans_RU не помог...

Подниму еще раз...
В последнем хотфиксе (исправительные фактуры, который проектом xpo) запрос для заполнения ссылки переделали - проблема производительности похоже больше не актуальна. Из него выкинули связь с SalesParm*** и оставили прямое условие RefAdjustedInvoiceTrans_RU = 0 (это в методе CustVendInvoiceTrans::queryCorrectedTrans_RU())

То есть, после выполнения запроса

update_recordSet custInvoiceJour
    setting RefOriginalInvoice_RU = custInvoiceJour.RecId
    where
        custInvoiceJour.RefOriginalInvoice_RU == 0
    ;

не будет выбираться вообще ничего!
А если такой запрос не выполнялся, то будет выбираться исходная накладная (самая первая в цепочке), что тоже не совсем корректно для корректировочных документов. Для исправительных это смысл имеет, но видимо разработчики поленились писать дополнительную логику в зависимости от указанного типа корректировка-исправление и оставили выбор корректируемой строки на откуп пользователю...