Всем привет!
Прошу помощи при решении простой(но для меня сложной!) задачи.
Необходимо автоматизировать предприятие, занимающееся реализацией путевок для различных санаториев.
На входе имеем:
-список санаториев(характеризуется простым наименованием)
- у каждого санатория имеются путевки(характеризуются номером путевки)(Путевки - не справочник!). Номер путевки уникален в рамках санатория. Путевка может появиться в системе только один раз: пришла-продали, больше такой путевки не должно быть.
- у каждой путевки есть дополнительные характеристики: дата заезда, продолжительность проживания. Характеристики могут расширятся без изменения конфигурации.
- Приходная накладная: в шапке санаторий, в табличной части номера путевок с доп. характеристиками.(Необходим контроль на задублированность путевок, как в самом документе так и на ранее введенные). - приходует путевки на остаток.
- Расходная накладная: в табличной части санатории, путевки. Подбор осуществляется через окно текущих остатков путевок. - расходует путевки с остатков.
- Отчет: Остатки и движение путевок. В фильтре: Период, Санаторий, Дата заезда.
В разрезе путевок вывести дополнительные характеристики.
Прошу помощи при решении простой(но для меня сложной!) задачи.
Необходимо автоматизировать предприятие, занимающееся реализацией путевок для различных санаториев.
На входе имеем:
-список санаториев(характеризуется простым наименованием)
- у каждого санатория имеются путевки(характеризуются номером путевки)(Путевки - не справочник!). Номер путевки уникален в рамках санатория. Путевка может появиться в системе только один раз: пришла-продали, больше такой путевки не должно быть.
- у каждой путевки есть дополнительные характеристики: дата заезда, продолжительность проживания. Характеристики могут расширятся без изменения конфигурации.
- Приходная накладная: в шапке санаторий, в табличной части номера путевок с доп. характеристиками.(Необходим контроль на задублированность путевок, как в самом документе так и на ранее введенные). - приходует путевки на остаток.
- Расходная накладная: в табличной части санатории, путевки. Подбор осуществляется через окно текущих остатков путевок. - расходует путевки с остатков.
- Отчет: Остатки и движение путевок. В фильтре: Период, Санаторий, Дата заезда.
В разрезе путевок вывести дополнительные характеристики.
По теме из базы знаний
- Загрузка номенклатуры в табличную часть документа из Excel
- Решения всех экзаменационных билетов экзамена 1С:Специалист по платформе 8.3. Советы по подготовке к экзамену.
- Специалист по платформе (алгоритм подготовки + решенные билеты)
- Algo1C: Решение алгоритмических задач на базе 1С:Предприятие [Часть #10]
- Решение алгоритмических задач на базе 1С:Предприятие [Часть #11]
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Это задачка для трудоустройства на работу, но за моими плечами опыта нет, есть только оконченные курсы, которых маловато для такой жести.
Я понимаю, что нужно создать справочник Санатории. Далее документы покупка-продажа. Сделать движения по регистру накоплений для срабатывания счетчика +/- путевка, где измерения будут Санаторий и Путевки, а ресурс Количество. Я так понимаю, для доп характеристик нужно использовать План видов характеристик (к сожалению, с ним я не знаком, пока понять не могу как и с чем его едят). Самое сложное понять, где должны хранится Путевки, раз это не справочник? В планах характеристик к Санаторию? А далее, как сделать уникальным Номер путевки, чтобы не было возможности его дублировать, как делается проверка? Ну и дальше в регистре накоплений как будет тикать счетчик по каждому новому полю, это нужно запрос делать?
Я начинающий в этом деле, есть какие то знания и немного навыков базовых, но я очень хочу уже устроится на работу, а времени 2 дня) Извиняюсь заранее, если я написал что-то некомпетентно.
Я понимаю, что нужно создать справочник Санатории. Далее документы покупка-продажа. Сделать движения по регистру накоплений для срабатывания счетчика +/- путевка, где измерения будут Санаторий и Путевки, а ресурс Количество. Я так понимаю, для доп характеристик нужно использовать План видов характеристик (к сожалению, с ним я не знаком, пока понять не могу как и с чем его едят). Самое сложное понять, где должны хранится Путевки, раз это не справочник? В планах характеристик к Санаторию? А далее, как сделать уникальным Номер путевки, чтобы не было возможности его дублировать, как делается проверка? Ну и дальше в регистре накоплений как будет тикать счетчик по каждому новому полю, это нужно запрос делать?
Я начинающий в этом деле, есть какие то знания и немного навыков базовых, но я очень хочу уже устроится на работу, а времени 2 дня) Извиняюсь заранее, если я написал что-то некомпетентно.
(4) если условие в задаче "путевки не справочник" жестко прописано, тогда можно использовать регистр сведений.
Где первое измерение это Санаторий, а второе это Путевка. Если у путевки используется только номер, тогда именно номер путевки и будет измерением. Уникальность путевки обеспечит сам регистр сведений.
Где первое измерение это Санаторий, а второе это Путевка. Если у путевки используется только номер, тогда именно номер путевки и будет измерением. Уникальность путевки обеспечит сам регистр сведений.
(25) если у задаче точно указано что тип номера путевки это число. Я бы использовал тип строка. И 3 измерение будет характеристика ПВХ.
А ресурсы могут быть разные. Но количество особого смысла нет. Путевка не может быть во множественном числе. Думаю больше подойдет Статус, в котором хранить значения перечисления. Новая, Продана, Закрыта и т.д. Тут уже от фантазии зависит.
А ресурсы могут быть разные. Но количество особого смысла нет. Путевка не может быть во множественном числе. Думаю больше подойдет Статус, в котором хранить значения перечисления. Новая, Продана, Закрыта и т.д. Тут уже от фантазии зависит.
(4) Хотите в справочнике, хотите в документах храните Путевку, это самый главный вопрос в задаче ? И вопрос с уникальностью номера там решается галочкой в настройке объекта (с годичностью в документе вот можно подумать, делать ли её или отключить совсем). регистр сведений я бы не стал использовать.
Движения в регистр накопления хоть через конструктор можно сделать в таком примитивном виде
Движения в регистр накопления хоть через конструктор можно сделать в таком примитивном виде
Я не пойму одного. Вы че тут все сразу стали гуру по решению всех задач?! Я просто попросил помощи. Мне нужны подсказки, так как своих знаний не хватает, а где их найти за два дня не знаю, кроме как на форумах. Я так понимаю, что люди, которые жопят помочь, имея знания, работают во Франчайзи или вообще нигде и хотят денег? Ведь только в крысинных местах типа Франчей люди не помогают друг другу просто так, а только за деньги, ибо там получают копейки и конкурируют между собой. Кто сидят на окладах думаю воспринимают подобную помощь как вызов себе для прокачки своих навыков и знаний.
Все же с чего начинали, вспомните себя на начале пути КАК ЭТО СЛОЖНО!
Все же с чего начинали, вспомните себя на начале пути КАК ЭТО СЛОЖНО!
(16) Те, которые сидят на окладах - очень боятся таких сотрудников из франчей, потому что именно они ломают в 1С все, что можно, а мы потом это говно разгребаем. Это не конкуренция, это попытка навести профессиональную гигиену и содержать нишу в чистоте.
По теме - поищи работу стажера для наработки опыта, можно даже во франче, если голова на месте.
По теме - поищи работу стажера для наработки опыта, можно даже во франче, если голова на месте.
(19)
Ну как "отсутствие" денег. Там сдельная оплата труда, сколько сделал, столько получил.
Я бы то же хотел получать деньги за то что ничего не умею. Но это надо в депутаты идти. А там не каждого берут, в отличие от франча.
В сосалку в виде отсутствия денег я не хочу играть. А в таком случае, придется так делать до полугода и больше.
Ну как "отсутствие" денег. Там сдельная оплата труда, сколько сделал, столько получил.
Я бы то же хотел получать деньги за то что ничего не умею. Но это надо в депутаты идти. А там не каждого берут, в отличие от франча.
Вопросов с хранением путевок я не вижу ( в обычной БП можно же продавать услуги не заводя элементов с справочник номенклатура) В ТЧ документов будет реквизит "Путевка" с типом число а в регистре накопление Измерение - "Номер путевки" что будет логически верным для отслеживания путевок. Больше вопросов к характеристикам скорее всего нужно добавлять не к путевке а к справочнику санатории
Похоже на задачи по подготовке к 1с спец. Напишите сюда . Там люди готовятся к экзамену и могут оперативно помочь с решением.
"Путевка может появиться в системе только один раз: пришла-продали, больше такой путевки не должно быть" - скорее всего из-за этого условия путевка - не справочник. Т.е в документах путевка - это строка с номером. Характеристики, как писали выше, можно в таком случае привязать к санаторию, т.к. каждый санаторий выдает свой перечень путевок (Номер путевки уникален в рамках санатория).
Но по мне, со справочником было бы правильнее.
"Путевка может появиться в системе только один раз: пришла-продали, больше такой путевки не должно быть" - скорее всего из-за этого условия путевка - не справочник. Т.е в документах путевка - это строка с номером. Характеристики, как писали выше, можно в таком случае привязать к санаторию, т.к. каждый санаторий выдает свой перечень путевок (Номер путевки уникален в рамках санатория).
Но по мне, со справочником было бы правильнее.
(28)
Что мешает внести повторно точно такую же строку с номером путевки в другой документ?
"Путевка может появиться в системе только один раз: пришла-продали, больше такой путевки не должно быть" - скорее всего из-за этого условия путевка - не справочник. Т.е в документах путевка - это строка с номером.
Что мешает внести повторно точно такую же строку с номером путевки в другой документ?
(34) Ну вам придется делать два контроля - первый контроль о том, что она есть в проведенных приходных документах, а второй, что её нет в проведенных расходных документах... Но это бред.
Номер путевки - это серия. Которая спокойно работает с регистрами остатков. Есть остатки - продаем.
Номер путевки - это серия. Которая спокойно работает с регистрами остатков. Есть остатки - продаем.
(35) Кстати , интересный момент , допустим пришла путевка N 1 , потом ее продали ( соответсвенно есть движения прихода и расхода по регистру накопления)
Через какое-то время снова пытаются купить путевку N 1 (допустим была ошибка ввода) . Нигде не сказано что номера путёвок только возрастают и по сути номер может быть любой . Как в таком случае проверить уникальность ? ( ведь на остатках путевки с таким номером не будет) т.е. ещё должен быть регистр сведений типа проданные путевки , и при покупке путёвок проверять не встречалась ли путевка с этим номером раньше
Через какое-то время снова пытаются купить путевку N 1 (допустим была ошибка ввода) . Нигде не сказано что номера путёвок только возрастают и по сути номер может быть любой . Как в таком случае проверить уникальность ? ( ведь на остатках путевки с таким номером не будет) т.е. ещё должен быть регистр сведений типа проданные путевки , и при покупке путёвок проверять не встречалась ли путевка с этим номером раньше
(37) Зачем? Путевки номерные, номера присваивает санаторий, ты их изменить не можешь. С каким номером на остатках есть - с таким и продаешь. Контролить уникальность вовсе даже необязательно в принципе. Если же номера присваивает не санаторий, а мы должны контролить - ну тогда сами и присваиваем число инкрементом при приобретении путевок, а при продаже контроль опять же будет лежать в области остатков по сериям (номерам).
(39) ты не понял
01.01.2020 приход путевка N1
05.01.2020 расход путевка N1
Сейчас остатков по путевки N 1 нет
31.01.2020 при вводе документа снова пытаются приходовать путевку N1
Раз номера уникальны мы не можем заново приходовать путевку с таким номером , но по остаткам ее нет.
Никто не застрахован от ошибки ввода данных
01.01.2020 приход путевка N1
05.01.2020 расход путевка N1
Сейчас остатков по путевки N 1 нет
31.01.2020 при вводе документа снова пытаются приходовать путевку N1
Раз номера уникальны мы не можем заново приходовать путевку с таким номером , но по остаткам ее нет.
Никто не застрахован от ошибки ввода данных
(38) я согласен, что на справочниках все это корректнее. Если делать аналогию к типовым, то Санаторий - это контрагент, путевка - номенклатура, Номер путевки - серия. Но как пишут в описании темы, путевка - не справочник. На мой счет, постановка задачи не совсем корректная. Предложенный выше вариант был именно с учетом описания задачи.
(42) Ну так по сути путевка - это и не справочник. Путевка - это номер серии и набор характеристик. Нет отдельного справочника "Путевки". Я думаю, именно это имелось ввиду.
А для связи в документах санатория и путевки (контрагента и номенклатуры) - можно в характеристики добавить как раз свойство "Санаторий"...
А для связи в документах санатория и путевки (контрагента и номенклатуры) - можно в характеристики добавить как раз свойство "Санаторий"...
(46) "серийный номер" это более абстрактное понятие ассоциируемое со "серия". И обычно "Серия" это справочник.
В итоге просто можно запутать ТС.
"Штрихкод" же как правило не справочник. И это более просто в понимании. Он так же может выступать в роли "серийный номер" в том виде, который подразумевается.
И использование РС в данном случае видится наиболее соответствующий задаче.
Невозможно привязать в строкам документа доп. характеристики. Привязка же доп. характеристик к санаториям вообще видится абсурдным. Это будет заметно на первой же сотне путевок, когда придется выбирать/создавать доп.характеристики.
В итоге просто можно запутать ТС.
"Штрихкод" же как правило не справочник. И это более просто в понимании. Он так же может выступать в роли "серийный номер" в том виде, который подразумевается.
И использование РС в данном случае видится наиболее соответствующий задаче.
Невозможно привязать в строкам документа доп. характеристики. Привязка же доп. характеристик к санаториям вообще видится абсурдным. Это будет заметно на первой же сотне путевок, когда придется выбирать/создавать доп.характеристики.
(47) Ну да, именно серия. Я из условий задачи понял так, что не надо плодить именно отдельного справочника под путевки, а не то чтобы не использовать справочников вовсе для учета путевок... И - да, никакого справочника "путевки" при моем решении в системе нет...
Можно завести несколько номенклатурных позиций "Путевка санатория "Родинка" и указывать у нее основного производителя/поставщика...
Привязка же доп. характеристик к санаториям вообще видится абсурдным.
Я вообще не об этом. Есть номенклатура (одна) путевка, у нее есть индивидуальные ХарактеристикаНоменклатуры, одним из свойств этой характеристики является "Санаторий" с типом "Контрагент"... Ну да, если создание характеристик оставить ручным -это немного муторно, согласен.
Можно завести несколько номенклатурных позиций "Путевка санатория "Родинка" и указывать у нее основного производителя/поставщика...
(48)
Это просто замена слова "Путевка" на "Серия". В задаче не это имеется ввиду.
т.е. подразумевается все же справочник Путевка?
Тогда вообще проще сделать справочник Путевка подчиненным справочнику Санаторий.
Тут главное доп.характеристики как "дата заезда", "время проживания" и дополнительные ручные добавления.
Ну да, именно серия. Я из условий задачи понял так, что не надо плодить именно отдельного справочника под путевки, а не то чтобы не использовать справочников вовсе для учета путевок...
Это просто замена слова "Путевка" на "Серия". В задаче не это имеется ввиду.
Есть номенклатура (одна) путевка, у нее есть индивидуальные ХарактеристикаНоменклатуры, одним из свойств этой характеристики является "Санаторий" с типом "Контрагент"...
т.е. подразумевается все же справочник Путевка?
Тогда вообще проще сделать справочник Путевка подчиненным справочнику Санаторий.
Тут главное доп.характеристики как "дата заезда", "время проживания" и дополнительные ручные добавления.
(49)
(49)
т.е. подразумевается все же справочник Путевка?
Нет, с чего вы взяли? Это существующие справочники "Номенклатура" (услуга "Путевка"), "Характеристики номенклатуры" (свойства "Контрагент", "Длительность"), "Серии номенклатуры" (номер путевки)... С датой заезда я еще не определился - если от даты заезда зависит цена, то её тоже в характеристику, чтобы можно было устанавливать разные цены для разных характеристик. А если от даты заезда цена не зависит, и она жестко установлена самим санаторием - то её можно в серию засунуть к номеру путевки.
(49)
В задаче не это имеется ввиду.
Откуда информация?
(51) Так там эти реквизиты существуют для разных типов серийного учета. Нам нужен только типовой учет по серийным номерам. Как для телевизоров. Телевизоры продаются по серийным номерам, и им не мешает срок годности? Серийный номер - уникальный в рамках одного производителя, как и номер путевки в рамках одного санатория.
Система полностью работает автоматически. О каком "отслеживании на проверяемость" идет речь?
Система полностью работает автоматически. О каком "отслеживании на проверяемость" идет речь?
(53) если даже представить, что так получилось (не рассматривая эти сложности), кто помешает в документе ПоступлениеТоваровУслуг ввести кучу этих путевок с количеством 100500? Можно даже не создавать новые серии, а использовать уже введенные. Костылить все равно придется.
(56)
А вот другим документом можно провести уже существующие серии,
То есть получается, что 100500 путевок с одним номером серии в одном документе не получится. А вот в 100500 документах - вполне. Тут я пока не знаю, как побороть, может и есть где-то еще хитрая настройка. В демо при настройке политик серии ругается на настройки ордерных складов, что не позволяет применить единую политику серий к виду номенклатуры с контролем остатков серий.
Опять же, номера серий привязаны к видам номенклатуры, что не позволит вести уникальность в пределах одной позиции номенклатуры, и для каждого санатория придется заводить отдельный вид номенклатуры, что вообще безобразно...
Костылить придется в любых вариантах, кажется.
кто помешает в документе ПоступлениеТоваровУслуг ввести кучу этих путевок с количеством 100500
Серийный учет "по экземпляру" - не дает. Одна серия - 1шт. Документ не проводится. Проверил...
А вот другим документом можно провести уже существующие серии,
То есть получается, что 100500 путевок с одним номером серии в одном документе не получится. А вот в 100500 документах - вполне. Тут я пока не знаю, как побороть, может и есть где-то еще хитрая настройка. В демо при настройке политик серии ругается на настройки ордерных складов, что не позволяет применить единую политику серий к виду номенклатуры с контролем остатков серий.
Опять же, номера серий привязаны к видам номенклатуры, что не позволит вести уникальность в пределах одной позиции номенклатуры, и для каждого санатория придется заводить отдельный вид номенклатуры, что вообще безобразно...
Костылить придется в любых вариантах, кажется.
(59) Чтобы не вводили уже существующие путевки использовать статус в РС. Цены можно там же хранить. Тут все зависит от ценообразования. Оно в задании не указано. Остатки можно тоже через РС получать. Статус. Можно отдельный РН использовать. РН более детальную отчетность позволит показывать.
В документ оприходования добавить уже существующий не позволит РС.
Доп.характеристики так же просто привязываются как измерение РС.
В чем проблема?
В документ оприходования добавить уже существующий не позволит РС.
Доп.характеристики так же просто привязываются как измерение РС.
В чем проблема?
(60) Ну то есть это изменения в модулях контроля типовых документов при проведении, изменение формы подбора этих путевок... Совсем никаких изменений в конфигурации, ага.
Доп.характеристики так же просто привязываются как измерение РС.
Тогда это позволит задвоить номера путевок в рамках одного санатория. Если уж и хранить допхаракетристики в РС - то только в реквизитах.
(61)
я это не говорил. это сами придумали.
я говорил только это: "Не надо ничего костылить в существующей конфигурации."
Зачем что-то изменять в модулях типовых документов при проведении? где сказано, что будут использоваться типовые документы? Документы будут новые.
Это решается. Обязательное поле в доп.характеристике для проверки номера. Проверять его не сложно.
тогда можно хранить только одну какую-то характеристику. Нам же нужно много разных.
Совсем никаких изменений в конфигурации, ага.
я это не говорил. это сами придумали.
я говорил только это: "Не надо ничего костылить в существующей конфигурации."
Зачем что-то изменять в модулях типовых документов при проведении? где сказано, что будут использоваться типовые документы? Документы будут новые.
Тогда это позволит задвоить номера путевок в рамках одного санатория.
Это решается. Обязательное поле в доп.характеристике для проверки номера. Проверять его не сложно.
Если уж и хранить допхаракетристики в РС - то только в реквизитах.
тогда можно хранить только одну какую-то характеристику. Нам же нужно много разных.
В общем... на данный момент результат таковы ( и мой ход мыслей вроде правильный(где то сам подумал, где то с подсказок постановщика задачи):
Создал справочник "Санатории"
Создал документы "РасходнаяНакладная" и "ПриходнаяНакладная"
В документе "ПриходнаяНакладная" реквизит санаторий, табличная часть с реквизитом "НомерПутевки" тип Число
Создал РегистрНакопления с измерениями "Санаторий" и "Путевка" и ресурсом "Количество"
Сделал Движения по документу "ПриходнаяНакладная", где ресурс "Количество" всегда принимает значение 1
Таким образом осуществлен приход путевок на остаток для дальнейшего вывода в отчет
Для осуществления проверки на задублированность значения Путевки в текущем документе, как я понял, необходимо выполнить обход таблицы, сравнить значения ячеек Путевка предыдущих строк с текущей строкой и при нахождении повтора выполнить запрет на ввод значения.
Я нашел в интернете простой код без обхода таблицы(там человек делал задание в УПП у него работало и версия платформы точно ниже 8.3), у меня не работает НайтиСтрокуТабЧасти. Может кто скинет ссылку, как выполнить запрет ввода в таблице, не могу найти? Или кусок кода хотя бы...
Второе же условие на проверку задублированности путевок в ранее созданных документах с таким же значением реквизита "Санаторий" я вообще не приложу голову, каким образом осуществить.
В документе "РасходнаяНакладная" необходимо выполнить подбор из РегистраНакопления, причем естественно должен быть запрет на повторный выбор путевки.
Для этого я создал общую форму "ФормаДляПодбора", в которой создал таблицу значений с колонками Санаторий и Путевка и вторую таблицу Динамический список, в который с помощью произвольного запроса я засунул виртуальную таблицу РегистрНакопления.Остатки. Далее в документе "РасходнаяНакладная" создал команду-кнопку Подбор, там пытался писать код, но ничего не вышло, даже кнопка в режиме предприятия не показана.
Подскажите, пожалуйста, ссылку на информацию по осуществлению подобного подбора. И может кто знает как выполнить "пропажу" путевки из регистра накопления после добавления в документ "РасходнаяНакладная"?
Что касается дополнительных характеристик у путевок, тут используется объект ПланВидовХарактеристик и РегистрСведений, в котором должны отображаться характеристики. Видимо благодаря этой связке выполняется условие, что пользователь может самостоятельно добавлять новые харакетристики к путевкам, а может еще и для использования в отчет, т.к. в условиях задачи еще написано, что в отчете в разрезе путевок вывести дополнительные хар-ки.
Что делать с доп хар-ми я вообще не знаю(
Вот как то так...
Создал справочник "Санатории"
Создал документы "РасходнаяНакладная" и "ПриходнаяНакладная"
В документе "ПриходнаяНакладная" реквизит санаторий, табличная часть с реквизитом "НомерПутевки" тип Число
Создал РегистрНакопления с измерениями "Санаторий" и "Путевка" и ресурсом "Количество"
Сделал Движения по документу "ПриходнаяНакладная", где ресурс "Количество" всегда принимает значение 1
Таким образом осуществлен приход путевок на остаток для дальнейшего вывода в отчет
Для осуществления проверки на задублированность значения Путевки в текущем документе, как я понял, необходимо выполнить обход таблицы, сравнить значения ячеек Путевка предыдущих строк с текущей строкой и при нахождении повтора выполнить запрет на ввод значения.
Я нашел в интернете простой код без обхода таблицы(там человек делал задание в УПП у него работало и версия платформы точно ниже 8.3), у меня не работает НайтиСтрокуТабЧасти. Может кто скинет ссылку, как выполнить запрет ввода в таблице, не могу найти? Или кусок кода хотя бы...
Второе же условие на проверку задублированности путевок в ранее созданных документах с таким же значением реквизита "Санаторий" я вообще не приложу голову, каким образом осуществить.
В документе "РасходнаяНакладная" необходимо выполнить подбор из РегистраНакопления, причем естественно должен быть запрет на повторный выбор путевки.
Для этого я создал общую форму "ФормаДляПодбора", в которой создал таблицу значений с колонками Санаторий и Путевка и вторую таблицу Динамический список, в который с помощью произвольного запроса я засунул виртуальную таблицу РегистрНакопления.Остатки. Далее в документе "РасходнаяНакладная" создал команду-кнопку Подбор, там пытался писать код, но ничего не вышло, даже кнопка в режиме предприятия не показана.
Подскажите, пожалуйста, ссылку на информацию по осуществлению подобного подбора. И может кто знает как выполнить "пропажу" путевки из регистра накопления после добавления в документ "РасходнаяНакладная"?
Что касается дополнительных характеристик у путевок, тут используется объект ПланВидовХарактеристик и РегистрСведений, в котором должны отображаться характеристики. Видимо благодаря этой связке выполняется условие, что пользователь может самостоятельно добавлять новые харакетристики к путевкам, а может еще и для использования в отчет, т.к. в условиях задачи еще написано, что в отчете в разрезе путевок вывести дополнительные хар-ки.
Что делать с доп хар-ми я вообще не знаю(
Вот как то так...
(65) Очень интересный подход, спасибо. В процессе работы клиенты выдвигали противоположные суждения, мотивируя постановкой учета от имени разных аудиторов. Путевка как бланк строгой отчетности (по аналогии с талоном на бензин), или путевка как авансовый платеж за услуги (как билет на пассажирский поезд, с местом или без него). И в том, и в другом случае возможны посредники (но их учет и налогообложение отличается). Полагаю, что сайт триваго с бронированием мест в отелях имеет какие-то свои требования. Стандарты бух.учета предусматривают как учет бланков, так и учет авансов (которые в типовых переделывать под учет путевок как-то страшновато).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот