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

[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]

Цитата:

Сообщение от 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
    ;

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

[Jabberwocky]

Цитата:

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

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

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

[vanokh]

Цитата:

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

Нет, не поленились. Просто немного изменился механизм линковки исходных и корректирующих строк накладных (линки, сделанные старым механизмом новым алгоритмом поддерживаются).

Только строк? А шапки и фактуры по-прежнему в цепочке? Что-то я совсем запутался, пойду разбираться...

[maldini]

Добрый день.
Ax2009 RollUp 7 установлены все последние патчи кроме тех что идут на RollUp 8

При попытке закрыть книгу продаж возникает ошибка, не найдено значение в карте соответствия.

Посмотрел код, наткнулся на то что есть Map в котором записаны строки из FactureTrans
с ключом [tax,dim,inventTransId,internalInvoiceId,invoiceId,numberSequenceGroupId], а ошибка возникает когда в этом map из журнала восстановления НДС ищутся значения, но вот только ключ из журнала восстановления НДС приходит с пустым inventTransId и конечно возникает ошибка.

Подскажите, что может быть?

[TravellerInTime]

Цитата:

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

Ax2009 RollUp 7 установлены все последние патчи кроме тех что идут на RollUp 8

При попытке закрыть книгу продаж возникает ошибка, не найдено значение в карте соответствия.

Тоже столкнулись с подобным. Насколько я понимаю, чтобы работал русский функционал книг покупок и продаж, необходимо включать "Группировать по номеру лота" в настройках поставщиков - закладка "Главная книга и налог" группа "Книга покупок". Без включения этой галки заставить работать акс без ошибки нам не удалось.

[maldini]

Цитата:

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

Тоже столкнулись с подобным. Насколько я понимаю, чтобы работал русский функционал книг покупок и продаж, необходимо включать "Группировать по номеру лота" в настройках поставщиков - закладка "Главная книга и налог" группа "Книга покупок". Без включения этой галки заставить работать акс без ошибки нам не удалось.

Проблемма где то в другом месте, если при закрытии книги продаж в журнале восстановления НДС есть суммы больше 0, то код идет по другой ветке, в которой и возникает ошибка.
Вот фрагмент кода

while select restoredVATLogTransOper
            where restoredVATLogTransOper.Include
        exists join restoredVATLogTrans
            where restoredVATLogTrans.TransDate             == restoredVATLogTransOper.TransDate            &&
                  restoredVATLogTrans.ProcessLogTransRecId  == restoredVATLogTransOper.ProcessLogTransRecId &&
                  restoredVATLogTrans.InvoiceRecId          == vendTrans.RecId                              &&
                  restoredVATLogTrans.FactureId             == factureJour.FactureId                        &&
                  restoredVATLogTrans.FactureModule         == factureJour.Module
        exists join restoredVATLogTable
            where restoredVATLogTable.TransDate == restoredVATLogTransOper.TransDate &&
                  restoredVATLogTable.Approved
        {
            if (restoredVATLogTransOper.TaxAmount          +
                restoredVATLogTransOper.TaxAmountNotLiable +
                restoredVATLogTransOper.TaxAmountWrittenOff == 0)
            {
                continue;
            }
            key = [restoredVATLogTransOper.TaxCode,
                   restoredVATLogTransOper.Dimension,
                   restoredVATLogTransOper.InventTransId,
                   vendInvoiceJour.InternalInvoiceId,
                   vendInvoiceJour.InvoiceId,
                   vendInvoiceJour.NumberSequenceGroup];
            addRestoredAmounts(SalesBookVATRestoringType_RU::Export);
            addRestoredAmounts(SalesBookVATRestoringType_RU::NotLiableToVAT);
            addRestoredAmounts(SalesBookVATRestoringType_RU::AssetDisposal);

Вот тут если сумма не равна 0 то заполняется Map который потом в цикле проходит, но возникает ошибка так как в строках фактуры не находится ни одно значение без inventTransId, по какой то причине в таблице restoredVATLogTransOper пустой inventTransId