• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Решено Подчиненные документы...

  • Автор темы JohnLemon
  • Дата начала
J

JohnLemon

Подскажите пожалуйста, как решается в лотусе следующая проблема! Допустим необходимо реализовать списание материалов. Я создаю документ расходная накладная например, далее на форме выбираю материал, количество, цену и т.д нажимаю добавить создается документ "Списание" с unid накладной, материалом, и т.д. Если я не сохраню док "Накладная" документы, которые я добавил останутся и будут лишними. Можно ли как то в лотусе создавать как бы временные документы, что бы потом не удалять их самому. И вообще может кто подскажет как простым способом решаются данные проблемы.
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
1 Инфу для дока "Списание" можно набирать в "Накладную" (как временную, т.е. её не сохранять) и, если она (Накладная) сохраняется - в queryclose создать "Списание", набить ранее подготовленной инфой и сохранить. Будет сохранена пара доков, или не одного.
2 Если делать как у тебя, после сохранения "Списания", записать его UNID в "Накладную" и, если "Накладная" не сохраняется, опять же в queryclose накладной, взять по этому UNID "Списание" и удалить.
3 "Склад" прогится, почти так же как и "Бухгалтерия", т.е. в "расчёт" должны попадать только доки, которые имеют уже сохранённый родитель. В 1С для этого придуман хор. механизм - "проведение": т.е. в док записывается метка "проведён" и он учитывается в расчётах. В твоём случае, можешь делать уже сохранённое "Списание" "проведённым", если "Накладная" (от него) сохраняется (опять же в queryclose). В противном случае он остаётся "не проведённым" (т.е. временным) и не видимым для логики (конечно, если это предусмотрено), и можешь удалить его потом, когда нибудь, напр. агентом.

Такшта, все способы простые.
---------------------
P.S.
... и причём здесь Xpages ;)
 
  • Нравится
Реакции: JohnLemon

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
На закрытие вряд ли получится что-то удалить. Т.к. обычно у пользователей нет прав на удаление.

Мы поступали проще. Основной док все равно сохраняется как черновик. А через н-дней удаляются серверным агентом
 
  • Нравится
Реакции: JohnLemon

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
Да и хранить юнид не надо. Можно и так получить коллекцию респонсов
 
Последнее редактирование модератором:
  • Нравится
Реакции: JohnLemon

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Мы поступали проще. Основной док все равно сохраняется как черновик. А через н-дней удаляются серверным агентом
Эт ващще хороший вариант. Удалять сразу доки - зло, лучше их метить как "удалённые", до "лучших времён"
 
  • Нравится
Реакции: JohnLemon

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
а разве при копировании дока из базы в базу(или онтрЦ контрлВ) он не меняется, и вся иерархия респонзов не теряется?
Меняется. Разрешать юзеру произвольное копирование - тоже зло. Я всё это запрещаю (для сложных баз), в том числе и CtrC\CtrV. Только кодом.
 
  • Нравится
Реакции: JohnLemon

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
а разве при копировании дока из базы в базу(или онтрЦ контрлВ) он не меняется, и вся иерархия респонзов не теряется?
при копировании полной пачки (родитель и респонсы) сразу - связь сохраняется.
НО если механизм копирования рукописный - можно даже юниды сохранить.

Но мы и от этого отказались. После прохождения цикла согласования - респонсы удаляются и данные записываются в RT-поле. И в результате у нас остается один документ
 
  • Нравится
Реакции: JohnLemon

savl

Lotus Team
28.10.2011
2 597
310
BIT
159
Но мы и от этого отказались. После прохождения цикла согласования - респонсы удаляются и данные записываются в RT-поле. И в результате у нас остается один документ
Приколько, но как реализовано для многоуровневых дискуссий?
 
  • Нравится
Реакции: JohnLemon
J

JohnLemon

2 Если делать как у тебя, после сохранения "Списания", записать его UNID в "Накладную" и, если "Накладная" не сохраняется, опять же в queryclose накладной, взять по этому UNID "Списание" и удалить.
Это не вариант, а если закрыли вкладку или браузер доки остаются.
Основной док все равно сохраняется как черновик
Помечается как то в отдельном поле?? или у лотуса можно прям создать как то что бы он понимал что это черновик ?
Почему нельзя построить таблицу с данными а потом из нее сохранять доки ? Неужели проще создавать доки, потом их как то помечать а потом удалять и еще проверять удаляются они или нет ?
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Это не вариант, а если закрыли вкладку или браузер доки остаются.
... А если умер комп?... А если упал сервер?... А если умер юзер... Описано 4 варианта, а не рецепта. На самом деле их немеряно - программирование это искусство.
Надо обеспечить отказоустойчивость - флаг в руки. У нотуса нет встроенного механизма транзакций, ну вот нету, и всё...
или у лотуса можно прям создать как то что бы он понимал что это черновик ?
;) это что? Хочется, чтобы вендор предусмотрел все будущие хотелки и список рецептов на все случаи жизни? А программист для мебели?
Почему нельзя построить таблицу с данными а потом из нее сохранять доки ?
???????? А доки, сохраненные в базе это не уже построенная "таблица"???
 
  • Нравится
Реакции: JohnLemon
J

JohnLemon

???????? А доки, сохраненные в базе это не уже построенная "таблица"???
Доки сохраненные в базе, привязанные к несуществующему доку это мусор а не доки!!!
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
34
Доки сохраненные в базе, привязанные к несуществующему доку это мусор а не доки!!!
Так точно, мусор. Вот и удаляй их автоматом, если они там появились. Это тоже может быть частью логики сохранения нормальной связности цепочек. Асинхронный механизм контроля часто лучше синхронного. Кста, стабы ведь тебя особо не парят? А их может быть немеряно. Каму-то они нужны, кто-то их чистит сам, а кто-то просто не даёт им появляться. Важно только одно: что бы "мусор" не мешал работе - не был виден, где ему не положено.
 
Последнее редактирование модератором:
  • Нравится
Реакции: JohnLemon
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!