не могу присвоить значение полю из триггера

[flov_imported]

В форме продажа заказ вставляю товарные позиции.
При этом если тип диллера пустой, то он должен подтянуться из карточки менеджера.
В таблице Sales Line пишу в конце триггера No.-OnValidate присвоение

       recSalesHeader.RESET;
       recSalesHeader.SETRANGE("No.","Document No.");
       IF recSalesHeader.FINDFIRST THEN BEGIN

          IF recSalesHeader.DealersType = '' THEN BEGIN
             UserSetup.RESET;
             UserSetup.SETRANGE("User ID",UPPERCASE(USERID));
             IF UserSetup.FINDFIRST THEN BEGIN
                recDefaultDimension.RESET;
                recDefaultDimension.SETRANGE("No.",UserSetup."Salesperson Code");
                recDefaultDimension.SETRANGE("Dimension Code",'ÒÈÏ ÄÈËÅÐÀ');
                IF recDefaultDimension.FINDFIRST THEN BEGIN
                   recSalesHeader.VALIDATE(DealersType, recDefaultDimension."Dimension Value Code");
                   recSalesHeader.MODIFY(TRUE); 
                   recDocumentDimension.INIT;
                   recDocumentDimension.RESET;
                   recDocumentDimension."Table ID"               := 37;
                   recDocumentDimension."Document Type"          := recSalesHeader."Document Type";
                   recDocumentDimension."Document No."           := recSalesHeader."No.";
                   recDocumentDimension."Line No."               := 10000;    // это только для 1-й строки, поэтому 1000
                   recDocumentDimension."Dimension Code"         := 'ТИП ДИЛЕРА';
                   recDocumentDimension."Dimension Value Code"   := recDefaultDimension."Dimension Value Code";
                   IF NOT recDocumentDimension.INSERT(TRUE) THEN recDocumentDimension.MODIFY(TRUE);              
                END;
             END;
          END;
       END;

но в таблицу Document Dimension присвоение не происходит, то есть поле код значение измерения остается пустым.
Это происходит только для первой строчки.

Т.к. в таблицу Sales Header тип диллера присваивается( так же присвоение идет в этом же триггере)
Дальше этот тип просто так не удаляется, т.к срабатывает триггер.
Поэтому следующие строки в Sales line уже добавляются по своему алгоритму.
и этой проблемы не возникает. т.е. в таблицу Document Dimension идет присвоение код значение измерения

как сделать присвоение для первой строки?

[IGG]

recDocumentDimension.RESET; после INIT зачем????

[prefreitor]

Лучше всего в данной ситуации воспользоваться отладчиком, посмотреть в нем интересующие значения переменных и полей.
По коду: Желательно использовать уже имеющиеся функции если они есть, это я про GetSalesHeader в Sales Line. Нежелательно вписывать в код константы типа 'ТИП ДИЛЕРА'

[romeo]

Автор, смотри треггера OnInsert(), OnModify() на таблице Document Dimension. Они не пустые и .. вполне могут поменять значение записи перед сохранением. Вполне возможно, что ваш код измерения ТИП ДИЛЕРА для системы ничто.

[.Quattro.]

Проверьте запись в "Default Dimension", которую вы нашли - возможно, что в ней пустое значение.
И при поиске измерения добавьте фильтр на "Table ID", чтобы искать измерения именно по менеджеру.

[apanko]

Мне в голову кой-какие мысли пришли:
1. Вы когда валидейтите номер, запись в этот момент еще не вставлена, т.е. у строки номер 0. Не готов сказать пока на что это вляет.
2. Еще второй момент, который меня волнует это функция CreateDim. Она есть и она довольно агрессивная.
3. Еще меня смущает принудительное указание строки в 10000.

Это мысли насчет программинга. Но есть мысли и о том как решить задачу без него.
Если я правильно понял задачу, то код дилера он связан с заголовком. Так и задавать измерение нужно из заголовка, дальше оно само должно в строки переноситься.
Отсюда мысль - правильно задать измерение для менеджера, а также приоритеты стандартных измерений. В этом случае если у клиента приоритет повыше, то измерение подтянется из него, но если его нет, то из менеджера. Как-то так.

В принципе тоже самое можно сделать и для строк (т.е. товаров).

[rmv]

Цитата:

Написанный код не надо вставить в триггер «No.» табл. 37. Вы должны включить его в подформу (форма 47)в триггер OnAfterValidate поля «No.» и присвоить recDocumentDimension."Line No." := "Line No." (табл. 37)

Есть уверенность что валидэйты только с формы будут?

По сабжу - не множьте простыни кода , все уже написано.
В заголовке настройте и заполняйте исходя из приоритетов измерений (похоже так и есть).
В строках отлично отработает код CreateDim на валидэйте No. и подтянет значение измерения из заголовка,
если есть какие-то проблемы, копайте в сторону функции CreateDim.
Если все таки хочется написать велосипед, помните, что в валидэйт No. может пройти до Insert, соотвественно
номер строки будет нулевым, посему пользуйтесь стандарнтыми функциями кодеюнита DimMgt

[alexb_imported]

Цитата:

"Если все таки хочется написать велосипед, помните, что в валидэйт No. может пройти до Insert, соотвественно
номер строки будет нулевым..."

Если в OnAfterVaildate в "No." прописать CurrForm.UPDATE(TRUE), то номер строки будет заполнен и не надо просваивать какой-то левый номер 10000.
Но это, конечно, иногда чревато (т.к. производится принудительный INSERT), но иногда и необходимо. А в остальном согласен с тем, что заполнение аккуратнее делать из заголовка.

[rmv]

Цитата:

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

Если в OnAfterVaildate в "No." прописать CurrForm.UPDATE(TRUE), то номер строки будет заполнен и не надо просваивать какой-то левый номер 10000.
Но это, конечно, иногда чревато (т.к. производится принудительный INSERT), но иногда и необходимо. А в остальном согласен с тем, что заполнение аккуратнее делать из заголовка.

Привычка писать код бизнес-логики не в таблицах, а на формах (равно как и использование ал-ля 'ДИЛЕР' в коде) рано или поздно приведет к полной утрате контроля за проектом.
Крайне редки задачи, требующие такого подхода.

[alexb_imported]

Цитата:

Привычка писать код бизнес-логики не в таблицах, а на формах (равно как и использование ал-ля 'ДИЛЕР' в коде) рано или поздно приведет к полной утрате контроля за проектом.
Крайне редки задачи, требующие такого подхода.

Обеими руками за! Программирование в формах должно быть абсолютным исключением!

[Sancho]

аналитиков менять не пробовали?

[rmv]

Цитата:

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

Абсолютно не согласна. Очень часто, именно только в формах, приходится писать код бизнес-логики (после согласования со всеми аналитиками).

Несогласны с тем что плохо или с тем что крайне редки задачи?
Предлагаю подумать как весело будет работать если весь родной код Навижна перенести с таблиц на формы (сколько их там для 36 таблицы?)
Впрочем, у каждого свой путь к дао .