Как удобнее (правильнее) обрабатывать строки формы?

[yd_]

Здравствуйте!
Идея следующая: вследствие отсутствия лицензии на заказы поставщикам и товары, делаю упрощенное подобие заказа. Создал табличку, форму к ней и т.д. Процедура частичного учета моего заказа будет состоять в том, чтобы исходя из значений определенных полей создать строки фин. журнала, отражающие оплату по данному заказу или оприходование товара на склад. Заказ будет представлять из строку в табличной форме, соответствующую записи соответствующей таблицы. Некоторые заказы будут закрытыми, т.е. по ним вся сумма оплачена, другие будут "чистыми", т.е. по ним никаких движений, ни оприходований, ни оплат, пока не делалось, и т.д. Вопрос в том, что лучше сделать по кнопке "Учет": выбирать все записи согласно текущим фильтрам и по очереди смотреть заполнены ли соответствующие поля в заказе, и, если заполнены, создавать соответствующие оплаты и отгрузки, или же брать текущую запись (на которой стоит курсор) и учитывать её? Кстати, существует ли такое понятие, как текущая запись, и можно ли получить к ней доступ?

Заранее спасибо.

[asacom_imported]

Цитата:

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

Здравствуйте!
Вопрос в том, что лучше сделать по кнопке "Учет": выбирать все записи согласно текущим фильтрам и по очереди смотреть заполнены ли соответствующие поля в заказе, и, если заполнены, создавать соответствующие оплаты и отгрузки, или же брать текущую запись (на которой стоит курсор) и учитывать её? Кстати, существует ли такое понятие, как текущая запись, и можно ли получить к ней доступ?

Заранее спасибо.

<{POST_SNAPBACK}>

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

[yd_]

Результаты, действительно, могут быть "интересными", но какая Вам, собственно, разница - отвечать за них так или иначе придется мне, а не Вам. При возникновении необходимости до документации я доберусь. Сейчас мне нужно всего лишь решение - как с Вашей точки зрения будет удобнее - учитывать как это сделано в финансовом журнале, или же всё таки текущую строку.

[mazzy]

Цитата:

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

но какая Вам, собственно, разница - отвечать за них так или иначе придется мне, а не Вам.

<{POST_SNAPBACK}>

?!
Отвечайте.

[asacom_imported]

Цитата:

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

как с Вашей точки зрения будет удобнее

<{POST_SNAPBACK}>

Лично с моей точки зрения удобнее работать со стандартным функционалом, зная его особенности и возможности!
Если он не устраивает, то стоит задуматься, а на той ли системе построен учет?!

[asacom_imported]

И еще. Я никогда не буду советовать самоубийце, каким способом ему лезть в петлю, даже если мне эти способы известны!

[Wizard_imported]

Сначала надо бы почитать Application Developer Guide и Solution Development.
а потом правильным представляется:
1. Сделать функцию (юнит) учета одной строки таблицы.
2. Сделать пакетное задание для учета нескольких строк.
3. На форме вывести обе функции - учет строки и вызов пакетника, в который передать фильтры таблицы и, возможно, запросить дополнительные параметры.

[yd_]

1. Где обычно размещен на диске дистрибутива Solution Development? Или, хотя бы, как он называется (по аналогии файл Application Developer Guide называется w1w1adg.pdf, что находится в директории Doc\W1 дистрибутива)?
2. В чем, собсно, "самоубийство", я не совсем понимаю. Всё что я хочу делать, это по нажатию на некоторую кнопку создавать несколько записей финансового журнала. НЕ УЧИТЫВАЯ ИХ. Когда создаются эти записи фин. журнала, в заказе изменяются значения специальных полей. И всё. По хорошему, конечно, нужно бы сделать в обратную сторону, т.е. при удалении соответствующих строк фин. журнала в нужном заказе значения специальных полей должны возвращаться в исходное положение... Может эти строки фин. журнала сразу и учитывать?..

Напрягает, то, что в конечном итоге, если я пойду по правильному пути, то с 90-процентной вероятностью я повторю функционал стандартного заказа. Зато опыт будет...

[rov_imported]

Цитата:

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

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

<{POST_SNAPBACK}>

Всецело поддерживаю.

Но наверное все равно отвечу, раз дело не идет об УЧЕТЕ.
Если я правильно понял, то создается аналог заказа покупки - в нем заполняются определенные поля и далее по определенной логике они переносятся в фин. журнал?

Если так, то: Ваша модель так же будет состоять из заголовка и линий
к нему? Если да, то кнопка Учет ессно должна обрабатывать все линии выбранного заказа на основании как вы правильно сказали фильтров и чего-то там ещё. Если нет(то есть у вас будут только линии ) - то логично, что
кнопка Учет обрабатывает только текущую линию.

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

[Wizard_imported]

Цитата:

Где обычно размещен на диске дистрибутива Solution Development?

не знаю, не нашел в 3.60.. Это из 3.10, а в 3.01 назывался просто Development, экзамен по нему кажется принимали.
PS. Народы, на мой взгляд, вы напрасно взъелись на человека... Нету гранул.. ну нету.. А хоть бы и были... Сделать собственными руками документы и процедуры для их учета - это упражнение для начинающих, никакой сложности тут нет. Это, кстати весьма полезное умение. А то понаделают на 83 таблице панимаишь.... и в приложение понавтыкают... сори.

[yd_]

To Wizard: Спасибо за поддержку! Собсно мне, человеку крайне начинающему, и то непонятно какой криминал в том, что я собираюсь сделать. Также огрооомное спасибо за Solution Development.