|
![]() |
#1 |
Участник
|
Наступил на вот такие грабли:
В DS формы свойство CounterField установлено как LineNum. Строк в документе 760. В результате «хитрого» стечения обстоятельств часть строк получили одинаковый LineNum. Это в свою очередь привело к тому, что при разноске документа, у меня пошли некорректные суммы. Прогнал job и сделал уникальным LineNum для этого документа, суммы сошлись. Приложение сильно модифицированное, но что-то мне кажется, что при таких раскладах и в стандарте была бы ошибка. Кто-то еще сталкивался с такой проблемой? |
|
![]() |
#2 |
Участник
|
Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum
|
|
![]() |
#3 |
Участник
|
Скорее всего, LineNum там все-таки разный, но отличается в пятом-шестом-седьмом знаках. Аксапта показывает округленные значения. Но на сравнение все равно влияют все значящие цифры. Скорее всего, причина бага в другом.
|
|
![]() |
#4 |
Участник
|
Цитата:
Цитата:
X++: 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)); } } После того как job-ом сделали уникальным LineNum в рамках ParentRecId, проблема исчезла. |
|
![]() |
#5 |
Участник
|
Коллеги, добрый день! Возможно, кому-то будет интересно. При разборе собственных авгиевых конюшен, столкнулись со следующим эффектом (воспроизводится на DAX2009, в частности):
если в форме с заказами несколько раз создать строки без сохранения данных в БД, то нумерация таких (не сохранённых) строк правильная. Срабатывает свойство CounterField на источнике данных SalesLine. Далее, начинаем прописывать код номенклатуры и пр. в созданные "болванки", сохраняем строки в БД. При этом видим: номер строки во всех создаваемых строках равен максимальному номеру строки созданного нами массива "болванок". В результате получаем строки с одинаковыми номерами. Причём, уникальный индекс, который содержит SalesLine.LineNum (SalesLineIdx) позволяет такую штуку, поскольку в него входит ещё и RecId. Может быть, кто-нибудь знает, как этот момент красиво обойти?
__________________
MS Dynamics AX 2009 Kernel 5.0.1600.4110 Application 5.0.1500.6491 |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#6 |
Участник
|
Цитата:
Запись не сохраняется при переходе на другую в гриде Т.е. в метод Create() на SalesLine в источнике данных формы в конце после super() добавить команду X++: this.forceWrite(true) Правда, тогда невозможно будет делать болванки без сохранения
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Sergey Petrov (1). |
![]() |
#7 |
Участник
|
Цитата:
![]() Мы решили не очень элегантно, зато достаточно надёжно: инициируем значения в initValue() источника данных. Предварительно делаем контейнер с имеющимися номерами и развлекаемся с этим контейнером. А свойство CounterField у нас вообще пустое.
__________________
MS Dynamics AX 2009 Kernel 5.0.1600.4110 Application 5.0.1500.6491 |
|