LineNum

[Андре]

Добрый день.

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

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

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

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


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

[Wamr]

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

[Андре]

Zitat:

SalesLine.createLine(...)

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

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

Zitat:

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

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

PHP-Code:

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

[Андре]

Zitat:

А метод, действительно, недоступен... видимо, он является неотъемлемой частью 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]

Zitat:

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

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

[novic]

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

[DreamCreator]

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

PHP-Code:

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


[novic]

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

[DreamCreator]

А если так:

[Ваш код]

PHP-Code:

        CopyLine::copyJournalLine(InventJournalTrans,i); 


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

А в методе copyJournalLine

PHP-Code:

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]

Zitat:

Zitat von Starling

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

Zitat:

Zitat von zinius

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

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

[Starling]

Zitat:

Zitat von zinius

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

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

Zitat:

Zitat von 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 округления не было.

Zitat:

Zitat von mazzy

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

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

[Sergey Petrov]

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

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

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

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

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

Zitat:

Zitat von Sergey Petrov

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

Не оно?

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

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

this.forceWrite(true)

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