v7: открыть форму документа #654813

Я програмно создал новый документ и заполнил его. Могу ли вывести его на экран не записав перед этим.

В семёрке - нет или махинации с открытием формы и сохранением или сохранение и только потом открытие.

Сохранять нежелательно, пока пользователь глазами не увидит. А что за махинаци???

порватый баян...

Самое простое - открываешь форму нового документа и в параметре передаёшь таблицу значений для заполнения документа данными.

Я все детство занимался игрой на баяне, и ни на одной кнопке про открытие несохраненного документа не было написано. Баян это страшная штука, уж поверь мне. Даже порванный.

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

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

Ну да, но тогда и в открываемом документе в модуле придется  изменять приоткрытии или писать ввод на основании. А это двойная работа.

Таквоттож. Я и думал, раз номер есть, значит и открыть можно.

Автор, нахрена открывать заполненный документ? что там, В ЗАПОЛНЕННОМ документе юзверь увидеть и проверить должен? или ты НЕ ЗНАЕШЬ какими данными ПРАВИЛЬНО заполнять программный док..? Знаешь - заполни, запиши, открой - пусть делают что хотят после того как ты ПРАВИЛЬНО заполнил документ. Не знаешь - нефиг заполнять! Открой форму нового документа - пусть сами заполняют

Он просто в восьмёрке привык, что там можно сделать сначала СоздатьОбъект, а потом ПолучитьФорму.Открыть и откроется форма незаписанного документа. В семёрке модуля объекта, как такового, просто нет - есть модуль документа, но он работает только при проведении, а также модуль формы, который работает, когда форма открыта.

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

Клиент хочет видеть документ, перед тем как его записать. Это часть ТЗ и за выполнение работы, он платит деньги, он не хочет смотреть правильные данные или нет в каком то эфемерном отчете, он хочет открыть заполненную реализацию, пересчитать сумму в разных типах цен и если все ОК записать(реальный пример, слава яйцам 8ка, обошлось без гемора). Ему какой довод привести?

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

В восьмёрке внутренний идентификатор присваивается документу при его рождении, то есть запись никак на расходование Ид (а там же GUID) никак не влияет. Поэтому, никаких проблем с работой с документом нет - мы даже можем дать на него ссылку, чтобы присвоить другому документу. В семёрке Ид документа формируется по таблице и он единый для всех - присваивается в момент записи в базу данных посему до записи документа в базу он как бы не существует.

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

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

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

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

ну про то и речь... я бы немного уточнил твою мысль: "..НУЖНО ПЫТАТЬСЯ ВЫЯСНИТЬ у заказчика, что ему нужно". . заказчику зачастую начинают описывать нужные ПО ИХ ПРЕДСТАВЛЕНИЯМ инструменты/методы.. гвозди, молоток... получают гвозди.. молоток.. и только потом выясняется что надо две железные рельсы скрепить...

хз.. сие покрыто мраком как правило ;-) по моим наблюдениям - это следствие изначально неправильной постановки работы/учета или же недостаточности ресурсов на такую постановку... возможно, такакй тупой обезъяний процесс вполне себе оправдан где-то... на неключевых участках... Спустя неделю/месяц поянть почему данные разложен так а не иначе - фиг проссышь... ВРОДЕ правильно - ну и зашибись...

Основная проблема в том, что на уровне 1С (да и многих других программ) не получается сделать все данные в одной системе с разделением по участкам, чтобы каждая часть программы работала только со своими данными. Тогда необходимости переноса данных, как и попытка слепить из данных одной системы, необходимые в другой - отпадают. В случае переноса - посмотреть документ никак не мешает, но самое главное - продумать вопрос синхронизации номеров, чтобы при повторном переносе открывался заполненный в прошлый раз документ, а не новый - иначе - получается граната для обезьяны.

ух, переносы и обмены жуть как не люблю. У меня вот по истечении двух лет выяснилось что требуется некая определенная инфа, а получить ее влегкую - неготкуда.. бо не планировалось/не думалось/давайдавай... вот и маюсь сейчас склеивая часть инфы из торг с частью инфы из бух. главное чтобы это никто из других 1Сников не видел ;-) распнут/засмеют...

Знаешьв чем заморочка, товар приходуется по строчкам 190 кг* 2,17  + .... и в итоге получается конкретная сумма. А в накладной поставщика написано что 800 кг * 3р = 2401 рубль. И хоть ты его убей. Он говорит что 2 х 2 = 4.1. Поэтому приходится сворачивать все одинаковые строчки и делать новый документ. И там уже корректировать сумму на сумму по накладной. А может так получиться что и пользователь в основном документе где в кол-ве ошибся и что, каждый раз удалять вновь созданный документ?

Так что проверять документ перед записью всегда надо.  И это не прихоть пользователя. Получается что переданный параметр в открывающуюся форму единственное решени. Ввод на основании тоже не пашет пока основной документ не записан.

абсолютно тривиальная задача, в чем проблема подтянуть накладную поставщика из файла обмена, загрузить по данным поставщика и в протокол выдать строки где расхождения по типу: поставщик: 800*3 = 2401, по математике=2400, невязка = 1, этот загруженный документ сравнить С ФАКТОМ приемки (приемку делай хоть одну позицию на 20 строк ОТДЕЛЬНЫМ СООТВЕТСУЮЩИМ ДОКОМ или как-то иначе) и выдавать проткоол фактической приемки. . хотя, вообщем, похрен. Ибо из изложеняи задачи все равно неясны все тонкости. Но итог один: чем меньше будут чего-тотам вбивать ручками ВМЕСТО ПОСТАВЩИКА - тем больше ошибок и "ненужной" работы... как-то так.

Накладная поставщика действительно находится в файле, только не обмена а целофановом на столе у кладовщика. И пользователю тоже не улыбается два раза одно и тоже заносить. Действительно риск ошибиться повышается. Но пока поставщик не начнет писать в накладной 2 х2 =4, другого пути пока не видно. Но это все лирика. Спасибо за совет.

В семерке делается тоже самое :)

Просто они считают: Цена * Количество = Сумма А поставщик: Сумма / Количество = Цена Вот и весь секрет :)

+ Еще там же автоматически включается само НДС, но может и не включаться... Это как с поставщиком договорится клиент :)

Бессмысленный путь... но ты страдай, только через страдание приходит опыт :)

начать транзакцию

С 50-тью пользователями, не самый гуманный путь :)

+  А если он после еще нажмет "Сохранить"? Что будет?

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

так ты ничего и не понял...

Как вариант: Заполнить форму Обработки и по кнопке перенсти в документ.....

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

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

Да, действительно, без формекса не работает... Не знал.

Ты не линуксоидмаковод случаем? Их симптомы из разряда: - В вашей системе реализован протокол X? - Нет. Протокол X не нужен. По крайней мере мне ни разу не понадобился. Вопрос здесь не в том, какой функционал повесили на документ, вопрос в том, что заказчику удобнее работать в форме документа. Если с реализацией пример тебе не нравится(там действительно должны быть точные цифры), давай возьмем формирование заказа. очень часто это процесс творческий(за исключением очень больших объемов, когда не автоматизировать это невозможно), в середине которого, человек может посмотреть - как то мало получается, не буду оформлять, сделаю чуть позже когда заказ будет побольше. - Маловато товара на складе у поставщика, не буду оформлять, опять половина не приедет. Ну и тд, ситуации бывают разные. Или просто бросить на середине, потому что передумал. Или отказаться от записи по каким то еще причинам.