LineNum

[Андре]

Добрый день.

Есть такие таблицы, как InventJournalTrans, SalesLine. У них есть поле LineNum, которое заполняется по довольно интересному алгоритму.

Возьмем одну таблицу InventJournalTrans, а точнее форму с аналогичным названием. При создании строк lineNum автоматически формируется. А вот где это происходит ???

Беглый поиск по исходному коду ничего не дал. Но зато, на датасоурсе в той же форме InventJournalTrans я нашел свойство counterField = LineNum. И что-то у меня закралось подозрение, что кода формирующего lineNum я не увижу, так как этот код прописан глубоко в ядре, а все чем я могу играться это тот самы counterField.

Это так или нет ? Если я прав, как пользоваться этим counterField ? Если нет, где этот код ?


Заранее благодарю.

[Wamr]

SalesLine.createLine(...)
---- добавлено -------
А чем тебя не устраивает алгоритм создания LineNum?

[Андре]

Цитата:

SalesLine.createLine(...)

Это ты мне даешь рецепт, а не причину

К тому же я работаю с InventJournalTrans, а там нет такого замечательного метода, как createLine().

Цитата:

А чем тебя не устраивает алгоритм создания LineNum?

Задача такая - в коде программы создавать строки журнала.

PHP код:

   // [from IJT.initValue() (frm)]
    inventJournalTrans.initFromInventJournalTable(inventJournalTable);
    inventJournalTrans.journalType = InventJournalType::LossProfit;
    // [from IJT.initValue() (tbl)]
    inventJournalTrans.TransDate = systemdateGet();
    // [from IJT.itemId.modified() (frm)]
    inventJournalTrans.ItemId = '0-0401À';
    inventJournalTrans.ConfigId = '1';
    inventJournalTrans.inventMovement().journalSetItemId(inventDim);
    inventDim.initFromInventTable(inventJournalTrans.inventMovement().inventTable());
    inventJournalTrans.insert(); 


Тут еще много чего не доделано, но основной недостаток - не генерится LineNum.

Можно конечно самому последовательно нумеровать, но я думал найти метод, где это делается и вызывать его из своего кода. Отсюда и вопрос.

Что посоветуете ?

[Wamr]

Мне кажется, можно просто сделать lineNum ++ какой-дь, так как изначальная его идея сохранять порядок строк в форме.
А метод, действительно, недоступен... видимо, он является неотъемлемой частью FormDataSource и связан со свойством CounterField

[Андре]

Цитата:

А метод, действительно, недоступен... видимо, он является неотъемлемой частью FormDataSource и связан со свойством CounterField

ОК. Спасибо. Похоже мои предположения подтверждаются.

[mazzy]

Best Practice http://technet.navision.com/usered/B...ata_source.htm

A CounterField is typically used to ensure that a record inserted in a form is given a line number that corresponds to the actual, sequential position in the form.

For example, if a new line is inserted between lines 3 and 4, the new line is given line number 3,5. This is used for example in the CustWorksh in the standard application.

To achieve this effect the field given as CounterField should be given as index on the database table.

[Андре]

Еще раз спасибо. Подозрения переросли в уверенность.

[Vadik]

Цитата:

This is used for example in the CustWorksh in the standard application

Это что за зверь? Никакого CustWorksh у меня в 25SP5 не наблюдается

[novic]

Так у кого-нить есть ясность по поводу формирования LineNum в InventJournalTrans? Будьте любезны, поделитесь

[DreamCreator]

Я мож чего не понял, но почему бы не воспользоваться простым методом:

PHP код:

inventJournalTrans.LineNum = InventJournalTrans::lastLineNum(journalId) + 1; 


[novic]

Простой метод хорош! но не всегда -)
Этот пост родился из предыдущей темы - http://www.axforum.info/forums/showt...7960#post77960
Если скопировать сначала строку ( без записи) , а после создать новую - при +1 вылетает ошибка, при + 0.5 - через 2 строки ошибка.

[DreamCreator]

А если так:

[Ваш код]

PHP код:

        CopyLine::copyJournalLine(InventJournalTrans,i); 


где i - итератор в приведенном в начале топика http://www.axforum.info/forums/showt...7960#post77960 цикле.

А в методе copyJournalLine

PHP код:

inventJournalTrans.LineNum = InventJournalTrans::lastLineNum(journalId) + _i; 


где _i переданный фактический параметр i.

[AndyD]

Может сделать так?
http://www.axforum.info/forums/showt...7993#post77993

[Paul_ST]

я создавал складские журналы программно и не сталкивался с обсуждаемой проблемой, поскольку использовал: InventJournalTrans.insertFromCode()

[Starling]

Наступил на вот такие грабли:
В DS формы свойство CounterField установлено как LineNum. Строк в документе 760. В результате «хитрого» стечения обстоятельств часть строк получили одинаковый LineNum. Это в свою очередь привело к тому, что при разноске документа, у меня пошли некорректные суммы.
Прогнал job и сделал уникальным LineNum для этого документа, суммы сошлись.
Приложение сильно модифицированное, но что-то мне кажется, что при таких раскладах и в стандарте была бы ошибка.
Кто-то еще сталкивался с такой проблемой?

[zinius]

Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum

[mazzy]

Цитата:

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

часть строк получили одинаковый LineNum.

Цитата:

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

Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum

Скорее всего, LineNum там все-таки разный, но отличается в пятом-шестом-седьмом знаках. Аксапта показывает округленные значения. Но на сравнение все равно влияют все значящие цифры. Скорее всего, причина бага в другом.

[Starling]

Цитата:

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

Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum

Могут. Форма CustFreeInvoice. Таблица CustInvoiceLine. Индекс ParentRecIdIdx AllowDuplicate = Yes. Других индексов нет.

Цитата:

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

Скорее всего, LineNum там все-таки разный, но отличается в пятом-шестом-седьмом знаках. Аксапта показывает округленные значения. Но на сравнение все равно влияют все значящие цифры. Скорее всего, причина бага в другом.

Они были одинаковыми. Вот такой Job

static void Job157(Args _args)
{
    CustInvoiceLine custInvoiceLine;
    ;
    while select count(ReciD) from custInvoiceLine index hint ParentRecIdIdx group by LineNum
        where custInvoiceLine.ParentRecId == 8484848
    {
        if(custInvoiceLine.RecId > 1)
            warning(strFmt("%1", custInvoiceLine.RecId));
    }

}

Выдавал 2, 3, 7, я думаю в данном случае при group by округления не было.

Цитата:

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

Скорее всего, причина бага в другом.

После того как job-ом сделали уникальным LineNum в рамках ParentRecId, проблема исчезла.

[Sergey Petrov]

Коллеги, добрый день! Возможно, кому-то будет интересно. При разборе собственных авгиевых конюшен, столкнулись со следующим эффектом (воспроизводится на DAX2009, в частности):

если в форме с заказами несколько раз создать строки без сохранения данных в БД, то нумерация таких (не сохранённых) строк правильная. Срабатывает свойство CounterField на источнике данных SalesLine.

Далее, начинаем прописывать код номенклатуры и пр. в созданные "болванки", сохраняем строки в БД. При этом видим: номер строки во всех создаваемых строках равен максимальному номеру строки созданного нами массива "болванок". В результате получаем строки с одинаковыми номерами. Причём, уникальный индекс, который содержит SalesLine.LineNum (SalesLineIdx) позволяет такую штуку, поскольку в него входит ещё и RecId.

Может быть, кто-нибудь знает, как этот момент красиво обойти?

[Владимир Максимов]

Цитата:

Сообщение от Sergey Petrov

если в форме с заказами несколько раз создать строки без сохранения данных в БД, то нумерация таких (не сохранённых) строк правильная. Срабатывает свойство CounterField на источнике данных SalesLine.

Не оно?

Запись не сохраняется при переходе на другую в гриде

Т.е. в метод Create() на SalesLine в источнике данных формы в конце после super() добавить команду

this.forceWrite(true)

Правда, тогда невозможно будет делать болванки без сохранения