Кнопка открытия формы с продолжением

[bbv62]

Дорогие Форумчане!
Изучив данную ветку этого форума решил прибегнуть к Вашей помощи.
Сам познания в программировании получал 35 лет назад на «Наири-К» (язык АП), пользую рекордер в Ёкселе и простейшие задачи мастерами в Акцесс (т.е.=0)
Предполагал что сегодняшняя задача легко (!) решится в LibreBase, но «нарвался».
Цель: создать программу приёма заказов на изделия (Мет. Двери — индпошив).
Суть задачи: 1. «Главная форма» содержит кнопки открытия форм заведения данных по разделам информации (таблицы разные, связанные по коду заказа). Формы — НЕ ПОДЧИНЁННЫЕ!.
2. В этих формах также имеются кнопки такого же алгоритма для выбора вариантов «ветвления» конструкции. Все данные связаны по «Коду заказа».
3. Итогом заполнения является распечатка Договора-спецификации И (!) - получения строки параметров в любом формате (txt, csv, xls xml и пр.), которая на производстве импортируется в базу PLM (порядка 70 параметров).
Стопанул на первом же этапе: кнопка не получается. По отдельности все элементы работают, все вместе нет:
1.  Сохранение записи.
2. «запоминание» значения поля «КодЗаказа»
3. Открытие соответствующей кнопке формы
4. Открытие (создание) в этой форме записи с этим кодом.
Вообще создалось впечатление что я изобретаю велосипед — неужели ни у кого не было такой задачи (нигде никто такого не спрашивал) — видимо решается банальными способами, но ни здесь, ни в литературе такого не нашёл.
Зародыш базы прилагаю. Желанная кнопка в форме «Общие Данные».
Куча закоцаных макросов в базе.

[bbv62]

Да, Libre 5.0, Windows (XP...10)

[JohnSUN]

Добро пожаловать на форум!
Насколько мне изменяет память, в АП было целых 19 команд? И этого хватало на всё...

Чем вызвано это ограничение?

Формы — НЕ ПОДЧИНЁННЫЕ!
...
2. «запоминание» значения поля «КодЗаказа»

[bbv62]

Оп!
Клюнуло!
Можно и развернуть. Все требования и условия составлены ЛИЧНО МНОЙ из полученных (большей частью в этом Форуме) сведений о структуре баз и МОЕГО видения процедуры приёма заказа.
Уверен, что по мере продвижения к цели не меньше двадцати раз поменяю свои изначальные установки.
Должен пояснить, что процесс не так банален как кажется и в течении 6 последних лет руководство фирмы поменяло кажется четырёх ангажированных профессиональных программистов, писавших в "правильных" приложениях на "правильных" языках, но не давших рабочего продукта (хотя всё было красиво). Возможно задачу им ставили невнятно.
Я зашёл с другой стороны. Автоматизировав собственно производство (лазерный раскрой, фрезеровку, раскрой) обнаружил, что 90% ошибок совершаемых на производстве, совершается "моими" парнями при набивании заказа с рукописного заказа. (Собственно не обнаружил, а подтвердил старую истину). Тема вернулась с другой стороны.
Выбрал Свободный Софт по причине достаточности (по задаче) и отсутствию привязки к конкретному "писателю" для правки и развития программы. (9 офисов у фирмы в разных городах*стоимость ProMSO для "сомнительного", с точки зрения хозяина, результата).
Поэтому любые предложения по организации структуры программы только приветствуются (и ожидаются), желательно только наличие минимального количества процедур и функций. Т.е. использовать минимум функционала для его дальнейшего описания и изучения своими сотрудниками без "глубокого погружения" и привлечения сторонних программистов.

[bbv62]

Да, и ещё: как я понимаю - подчинённые формы выводятся "на одном листе" с головной, т.е. на маленьком мониторе (предполагаются нетбуки) работать будет неудобно. Желательно последовательное заполнение форм с последующим закрытием и перехода к другой категории данных.
"запоминание" кода - рудимент прокатки алгоритма в ёкселе.

[JohnSUN]

Оп!
Клюнуло!

Упс... сорвался...

...по мере продвижения к цели не меньше двадцати раз поменяю свои изначальные установки.

Лучше 19 или 21... чётное число в этом случае плохое - означает "вернуться к разбитому корыту истокам"

процесс не так банален как кажется...90% ошибок совершаемых на производстве, совершается "моими" парнями при набивании заказа с рукописного заказа

банально... или кажется?

Выбрал Свободный Софт по причине достаточности (по задаче)...

Логично. Но сразу предупреждаю - "Зародыш базы" так и останется зародышем, пилотным проектом. Для реального производства встроенная HSQLDB не очень-то и годится - работать будет, но геморроя с сопровождением тоже "будет"... Саму базу нужно будет разворачивать в чем-то более продвинутом (но тоже, разумеется, бесплатном). Но это позже, это уже когда структура таблиц и взаимосвязь форм станет понятной.

желательно только наличие минимального количества процедур и функций

А вот тут уж дудки - если главная задача приложения минимизировать операторские ошибки ввода, то обработку валидности каждого из введенных параметров будет выполнять отдельная процедура. И "написать меньше" значит "не выполнить задачу".

Теперь ещё раз уточним задачу приложения.
По устному заказу (телефонному звонку, например) к клиенту выезжает замерщик. Беседует, выясняет хотелки, записывает их в тетрадку, дополняет снятыми размерами... Копия этих каракулей попадает к "моим парням". Ребята переносят информацию в компьютер. Вот в этом месте - максимум ошибок. По внесенным данным распечатывается немного бумажек (собственно договор, счет или квитанция или расписка о получении задатка, спецификация, что-то там ещё), остальная работа с внесенными данными идёт в электронном виде - "строка параметров в любом формате (txt, csv, xls xml и пр.), которая на производстве импортируется в базу PLM (порядка 70 параметров)".
Пока всё верно?

[bbv62]

Похоже, придётся таки, вытаскивать всю процедуру. Сразу скажу - она очень не жёсткая.
Предпочтительней (для фирмы) такой: 1. Звонок в ОФИС "ХОЧУ!".
2. пока на бумажке. Назначается дата и время замера.
3. Визит замерщика: определение вида проёма (пока их 8), места установки (уличная наружная), материал стен, предварительное определение типа двери (беседа с заказчиком), направление открывания, возможность внести и установить цельную конструкцию или необходимость разборной, и пр. и пр.
4. Визит заказчика в офис. Определение "окончательное" типа двери (ТД), выбор замков (зависит от ТД), выбор фурнитуры (зависит и от замков и от ТД, а далее и от отделки, цвета окраски, наличие на складе (для "крутых"), выбор отделки (грунт, окраска, щиты (дерево (5 сортов) или оргалит (6 видов) и пр.) цвета для металла и щитов, эскиз фрезеровки щитов, материал для ламинирования, наличие и эскиз накладной ковки, наличие и вид остекления и т.д. и т.д.
В конце подсчёта выясняется что заказчик превысил свой лимит по деньгам. Самое плохое - если он решит сменить тип двери - всё начинается сначала, вплоть до анализа дверного проёма. Все ограничения по конструкции и комплектации должны быть предусмотрены. "от дурака". И критических дней.
Работа с заказчиком заканчивается определением стоимости и калькуляцией. (Это оставлю на-сладкое). Печать и подписание "Договора-Заказа".
После в договор вписываются чисто технические нюансы установки (сведения замерщика), данные о демонтаже имеющейся двери (хоп, это в калькуляцию входит) и др.
2-й вариант: 1. Заказчик приходит в офис. Всё выбирает, оформляет заказ, назначает замер.
2. Замерщик обнаруживает что всё выбранное для данного места и случая не годится и предлагает другой тип.
3. Заказчик снова в офисе. Весь заказ переигрывается и обсчитывается. Оказывается опять не подошла стоимость (у соседа-то на 15 тыщ дороже! Давай круче. Часто и такое). третий, четвёртый круг.
3-й вариант. Звонит заказчик и сообщает что он знаком с нашей продукцией, проём у него такой-то, отделку, замки и фурнитуру - такие-то, что готовую он сам увезёт и сам установит. с объявленной ценой согласен и завтра заедет отдать аванс.
На каком то этапе возникают сомнения и посылаем замерщика посмотреть место. И он, например, обнаруживает что стены не кирпич (как думал приобретатель жилья), а дерево, обложенное пустотелым кирпичом. обязательны изменения конструкции, а заказ уже у нас в базе PLM!
Короче - вариантов может быть масса.
Суть - ЗАКАЗ ОФОРМЛЯЕТСЯ ПОЛНОСТЬЮ В ОДНОМ ИЗ МНОГИХ ОФИСОВ В 5 ГОРОДАХ. Не всегда квалифицированными менеджерами. А на данный момент мы всё это ещё руками на производстве заносим.

[JohnSUN]

И в какое место этого... э-э-э... процесса должна воткнуться новая программа? И почему именно "база данных"?

[bbv62]

И в какое место этого... э-э-э... процесса

...ведь знает куда ткнуть...
НЕ ЗНАЮ! Год думаю над этой задачей, однозначного решения нет. Щас уж взялсЯ - буду на первый вариант целить. Другое дело  - как редактировать, в большинстве случаев придётся обнулять и заново заводить 2/3 полей. (может есть вариант с параллельным обсчётом оформлением нескольких альтернатив, с последующим присвоением победителю кода заказа?).
Почему база? - опять больной вопрос. На мои предложения создать электронный архив заказа руководство встало на дыбы. Я был обескуражен, когда узнал требования законов по хранению и обработке персональных данных в электронном виде! Защищённый сервер, выделенная линия, VPN и пр.... - овчинка выделки не стоит. Сейчас этот архив представляет собой сборище вторых экземпляров договоров за 25 лет работы. На свою продукцию у нас пожизненный сервис и частенько девчонки на "чердаке" над кузницей ищут договор на дверь поставленную "зимой, то-ли в 99, то-ли 01 году...". И сейчас этот архив то что будет создано должно быть без ФИО и адреса, можно только город. Меня на производстве это устроит, для изготовления, а вот менеджеров... И на кой такой "архив"?
Поэтому "базой" назвал условно, по привычке. Возможно будет только программа для генерации строки параметров и печати договора.

[idro]

Я только начиная изучать BASIC, поэтому маленько не понял в чем проблема. Вам хочется вносить данные одновременно в разные диалоги ?   В поочередные открытие не устраивает ?   

[bbv62]

Нет,  заполнение, как раз, последовательное, но разные группы данных зависят друг от друга и заведённые данные необходимо постоянно обновлять (сохранять).
Собственно в литературе достаточно подробно все описано, только муторно отсеивать необходимое. Плюнул - и начал читать все с начала и подряд. Те вопросы и сомнения которые здесь описал - уже решил.
Было б интересно узнать как другие решают подобные задачи. Но, видимо, тема или слишком банальная, либо тупо описана. Комментариев нет.

[idro]

Если все данные заносятся сразу, то сохраняю в глобальные переменные. А по нажатию финальной кнопки пишутся или Calc или в BASE (зависит от величины проекта). Если данные поступают в час по чайной ложке, то такая "финальная кнопка" на каждом диалоге, или после вода данных в каждом поле.

[bbv62]

Именно в эту сторону и запилил. Вдобавок размер формы (простыня) тоже сильно влияет. Уж очень полей много.

[kompilainenn]

Именно в эту сторону и запилил. Вдобавок размер формы (простыня) тоже сильно влияет. Уж очень полей много.

а там упростить или разбить на несколько таблиц не выйдет? Структура БД - это целая наука

[bbv62]

Кажись в "зародыше", который выложил, так и сделано. Каждая таблица задумана максимум на 10... 12 переменных, связанных по ключу. Для каждой таблицы - своя форма, открываемая из главной или предыдущей формы. Добавятся также формы из запросов (хотя попытаюсь вставить отдельные поля из запроса в "форму-по-таблице".
Лет 10 назад неплохо получалось в Акцесе без усугубления в программировании. Очень не хватает здесь таких инструментов как "подтаблица" и вкладок форм.