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

[Logger]

Добрый день.
При работе лукапа в строках используется запрос
custVendInvoiceTrans::queryCorrectedTrans_RU()

В нем есть условие по SalesParmLine и SalesParmTable c фильтром по статусу - ParmJobStatus::Waiting

Разработчики, подскажите, какой смысл у этого фильтра ?
Это защита от того чтобы одновременно не сделать с разных рабочих мест одну и ту же корректировку ?

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

[Jabberwocky]

Цитата:

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

Добрый день.
При работе лукапа в строках используется запрос
custVendInvoiceTrans::queryCorrectedTrans_RU()

В нем есть условие по SalesParmLine и SalesParmTable c фильтром по статусу - ParmJobStatus::Waiting

Разработчики, подскажите, какой смысл у этого фильтра ?
Это защита от того чтобы одновременно не сделать с разных рабочих мест одну и ту же корректировку ?

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

Записи в SalesParmLine со статусом ParmJobStatus::Waiting при отмене обработки очищаются, поэтому при повторном заходе в форму обработки соответствующие строки накладных доступны для выбора из лукапа (см. \Classes\SalesFormLetter\cleanupDialog и далее по стеку вызовов). Данный фильтр решает несколько иную проблему - при возникновении ошибки при обработке в SalesParmLine остаются записи со статусом ParmJobStatus::ContainErrors, но этот фильтр как раз позволяет выбрать такие записи повторно, без очистки SalesParmLine. Уточните пожалуйста действия, после которых такие записи остаются заблокированными.

[Daiver]

Заказы на продажу. Создали кредит-ноту штатными средствами. При обработке Накладной на закладке Дополнительно ставим галку Корректирующий документ. Аксапта подвисает на долго
Стал разбираться, дошел SalesParmLine::initCorrectedInvoiceLines_RU() от туда вызывается CustVendInvoiceTrans::queryCorrectedTrans_RU() для формирования query.
Получаем такой запрос:

SELECT FIRSTFAST * FROM CustInvoiceTrans 
	WHERE ((ItemId = N'item1')) AND ((SalesUnit = N'шт')) AND ((TaxGroup = N'НДС')) AND ((TaxItemGroup = N'18')) 
NOTEXISTS JOIN FIRSTFAST * FROM CustInvoiceTrans 
	WHERE CustInvoiceTrans.RecId = CustInvoiceTrans.RefAdjustedInvoiceTrans_RU 
NOTEXISTS JOIN FIRSTFAST * FROM SalesParmLine 
	WHERE CustInvoiceTrans.RecId = SalesParmLine.RefAdjustedInvoiceTrans_RU 
EXISTS JOIN FIRSTFAST * FROM SalesParmTable 
	WHERE SalesParmLine.ParmId = SalesParmTable.ParmId AND SalesParmLine.TableRefId = SalesParmTable.TableRefId AND ((ParmJobStatus = 2)) 
EXISTS JOIN FIRSTFAST * FROM CustInvoiceJour 
	WHERE CustInvoiceTrans.SalesId = CustInvoiceJour.SalesId AND
 CustInvoiceTrans.InvoiceId = CustInvoiceJour.InvoiceId AND CustInvoiceTrans.InvoiceDate = CustInvoiceJour.InvoiceDate AND
	CustInvoiceTrans.numberSequenceGroup = CustInvoiceJour.numberSequenceGroup 
AND ((CurrencyCode = N'RUR')) AND ((RefOriginalInvoice_RU = 5637447983)) 
EXISTS JOIN FIRSTFAST * FROM InventDim 
	WHERE CustInvoiceTrans.InventDimId = InventDim.inventDimId AND ((configId = ' ')) AND ((InventSizeId = ' ')) AND ((InventColorId = ' '))

У всех быстро отрабатывает данный запрос? Может кто-то сталкивался с этой проблемой?