Глюк FlowField?

[Lrundom]

Есть документ перемещения, работающий не через приходные/расходные накладные, а просто при отгрузке/получении создаются соответствующие операции в книге операций. а в самом перемещении меняется статус(открыт->отгружен->получен). В строках перемещения есть flowfield-поля "Отгруженное кол-во", "Полученное кол-во", берущие данные из книги операции(поле Quantity).
Было создано перемещение на 15 штук товара. Отгрузили. В книге операции создалась соответствующая операция расхода на 15 штук(Quantity = -15). В самом документе в строке поле "Отгруженное кол-во" стало равно 15, проваливаемся - открывается книга операций - там наша операция расхода. Все отлично.
Но надо было отгрузить не 15, а 10 штук. Потому решаем лишь подкорректировать книгу операций, т.е. в нашей расходной операции меняем значение поля Quantity с -15 на -10. По идее? "Отгруженное кол-во" должно стать равным 10, но когда открываю сам документ перемещения, то вот что я вижу: "Отгруженное кол-во" = 25, а "Полученное кол-во" = 10. Проваливаемся из данных полей в книгу операций и видим правильные данные: при проваливании в "Отгруженное кол-во" отображается одна единственная операция расхода на 10 единиц, а при проваливании в "Полученное кол-во" - пусто.

Ладно удаляю операцию расхода в книге операций и по идее "Отгруженное кол-во" должно стать = 0 , но нет - "Отгруженное кол-во" становится равным 15, "Полученное кол-во" = 15. Проваливаемся в данных полях в книгу операций - везде пусто.

Я никогда не сталкивалась с таким. CalcFormula полей не менялась. Никаких дополнительных операций в книге операций не создалось, кнопка Получить не нажималась, при том, что подобные манипуляции я проделывала уже и все проходило нормально. Почему сейчас данные flowfield-полей отображают совершенно не те данные, на основании которых они калькулируются.

Господа, в чем может быть причина?

[Sancho]

все потому, что кто-то грязными руками в Нав лазиет
попробуйте Файл - База Данных - Информация - Таблицы - Тест, оптимизировать и пр.

[Storkich]

Journal -> Codeunit(22) -> Ledger
Нужно заполнять журнал, и вызывать постинг, а не напрямую писать в 32-ю

[Lrundom]

Цитата:

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

Journal -> Codeunit(22) -> Ledger
Нужно заполнять журнал, и вызывать постинг, а не напрямую писать в 32-ю

32-ая тут совершенно не трогается. Это совершенно другой функционал - все таблицы, формы, книга операций были созданы спец-но для этого функционала, и с функционалом товара не имеет совершено никакой связи. Учет через журнал в данном функционале излишен, т.к. в данном случае нужен учет только лишь кол-ва, без цен и стоимостей.

[prefreitor]

Пересоздать ключ по которому FlowField работает. Сохраняете таблицу (книгу операций) в fob, потом отключаете ключи, компилируете, потом загружаете fob. Если это поможет, то лучше попробовать сменить билд клиента на более новый.
P.S Хотя руками и плохо лазить по учтенным операциям это все равно не освобождает FlowField от обязанности давать верные данные

[Lrundom]

Цитата:

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

Пересоздать ключ по которому FlowField работает. Сохраняете таблицу (книгу операций) в fob, потом отключаете ключи, компилируете, потом загружаете fob. Если это поможет, то лучше попробовать сменить билд клиента на более новый.P.S Хотя руками и плохо лазить по учтенным операциям это все равно не освобождает FlowField от обязанности давать верные данные

Было сделано:
1. Тест всех таблиц. Проблемной оказалась Книга Операций.
2. Пересозданы ключи в Книге Операций, как и подсказал prefreitor.
3. Опять тест таблицы Книга Операций - все ок.

Результат:
flowfield-поля отображают верные данные.Но.. лишь до первого изменения поля Кол-во в Книге Операций, после чего flowfield-поля опять оторажают неверные данные. А тест таблицы выдает ошибку что и ранее: "Таблица Книга Операций имеет противоречивые значения SumIndexField".

[prefreitor]

А вот книгу вы как меняете? Из самого Navision или SQL?

[rmv]

Какая версия клиента Навижна?
Calcformul'у тоже приведите.

[Lrundom]

Цитата:

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

А вот книгу вы как меняете? Из самого Navision или SQL?

Все изменения делаются в навижене.

Цитата:

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

Какая версия клиента Навижна?

клиент 4.0 SP3

У меня вот какой вопрос вдруг возник - возможно ли наличие одного и того же поля и в ключе и в его SumIndexFields?

[rmv]

Цитата:

У меня вот какой вопрос вдруг возник - возможно ли наличие одного и того же поля и в ключе и в его SumIndexFields?

Просил вроде привести Calcformula.
По Вашему вопросу - Да, насколько я знаю Навижн можно поставить в тупик, добавив where Quantity=field(Quantity) к примеру...

[Lrundom]

Цитата:

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

Цитата:

У меня вот какой вопрос вдруг возник - возможно ли наличие одного и того же поля и в ключе и в его SumIndexFields?

Просил вроде привести Calcformula.
По Вашему вопросу - Да, насколько я знаю Навижн можно поставить в тупик, добавив where Quantity=field(Quantity) к примеру...

так после вашей просьбы у меня и возник такой вопрос... потому как в Calcformula содержится Quantity, а именно Quantity = FILTER(<0). Сделано это было потому, что поля Open и Positive - flowfield-поля и соответственно их невозможно добавить в ключ.

Значит даже не прямое сравнивание, а просто наложение фильтра тоже приводит навижн в тупик?

[rmv]

К сожалению, весьма ограничен в фантазиях методологией Навижна, тем не менее попробую помочь
Итак вопросы:
1. Киньте список ключей с сифт-полями из книги операций.
2. Приведите все таки злосчастную Calcformula полностью.
3. Черт черт не шутит - строки перемещений часом не на книге операций сделаны?
4. Приведите текст SQL триггера на книге операций (вроде 4 SP3 SIFT'ы еще на триггерах были).

[Lrundom]

Цитата:

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

К сожалению, весьма ограничен в фантазиях методологией Навижна, тем не менее попробую помочь
Итак вопросы:
1. Киньте список ключей с сифт-полями из книги операций.
2. Приведите все таки злосчастную Calcformula полностью.
3. Черт черт не шутит - строки перемещений часом не на книге операций сделаны?
4. Приведите текст SQL триггера на книге операций (вроде 4 SP3 SIFT'ы еще на триггерах были).

1. Key = "Document No.,No.,Entry Type,Quantity", SumIndexField = Quantity
2. Calcformula = -Sum("Ledger Entry".Quantity WHERE (Document No.=FIELD(Document No.),No.=FIELD(No.),Entry Type=FILTER(Transfer|Negative Adjmt.),Quantity=FILTER(<0)))
3. Нет. Для строк есть своя отдельная таблица, т.е. есть таблицы Header, Line, Ledger Entry.
4. а где мне его посмотреть?

[Sancho]

Цитата:

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

...Сделано это было потому, что поля Open и Positive - flowfield-поля ...

имхо, позитив надо бы сохранять, а не рассчитывать! именно для подобного примера!
больше позитива, короче!

с решением, в котором вычисляемое поле входит в ключ для вычисления, сталкиваюсь первый раз. надеюсь, в последний.
замечание про "грязные руки" отзываю, поскольку был уверен, что меняете именно через SQL. был неправ, простите

[prefreitor]

Думаю, надо еще один опыт поставить: наложите на книгу операций кодом нужные фильтры, т.е (Document No.=FIELD(Document No.),No.=FIELD(No.),Entry Type=FILTER(Transfer|Negative Adjmt.),Quantity=FILTER(<0)и посчитайте calcsums(quantity), думаю результат д.б такой же как и на FlowField. Полагаю вам все таки надо менять билд на более новый, в одном из них были такие проблемы.

[rmv]

Цитата:

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

1. Key = "Document No.,No.,Entry Type,Quantity", SumIndexField = Quantity
2. Calcformula = -Sum("Ledger Entry".Quantity WHERE (Document No.=FIELD(Document No.),No.=FIELD(No.),Entry Type=FILTER(Transfer|Negative Adjmt.),Quantity=FILTER(<0)))
3. Нет. Для строк есть своя отдельная таблица, т.е. есть таблицы Header, Line, Ledger Entry.
4. а где мне его посмотреть?

По пункту 4 - можно нужно смотреть дизайн таблицы в Enterprise Manager или MSSMS не знаю что у вас там.
Вам все же придется перестроить свое решение, и отказаться от использования Quantity в ключе.
Постараюсь объяснить в чем проблема как можно более понятным языком.
Дело в том, что для поддержки SIFT в версии sql до 5.0 Навижн использует доп. таблицы и триггера на таблицах в SIFT полями.
На каждый ключ с с SIFT полями существует своя таблица, состав полей таблицы:
1. bucket - условно говоря уровень агрегации, количество уникальных bucket соотвествует числу галочек, показываемых на форме Sift Level List
2. Набор полей, составляющих ключ. По нему же составлен первичный ключ таблицы. "Document No.,No.,Entry Type,Quantity" в вашем случае
3. Набор полей, содержащий вычисляемые поля. Quantity в вашем случае
Триггер на вставку в это таблицу (расчет сифтов) генерится при редизайне таблицы из Нава. Опуская технические детали, можно сказать что триггер работает с двумя виртуальными таблицами - deleted (удаленные записи), inserted (вставленные записи). C вставкой и удалением записей надеюсь понятно, при модификации таблица deleted содержит запись до изменения, inserted после изменения.
Пока не страшно? Дальше будет веселее.
Опуская некоторые детали в части bucket в общем случае обновление сифтов выглядет как изменение записи если она по составу первичного ключа уже есть в базе, при этом вычисляемые поля считаются "Старое Значение В Базе" - "Значение В Таблице deleted" + "Значение в Таблице Inserted":
1. Навижн обновляет данные в таблицы только если измененились какие либо-из полей, входящие в ключ, либо в состав вычисляемых полей.
2. Навижн пытается проапдейтить запись, выполнив "Старое Значение В Базе" - "Значение В Таблице deleted" для полей PK, если не получилось (записей с такими полями PK нет в базе),
то идет вставка записи поля PK, в значениях вычисляемых полей - (минус) "Значение В Таблице deleted".
3. Навижн пытается проапдейтить запись, выполнив "Старое Значение В Базе" + "Значение В Таблице inserted" для полей PK, если не получилось (записей с такими полями PK нет в базе), то идет вставка записи поля PK, в значениях вычисляемых полей + "Значение В Таблице inserted".

В при смене Quantity с -15 на -10 Навижн ступил и вставил 2 доп. записи вместо обновления одной:
Было:
В сифт таблице запись Док,Но,Negative, -15, -15
Первичный ключ Док,Но,Negative, -15
Вычисляемое поле -15
Стало:
Первичный ключ Док,Но,Negative, -10
Вычисляемое поле -10

Логика похоже следущая:
1. Пытаемся обновить ключ Док,Но,Negative, -10 (здесь уже новое значение!). Не получилось. Вставляем Док,Но,Negative, -10, +15 как вычисляемое поле.
2. Без попытки обновления ключа Док,Но,Negative, -10 или -15 (обе записи есть в базе). Вставляем Док,Но,Negative, -10, -10 как вычисляемое поле.
Все привет Нав. Вместо одной записи в базе теперь три.

Рекомендую пересмотреть архитектуру решения. Boolean поле Open еще с трудом можно оправдать сложностью поддержки (ну иль ленью), то Positive уже вычислить труда совсем не составит.

[Lrundom]

Цитата:

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

Цитата:

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

...Сделано это было потому, что поля Open и Positive - flowfield-поля ...

имхо, позитив надо бы сохранять, а не рассчитывать! именно для подобного примера!
больше позитива, короче!

с решением, в котором вычисляемое поле входит в ключ для вычисления, сталкиваюсь первый раз. надеюсь, в последний.
замечание про "грязные руки" отзываю, поскольку был уверен, что меняете именно через SQL. был неправ, простите

Любой опыт, будь то положительный либо отрицательный - ценный опыт.Так что приму к сведению.


prefreitor спасибо за совет, но я пожалуй пойду более простым путем - изменю код.

rmv триггер нашла, но очень большой.. а что там должно быть, то что вы хотели посмотреть? там есть Update SIFT tables for INSERT statement..

[Lrundom]

rmv, спасибо за столь развернутый ответ.