Не получается сумма по полю подчиненной таблицы

Статус
Новые ответы в этой теме размещать нельзя.

Рустам

Продвинутый
#2
Почему так происходит.
Почему-то начало вдруг считать.
Причем выборочьно.
А я уже думал, что в формуле накосячил - 100 раз проверил.
 

Вложения

  • 81.4 KB Просмотры: 55

Рустам

Продвинутый
#3
Странно.
В каждом предыдущем поле значение вычисляется только тогда, когда я введу последующее.
Баг?
 

Рустам

Продвинутый
#4
Видимо не обновилось, так как я создал поле после.
Но и кнопки обновить тоже нет, пришлос вручную тыкать каждую и нажимать СОХРАНИТЬ.
Благо 12 записей.
 

Vladimir

Администратор
Команда форума
#5
Суммирование данных из дочерних объектов производится только в самой форме связи.
Если запись добавлена в дочернем объекте формы связи, но затем изменялась вне данной формы, или запись в объект была добавлена с установкой ссылки на родительский объект формы, то это никак не повлияет на результирующих итог в форме связи.

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

Рустам

Продвинутый
#6
Это плохо. Вот этот момент достаточно критичный.
Вот представьте ситуацию ФинМенеджер провел 5-6 платежей, и они не обновились, или он забыл парочку обновить.
И начинается потом паника по поводу расхождения сумм и чехарда с их поиском
ВАСЯ ПРОВЕРЬ, ДАЙ-КА СЧЕТА ПОСМОТРЕТЬ, ДА МОЖЕТ БУХГАЛТЕР ЧЕ ПЕРЕПУТАЛ,
ПОИЩИ СЧЕТ НА ПОЧТЕ, ЗАПРОСИ СЧЕТ ЕЩЕ РАЗ.

Просто когда люди работают в программе, они априори считают,
что программа не может считать неверно, или не обновляет данные сразу же.
А что я скажу ФинМенеджеру? ВАСЯ, ТЫ КОГДА В ПРОГРАММЕ ВВЕЛ ПЛАТЕЖ,
ЕЩЕ ДОПОЛНИТЕЛЬНО ЕГО ОТКРОЙ В СЧЕТАХ И НАЖМИ СОХРАНИТЬ,
ИНАЧЕ ОН НЕ ПЕРЕСЧИТАЕТСЯ. А ЗАБУДЕШЬ - ПОПАДЕШЬ НА ШТРАФ.
Менеджеры будут проклинать эту программу в мыслях.

На мой взгляд, вам стоит обратить внимание на этот момент.
Уверен, также как и я - думают многие руководители, если не все.
Они будут ожидать, что при изменении суммы в ПЛАТЕЖИ,
изменится и их сумма в связанной таблицы СЧЕТА.
А этого не произойдет. Их ожидания будут обмануты.
ЭТО - ПРИНЦИПИАЛЬНЫЙ МОМЕНТ!
 

Vladimir

Администратор
Команда форума
#7
В будущем возможность обновления данных в родительском объекте мы сделаем.
А сейчас, чтобы не возникало подобных проблем, рекомендуем делать так:
- доступ к созданию и редактированию данных дочернего объекта сохраняется в форме связи;
- если к объекту, который используется в качестве дочернего, предоставляется прямой доступ, то его лучше скрыть, а на его базе создать форму, в которой управление записями заблокировано.
Для формы дочернего объекта можно сделать переход по системной ссылке к форме связи, в записи которой присутствуют записи данного дочернего объекта, где и будет производится изменение данных.
В этом случае никаких проблем возникать не будет.

Кроме того, разрешать пользователям менять суммы платежей - очень плохая практика. Желательно предоставлять право управления финансовой информацией исключительно ограниченному кругу лиц.

Для отслеживания выполненных операций пользователями программы в менеджере служит вкладка "Журнал", в которой сохраняется информация по всем действиям сотрудников с данными:
- время входа/выхода;
- создание/изменение/удаление записей в объекте;
- сформированные документы.
В 6-ой версии планируется добавить механизм, когда изменение данных одного объекта будет вызывать автоматическую запись информации о совершённых операциях в другом объекте, что позволит дополнительно к возможностям контроля операций в менеджере вести лог всех операций, совершённых в базе данных.
 

Рустам

Продвинутый
#8
Пользователям и не будем давать менять суммы платежей.
Их будет менять финдир и директор - всё.
Дело вовсе не в этом. Дело в том, что цифры прыгают.
Например, вот, прилагаю рисунок.

Цифры прыгают, когда я че-то меняю, что с этими цифрами не связано.

Мне кажется, что вы меня не понимаете. Жаль далеко вы,
а то бы приехал в офис - показал проблему вживую ((
Тут хоть что делай в программе, а если такие косяки есть -
пользоваться ею - большой риск. 6-я версия выйдет нескоро,
вся надежда только на исправление, которое должно выйти на этой неделе.
Ждем.
 

Вложения

  • 123.7 KB Просмотры: 54
Последнее редактирование модератором:

Vladimir

Администратор
Команда форума
#9
Изучили тот пример проекта, которые Вы прислали последним.
В объекте "Платежи", для поля "Оплата-Предоплата" задана формула:
[String(Вид счета.Вид счета=Предоплата?Счет №1.Предоплата:Счет №1.Долг)]

1) Поля "Вид счета", которое получает данные из какого-либо объекта и его поля "Вид счета", в данном объекте нет.
Расчёт функции уже невозможен.

2) Производится попытка получить данные из системного поля "Счет №1".
Такого поля в объекте нет - поэтому расчёт функции опять невозможен.

3) Если исправить имя поля "Счет №1" на существующее имя системной ссылки на объект "Счет 1", то в объекте "Счета", на которое ссылается это поле, отсутствует поле "Предоплата" (но есть поле "Предопл").

4) Даже если исправить все указанные выше ошибки - нельзя использовать суммирующие данные из родительского объекта, которые получаются на основе добавляемых/изменяемых данных тех же самых дочерних записей. Какую бы мы последовательность обработки в программе не сделали: 1) вычислять значение суммы из дочерних объектов, а потом их использовать в дочернем списке, или 2) сначала сохранять данные в дочернем списке, а потом суммировать в родительском объекте - в любом случае результат будет некорректным или в записи дочернего списка, или в записи родительского объекта.

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

Рустам

Продвинутый
#10
Не не неее, вы посмотрели старый вариант, видать.
Я заметил эти ошибки и исправил их давно и высылал файл уже корректный.
Все равно все осталось по-прежнему.

Насчет последних слов я не понял:
я что, не могу суммировать значения вычислямых полей?
Почему тогда ТО получается, а ТО - НЕТ?
Не понимаю.
 

Вложения

Vladimir

Администратор
Команда форума
#11
Распишите, пожалуйста, логику расчёта и все поля, участвующие в алгоритме.
Также нужно описание последовательности действий, приводящих к результату, который считается ошибочным.
 

Рустам

Продвинутый
#12
Вот - логика расчета.
К сожалению, ни эксель-файл ни архив прикреплять нельзя, поэтому картинками вышлю.
 

Вложения

  • 58.8 KB Просмотры: 60
  • 65.8 KB Просмотры: 57
  • 45.7 KB Просмотры: 55

Рустам

Продвинутый
#13
Последовательность действий я скидывал картинки.
Если не разберетесь - скажите - пришлю снова.
 

Vladimir

Администратор
Команда форума
#14
Извиняюсь за недостаточно корректную просьбу - нужна логика расчёта участвующая в алгоритме, приводящем к предполагаемой ошибке, и все участвующие в этом поля.
Нам нужен максимально сокращённый проект, в котором надо оставить только то, что может повлиять на возникновение проблемы.
И точное описание шагов, которые приводят к ошибке.
Пример: открываю форму ..., меняю значение ...; при сохранении в поле ... получаю такой-то результат, хотя ожидался такой-то результат.

Поймите: вникать в логику проекта - отнимает много времени, которого не так много.
 

Рустам

Продвинутый
#15
Владимир, знаете как сделаем?
Сейчас обновление у вас должно было выйти.
Я начну заново создавать с нуля БД и все шаги буду фиксировать.
Тот шаг, на котором возникла ошибка - буду сразу вам говорить.

Кстати, по обновлению.
Мне программу заново скачать или само автоматом обновится или как?
 

Vladimir

Администратор
Команда форума
#16
Наталья собиралась найти ошибку, связанную именно с Вашим проектом. Потому и отложили обновление, что так и не выяснили, в чём же баг.

Мне программу заново скачать или само автоматом обновится или как?
Нет, программа сама не обновляется. Мы не считаем хорошим тоном обновлять программу автоматически. Это должен делать сам пользователь, сам для себя решая - необходимо ли это.
Вторая причина - выход новых версий, в которых происходит изменение структуры данных. Её обновление производится только при импорте проекта из архива .rpr, когда программа проверяет, в какой версии конструктора был создан архив.
Такое принудительное совершение архива проекта при смене версий служит также и для того, чтобы если в обновлении обнаружится ошибка в программе - всегда была бы старая версия программы с архивом для быстрого возврата.
 
Статус
Новые ответы в этой теме размещать нельзя.