Не получается сумма по полю подчиненной таблицы
- Автор темы Рустам
- Дата начала
- Статус
Суммирование данных из дочерних объектов производится только в самой форме связи.
Если запись добавлена в дочернем объекте формы связи, но затем изменялась вне данной формы, или запись в объект была добавлена с установкой ссылки на родительский объект формы, то это никак не повлияет на результирующих итог в форме связи.
Понимаем, что это не очень удобно, но пока изменить данный механизм не представляется возможным.
Если запись добавлена в дочернем объекте формы связи, но затем изменялась вне данной формы, или запись в объект была добавлена с установкой ссылки на родительский объект формы, то это никак не повлияет на результирующих итог в форме связи.
Понимаем, что это не очень удобно, но пока изменить данный механизм не представляется возможным.
Это плохо. Вот этот момент достаточно критичный.
Вот представьте ситуацию ФинМенеджер провел 5-6 платежей, и они не обновились, или он забыл парочку обновить.
И начинается потом паника по поводу расхождения сумм и чехарда с их поиском
ВАСЯ ПРОВЕРЬ, ДАЙ-КА СЧЕТА ПОСМОТРЕТЬ, ДА МОЖЕТ БУХГАЛТЕР ЧЕ ПЕРЕПУТАЛ,
ПОИЩИ СЧЕТ НА ПОЧТЕ, ЗАПРОСИ СЧЕТ ЕЩЕ РАЗ.
Просто когда люди работают в программе, они априори считают,
что программа не может считать неверно, или не обновляет данные сразу же.
А что я скажу ФинМенеджеру? ВАСЯ, ТЫ КОГДА В ПРОГРАММЕ ВВЕЛ ПЛАТЕЖ,
ЕЩЕ ДОПОЛНИТЕЛЬНО ЕГО ОТКРОЙ В СЧЕТАХ И НАЖМИ СОХРАНИТЬ,
ИНАЧЕ ОН НЕ ПЕРЕСЧИТАЕТСЯ. А ЗАБУДЕШЬ - ПОПАДЕШЬ НА ШТРАФ.
Менеджеры будут проклинать эту программу в мыслях.
На мой взгляд, вам стоит обратить внимание на этот момент.
Уверен, также как и я - думают многие руководители, если не все.
Они будут ожидать, что при изменении суммы в ПЛАТЕЖИ,
изменится и их сумма в связанной таблицы СЧЕТА.
А этого не произойдет. Их ожидания будут обмануты.
ЭТО - ПРИНЦИПИАЛЬНЫЙ МОМЕНТ!
Вот представьте ситуацию ФинМенеджер провел 5-6 платежей, и они не обновились, или он забыл парочку обновить.
И начинается потом паника по поводу расхождения сумм и чехарда с их поиском
ВАСЯ ПРОВЕРЬ, ДАЙ-КА СЧЕТА ПОСМОТРЕТЬ, ДА МОЖЕТ БУХГАЛТЕР ЧЕ ПЕРЕПУТАЛ,
ПОИЩИ СЧЕТ НА ПОЧТЕ, ЗАПРОСИ СЧЕТ ЕЩЕ РАЗ.
Просто когда люди работают в программе, они априори считают,
что программа не может считать неверно, или не обновляет данные сразу же.
А что я скажу ФинМенеджеру? ВАСЯ, ТЫ КОГДА В ПРОГРАММЕ ВВЕЛ ПЛАТЕЖ,
ЕЩЕ ДОПОЛНИТЕЛЬНО ЕГО ОТКРОЙ В СЧЕТАХ И НАЖМИ СОХРАНИТЬ,
ИНАЧЕ ОН НЕ ПЕРЕСЧИТАЕТСЯ. А ЗАБУДЕШЬ - ПОПАДЕШЬ НА ШТРАФ.
Менеджеры будут проклинать эту программу в мыслях.
На мой взгляд, вам стоит обратить внимание на этот момент.
Уверен, также как и я - думают многие руководители, если не все.
Они будут ожидать, что при изменении суммы в ПЛАТЕЖИ,
изменится и их сумма в связанной таблицы СЧЕТА.
А этого не произойдет. Их ожидания будут обмануты.
ЭТО - ПРИНЦИПИАЛЬНЫЙ МОМЕНТ!
В будущем возможность обновления данных в родительском объекте мы сделаем.
А сейчас, чтобы не возникало подобных проблем, рекомендуем делать так:
- доступ к созданию и редактированию данных дочернего объекта сохраняется в форме связи;
- если к объекту, который используется в качестве дочернего, предоставляется прямой доступ, то его лучше скрыть, а на его базе создать форму, в которой управление записями заблокировано.
Для формы дочернего объекта можно сделать переход по системной ссылке к форме связи, в записи которой присутствуют записи данного дочернего объекта, где и будет производится изменение данных.
В этом случае никаких проблем возникать не будет.
Кроме того, разрешать пользователям менять суммы платежей - очень плохая практика. Желательно предоставлять право управления финансовой информацией исключительно ограниченному кругу лиц.
Для отслеживания выполненных операций пользователями программы в менеджере служит вкладка "Журнал", в которой сохраняется информация по всем действиям сотрудников с данными:
- время входа/выхода;
- создание/изменение/удаление записей в объекте;
- сформированные документы.
В 6-ой версии планируется добавить механизм, когда изменение данных одного объекта будет вызывать автоматическую запись информации о совершённых операциях в другом объекте, что позволит дополнительно к возможностям контроля операций в менеджере вести лог всех операций, совершённых в базе данных.
А сейчас, чтобы не возникало подобных проблем, рекомендуем делать так:
- доступ к созданию и редактированию данных дочернего объекта сохраняется в форме связи;
- если к объекту, который используется в качестве дочернего, предоставляется прямой доступ, то его лучше скрыть, а на его базе создать форму, в которой управление записями заблокировано.
Для формы дочернего объекта можно сделать переход по системной ссылке к форме связи, в записи которой присутствуют записи данного дочернего объекта, где и будет производится изменение данных.
В этом случае никаких проблем возникать не будет.
Кроме того, разрешать пользователям менять суммы платежей - очень плохая практика. Желательно предоставлять право управления финансовой информацией исключительно ограниченному кругу лиц.
Для отслеживания выполненных операций пользователями программы в менеджере служит вкладка "Журнал", в которой сохраняется информация по всем действиям сотрудников с данными:
- время входа/выхода;
- создание/изменение/удаление записей в объекте;
- сформированные документы.
В 6-ой версии планируется добавить механизм, когда изменение данных одного объекта будет вызывать автоматическую запись информации о совершённых операциях в другом объекте, что позволит дополнительно к возможностям контроля операций в менеджере вести лог всех операций, совершённых в базе данных.
Пользователям и не будем давать менять суммы платежей.
Их будет менять финдир и директор - всё.
Дело вовсе не в этом. Дело в том, что цифры прыгают.
Например, вот, прилагаю рисунок.
Цифры прыгают, когда я че-то меняю, что с этими цифрами не связано.
Мне кажется, что вы меня не понимаете. Жаль далеко вы,
а то бы приехал в офис - показал проблему вживую ((
Тут хоть что делай в программе, а если такие косяки есть -
пользоваться ею - большой риск. 6-я версия выйдет нескоро,
вся надежда только на исправление, которое должно выйти на этой неделе.
Ждем.
Их будет менять финдир и директор - всё.
Дело вовсе не в этом. Дело в том, что цифры прыгают.
Например, вот, прилагаю рисунок.
Цифры прыгают, когда я че-то меняю, что с этими цифрами не связано.
Мне кажется, что вы меня не понимаете. Жаль далеко вы,
а то бы приехал в офис - показал проблему вживую ((
Тут хоть что делай в программе, а если такие косяки есть -
пользоваться ею - большой риск. 6-я версия выйдет нескоро,
вся надежда только на исправление, которое должно выйти на этой неделе.
Ждем.
Вложения
Последнее редактирование модератором:
Изучили тот пример проекта, которые Вы прислали последним.
В объекте "Платежи", для поля "Оплата-Предоплата" задана формула:
1) Поля "Вид счета", которое получает данные из какого-либо объекта и его поля "Вид счета", в данном объекте нет.
Расчёт функции уже невозможен.
2) Производится попытка получить данные из системного поля "Счет №1".
Такого поля в объекте нет - поэтому расчёт функции опять невозможен.
3) Если исправить имя поля "Счет №1" на существующее имя системной ссылки на объект "Счет 1", то в объекте "Счета", на которое ссылается это поле, отсутствует поле "Предоплата" (но есть поле "Предопл").
4) Даже если исправить все указанные выше ошибки - нельзя использовать суммирующие данные из родительского объекта, которые получаются на основе добавляемых/изменяемых данных тех же самых дочерних записей. Какую бы мы последовательность обработки в программе не сделали: 1) вычислять значение суммы из дочерних объектов, а потом их использовать в дочернем списке, или 2) сначала сохранять данные в дочернем списке, а потом суммировать в родительском объекте - в любом случае результат будет некорректным или в записи дочернего списка, или в записи родительского объекта.
При таком подходе к построению структуры проекта я бы тоже считал, что пользоваться им - большой риск.
В объекте "Платежи", для поля "Оплата-Предоплата" задана формула:
[String(Вид счета.Вид счета=Предоплата?Счет №1.Предоплата:Счет №1.Долг)]1) Поля "Вид счета", которое получает данные из какого-либо объекта и его поля "Вид счета", в данном объекте нет.
Расчёт функции уже невозможен.
2) Производится попытка получить данные из системного поля "Счет №1".
Такого поля в объекте нет - поэтому расчёт функции опять невозможен.
3) Если исправить имя поля "Счет №1" на существующее имя системной ссылки на объект "Счет 1", то в объекте "Счета", на которое ссылается это поле, отсутствует поле "Предоплата" (но есть поле "Предопл").
4) Даже если исправить все указанные выше ошибки - нельзя использовать суммирующие данные из родительского объекта, которые получаются на основе добавляемых/изменяемых данных тех же самых дочерних записей. Какую бы мы последовательность обработки в программе не сделали: 1) вычислять значение суммы из дочерних объектов, а потом их использовать в дочернем списке, или 2) сначала сохранять данные в дочернем списке, а потом суммировать в родительском объекте - в любом случае результат будет некорректным или в записи дочернего списка, или в записи родительского объекта.
Утверждать, что проблемы в нашем конструкторе - крайне преждевременно и опрометчиво, пока Вы не исправите все свои ошибки в логике структуры.
При таком подходе к построению структуры проекта я бы тоже считал, что пользоваться им - большой риск.
Последнее редактирование:
Не не неее, вы посмотрели старый вариант, видать.
Я заметил эти ошибки и исправил их давно и высылал файл уже корректный.
Все равно все осталось по-прежнему.
Насчет последних слов я не понял:
я что, не могу суммировать значения вычислямых полей?
Почему тогда ТО получается, а ТО - НЕТ?
Не понимаю.
Я заметил эти ошибки и исправил их давно и высылал файл уже корректный.
Все равно все осталось по-прежнему.
Насчет последних слов я не понял:
я что, не могу суммировать значения вычислямых полей?
Почему тогда ТО получается, а ТО - НЕТ?
Не понимаю.
Извиняюсь за недостаточно корректную просьбу - нужна логика расчёта участвующая в алгоритме, приводящем к предполагаемой ошибке, и все участвующие в этом поля.
Нам нужен максимально сокращённый проект, в котором надо оставить только то, что может повлиять на возникновение проблемы.
И точное описание шагов, которые приводят к ошибке.
Пример: открываю форму ..., меняю значение ...; при сохранении в поле ... получаю такой-то результат, хотя ожидался такой-то результат.
Поймите: вникать в логику проекта - отнимает много времени, которого не так много.
Нам нужен максимально сокращённый проект, в котором надо оставить только то, что может повлиять на возникновение проблемы.
И точное описание шагов, которые приводят к ошибке.
Пример: открываю форму ..., меняю значение ...; при сохранении в поле ... получаю такой-то результат, хотя ожидался такой-то результат.
Поймите: вникать в логику проекта - отнимает много времени, которого не так много.
Владимир, знаете как сделаем?
Сейчас обновление у вас должно было выйти.
Я начну заново создавать с нуля БД и все шаги буду фиксировать.
Тот шаг, на котором возникла ошибка - буду сразу вам говорить.
Кстати, по обновлению.
Мне программу заново скачать или само автоматом обновится или как?
Сейчас обновление у вас должно было выйти.
Я начну заново создавать с нуля БД и все шаги буду фиксировать.
Тот шаг, на котором возникла ошибка - буду сразу вам говорить.
Кстати, по обновлению.
Мне программу заново скачать или само автоматом обновится или как?
Наталья собиралась найти ошибку, связанную именно с Вашим проектом. Потому и отложили обновление, что так и не выяснили, в чём же баг.
Вторая причина - выход новых версий, в которых происходит изменение структуры данных. Её обновление производится только при импорте проекта из архива .rpr, когда программа проверяет, в какой версии конструктора был создан архив.
Такое принудительное совершение архива проекта при смене версий служит также и для того, чтобы если в обновлении обнаружится ошибка в программе - всегда была бы старая версия программы с архивом для быстрого возврата.
Нет, программа сама не обновляется. Мы не считаем хорошим тоном обновлять программу автоматически. Это должен делать сам пользователь, сам для себя решая - необходимо ли это.
Вторая причина - выход новых версий, в которых происходит изменение структуры данных. Её обновление производится только при импорте проекта из архива .rpr, когда программа проверяет, в какой версии конструктора был создан архив.
Такое принудительное совершение архива проекта при смене версий служит также и для того, чтобы если в обновлении обнаружится ошибка в программе - всегда была бы старая версия программы с архивом для быстрого возврата.
- Статус