Вот есть интересная задача. Её я получил в качестве тестового задания, сказали похожа на задачу из специалиста по платформе

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

Помогите, может кто встречал подобную задачу при подготовке?


Вот полный текст:
     Компания сдаёт в аренду мебель. Так же компания самостоятельно доставляет и монтирует мебель, а затем демонтирует и забирает её обратно. Для отражения всех операций по аренде используется один документ, который сразу делает движения и по монтажу, и по демонтажу (т.е. вводить в документ виды операций не нужно). Количество выданной в аренду мебели всегда равно количеству мебели, вернувшейся из аренды. Менеджер при оформлении документа аренды должен указать Контрагента, которому сдаётся в аренду мебель, Дату монтажа и Дату демонтажа (с точностью до минут), а также список сдаваемой в аренду мебели. Дата монтажа, как правило, не совпадает с датой документа. Т.е. документ может быть выписан датой 07.02, а реально мебель уедет в аренду с 15.02 по 20.02. Сумма за аренду фиксируется на дату документа.
     При проведении документов должен осуществляться контроль, есть ли необходимое количество мебели на складе. Причём необходимо учитывать ситуации, когда уже существуют оформленные документы аренды на тот период, на который оформляется аренда по текущему документу. Например, у компании есть 20 шт. столов. В период с 03.02 по 10.02 сдаются 7 столов, в период с 08.02 по 15.02 сдаются 10 столов. Текущий документ оформляется на период с 06.02 по 12.02. Ясно, что оформить можно не больше 3 столов, т.к. с 08.02 по 10.02 в общей сложности в аренде будут 7 + 10 = 17 столов, а всего у компании есть 20 столов. При попытке оформить больше 3 столов должно выходить соответствующее сообщение пользователю.

Ну если ничего лишнего не придумывать, то всё делается банально

ВидДвижения Период Контрагент Мебель Количество
Расход 01.05.2019 Пупкин В. Стол 1
Приход 01.11.2019 Пупкин В. Стол 1

и контроль остатков под это. Да, в промышленной автоматизации такой вариант не подойдёт, там будет много "НО": могут вернуть раньше/позже, могут не вернуть и т.д. Но по условиям задачи тупо расход+приход и самый простецкий контроль остатков по регистру

А кто мешает сделать два движения разными периодами? Это же не клюшки...

Работа задним числом?

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

(2) а что так можно было)) сейчас попробую

(3) по условиям задачи - передним, но что такое заднее/переднее число, все ж относительно, относительно текущего()

(0) Заведи отдельный склад с наименованием компании типа ответ хранения

(0) >Если вкратце там есть документ "Аренда мебели" и он должен одновременно и списывать мебель и каким то образом она должна обратно зачисляться на склад по истечении срока аренды( :o).

И в чем О то? В условии ничего такого нет и все банально.

Есть ДатаДокумента, есть ДатаНачала, есть ДатаОкончания.
И есть ТЧ Товары с Номенклатура и Количество.
Ну и СуммаАренды еще в документе.

И РН один сделать с измерениями Контрагент, Номенклатура и ресурсом Количество.
Если контрагент не указан - значит на складе.

Все реализуется типовым функционалом ЕРПа

(9) на сторону?

(0) Дебильная задача. От Вас хотят умение делать движение датами, отличными от даты документа делать. Ну и остатки получать.

(11) да всем плевать, главное что бы кнопочка жалась и работала

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

(11) +1 Задача явно учебная. Кодер должен уметь такое закодить. А вот консультант/аналитик/архитектор должен уметь осадить такого заказчика)

(13) Бегите оттуда. Как правило задачи даются исходя из конкретных задач предприятия. Если у них так процессы построены, то лучше в эту клоаку не  лезть. Исключения естественно есть, но обычно дела так обстоят - тупое тестовое задание ведет к тупой работе потом.

да ладно .. вот у нас аренда, действительно часть документов выписывается на будущее, а часть документов за прошлое.

(16) Угу. И машину времени еще каждому пользователю выдают.

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

(0) Зачем решаешь?! Нет бумажек сертификатных?! Так нужно было собирать их, а не слушать тех, на этом форуме, которые говорят, что такие бумажки тебе не нужны.

(19) Парадокс в том, что тем у кого есть бумажки, тоже дают эти задачи.

(0) И в чем проблема?

(20) Значит ты конторе не нужен или кусок настолько жирный, что не тебе глотать.

>Если вкратце там есть документ "Аренда мебели" и он должен одновременно и списывать мебель и каким то образом она должна обратно зачисляться на склад по истечении срока аренды( :o).

Я стесняюсь спросить:
Один и тот же документ делает две операции - сдает и принимает. Что мешает создать один документ на передачу в аренду и тут же создать другой документ на возврат из аренды с датой планируемого возврата?

Да, кстати, выход ТС на форум как раз и говорит, что не по зубам ему конторка.

Может от автора ждут решения на регистрах расчета

Если тип регистратора один, как в нашем случае, то расчет аренды хорошо заходит под них

(23)Наверное условие задачи?

(25) контроль остатков на РР. Круто чё.
Чего ждут от ТС вроде написано в (0)

- Вы хотите к нам устроиться водителем?
Вот вам тестовое задание - проехать 1000 км по этому маршруту на тягоче той модели, на котором работать собираетесь.
- Вы хотите к нам устроится хирургом?
Вот вам тестовое задание - прооперировать 90 летнюю старушку.
- Вы хотите работать Президентом?
Вот вам тестовое задание - поработать месяц Президентом в вот этой стране.

(0) это никак не похоже на спеца по платформе, так как нарушается один из принципов 1С

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

(30) Представь что операция-таки одна, т.е. абсолютно всегда строго гарантированно, что демонтаж будет осуществлен в запланированную дату.

в зупе такое раньше практиковалось.
сейчас точно не знаю

(31) тогда возникает ситуация, когда демонтаж не был произведен, произведен не в ту дату, или при демонтаже произошли проблемы - вносить изменения в уже существующий документ? Это неправильно. А если монтаж и демонтаж производят разные люди?

Должен быть документ монтаж и плановая потребность в демонтаже. По плановой потребности формируется документ, регистрирующий демонтаж.


(32) В ЗУПе один и тот же процесс (отпуск, больничный и т.д.) заполняют два сотрудника, каждый свои поля.

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

(34)

"Но не надо в РБ писать "Вперед", это очень плохая идея..."

да ну, почему бы и нет - движения есть, отчеты построить можно

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


то есть
было 1шт

док1
от 01/01
списываем 10/01 1ш
возвращаем 20/01 1шт

вроде не сложно (хотя и не самый тупой будет) написать запрос контроля остатков для док-2
от 01/01 но со списанием от 15/01

а вот попробуйте написать для док-3 со списанием 20/01,

а если документов 10шт, и их перепроводим.... тут возникает дилема какой из документов мы считаем правильным а какие 9 будем заворачивать?

(36) Прежде чем что-то кодить надо расписать задачу

нет алгоритмов, нет решения

кстати в (0) очень интересная задачка... и довольно не простая при чем не только в реализации но и методологически...

(0) всё предельно ясно, в ларёчном учёте такое встречается каждый второй раз
решается за 30 мин. по условию

(33) Что-то ты бакланишь. Могу только порекомендовать перечитать сообщение, на которое ты отвечаешь.

(34) "оперативные итоги будут не равны текущим" // Что еще за оперативные? В 8 текущие и есть оперативные.

+(42) Речь о флажке "Текущие" в управлении итогами - это и есть признак того рассчитываются ли "итоговые" итоги (на дату последнего движения) или нет.

(41) ну бугага че
кто еще бакланит, ты видимо в месте, где реально происходят события, никогда не был
виденье исключительно удаленщика

(44) Что-то у тебя язык заплетается. Давай еще разок. Ну или сходи туда же, куда послан предыдущий )

хотя в условиях задачи ничего такого не сказано, если подходить чисто формально по условиям, то все реализуемо тупо и беспощадно

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

(47) И пока складывается ощущение, что тебе это нравится)

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

ты действительно думаешь, что так бывает?

Я на какую-то там твою проф. тему и не заскакивал, так что про "соскочить" ты что-то напутал.

не ряби)

Таких слов не знаю, но факт что присосаться тебе не удалось)

чта?

пойди все таки поработай с реальными людьми в реальном процессе, потом будешь давать советы, где галочку с итогами ставить, теоретик

(53) Избавь меня от своих попыток присосаться. Спасибо! )

"присосаться" что это значит О_о

а, понял, этимология слова такова видимо

[email protected]

лол

(49) Мы же не видим всей системы. Может там есть документ, который может корректировать эти движения и сдвигать даты)

Чего вы придрались к тестовой задаче?
процесс один,аренда чего-то на определенное время
реально же,документ аренда это фиксация договора об аренде.
для получентя мебели со склада должна быть отгрузка,а для возврата,приходование на склад.
и,если мы ведем планирование аренды,то мы должны знать,когда и что к нам ДОЛЖНО вернуться.
вопросы оперативного учета и своевременного возврата-это отдельный контур.

(49) задача сделать, что написано в тестовом задании. если программист скажет, что он не будет решать, т.к. думает, что так в жизни не будет, так и брать его в контору не надо.

(59) умение обосновать свое мнение почему так делать не надо ценится куда как выше чем тупая реализация.

(58) да, тут больше термин "резервирование" подходит. На решение задачи это конечно не повлияет.

Кому не нравится записи в РН будущим периодом, может сделать перепроведение документов при запуске, тех что надо.

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

(62) "может сделать перепроведение документов при запуске, тех что надо" за такое с экзамена выгоняют и даже талончик на столовую не дадут))

(25) вспомнил ЗиК, там же такой треш творился с остатками.

ничего интересного,
и тут на*бали

(64) что путного может сказать человек с мылом сосальщик07@маил.ру?

этот чел организовал мне настроение прям на весь день, ржу

остаток 1шт

есть 2 документа
док 1 - от 01/01 и дата монтажа 10/01
док 2 - от 02/01 и дата монтажа 05/01

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

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

(67) Любую решаемую без компа задачу можно решить на компе.

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

Если кто понял проверьте решение

(69) Попытаюсь аргументировать по примеру в задаче.

Начальный остаток Стол-20шт.
У нас есть 3 документа.

Док1 с 03.02 по 10.02 сдаются 7 столов
Док2 с 08.02 по 15.02 сдаются 10 столов
На текущий момент Док3 с 06.02 по 12.02 доступно не более 3 столов.

Суть такова что если новый документ своей датой монтажа при проведении (его еще нет в БД) "влазит" в период пока не закончена самая последняя аренда, нам нужно получить остаток на момент даты монтажа (расхода) последнего документа который есть в базе - это и будет остаток доступный для использования.
Иначе если у нового документа дата монтажа больше последнего движения даты демонтажа (прихода когда все количество вернется обратно) тогда актуальный остаток и будет на дату последнего демонтажа (прихода)

Движения Док1 Дата - 03.02 ВидДвижения - Расход КолВо - 7
Движения Док1 Дата - 10.02 ВидДвижения - Приход КолВо - 7
Движения Док2 Дата - 08.02 ВидДвижения - Расход КолВо - 10
Движения Док2 Дата - 15.02 ВидДвижения - Приход КолВо - 10

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

Делаем запрос к остаткам и оборотам и сортируем результат по убыванию даты движения вычисляем остатки на каждую дату
Движения Док2 Дата - 15.02 ВидДвижения - Приход КолВо - 10 ОстатокНач - 10 ОстатокКон - 20
Движения Док1 Дата - 10.02 ВидДвижения - Приход КолВо - 7  ОстатокНач - 3 ОстатокКон  - 10
Движения Док2 Дата - 08.02 ВидДвижения - Расход КолВо - 10 ОстатокНач - 13 ОстатокКон - 3
Движения Док1 Дата - 03.02 ВидДвижения - Расход КолВо - 7  ОстатокНач - 20 ОстатокКон - 13

Далее группируем и сортируем по документу по убыванию

Движения Док2 Дата - 15.02 ВидДвижения - Приход КолВо - 10 ОстатокНач - 10 ОстатокКон - 20 <-
это нам доступно если дата следующего списания больше последнего прихода
Движения Док2 Дата - 08.02 ВидДвижения - Расход КолВо - 10 ОстатокНач - 13 ОстатокКон - 3  <-это нам доступно на 06.02 число так как документ влез в период
Движения Док1 Дата - 10.02 ВидДвижения - Приход КолВо - 7  ОстатокНач - 3 ОстатокКон  - 10
Движения Док1 Дата - 03.02 ВидДвижения - Расход КолВо - 7  ОстатокНач - 20 ОстатокКон - 13

(70) + как и по примеру задачи на 06.02 остаток у нас составит 3 стола которые не участвуют в периоде с 03.02 по 15.02

(70) Как проконтролируешь что из аренды вернулся именно тот стол который отдали в аренду?

(72) Это задача кладовщика. А не программиста.

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

(72) свое решение считаю верным по условию. Остальное нюансы. А следить должен кладовщик. Присвойте номера инвентаный

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

(76) Собственно, такой подход работает только когда постановщик качественный.
А если он не шарит в типовой функциональности и предлагает костылить и велосипедить, то это прямая дорога к перевнедрению)

(77) Такой подход работает всегда. Если постановщик некачественный - проект загнётся ещё до этапа программирования.

(78) Что-то у тебя язык заплетается. Давай еще разок :)

(79) Это у тебя мысли заплетаются. Проснись!

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

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

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

(80) Не помнишь что ли ветки с "миром шапок", где ЕРП используют как НСИ и печаталку печатных форм? Так что твое "всегда" уже всяко неуместно.

(82) * уточнение: с детализацией "по регистратору" читать как с детализацией "по каждой записи".

(82) Как это выглядеть будет? Вот - даже не представляю, что есть в регистрах расчёта, что поможет правильно решить задачу (0), да и что там рассчитывать? Если остаток на дату, то как это выглядит?

(85) >> что есть в регистрах расчёта.

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

Автор задачи - дятел с победитовым наконечником.

(86) Так это получение периода аренды, а требуется - учёт остатка в каждую дату бед движений передним числом

В ЗУП-е 2.5 для этого использовался ДатаВозврата регистра, и совсем не Расчёта.
В ЗУП 3 - вообще независимые записи сведений

(89) Я не работаю с ЗУПами. Понятия не имею как там реализовано вытеснение. И ума не приложу - как для этого можно использовать регистр сведений или накопления.
Даже интересно - нафига прикручивать регистр сведений там, где специально ради этого авторами платформы был изобретён регистр расчета с вытеснением.

(88) >> требуется - учёт остатка.

Ты не понял задачу. Остаток никому не интересен. В (0) - формулировка того, как это понимает пользователь.
Задача - определить наличие сдаваемого объекта в течении всего периода планируемой аренды.
На регистре накопления это решается только анальным способом - получение остатков на каждое движение в нужном периоде (начиная с даты сдачи) или вычислением всех движений с учётом начального остатка и последующих сдач/возвращений.
Недостаток регистра расчета для автора в том, что он не ведёт учет сдаваемой мебели по объектно. Его интересует только общее количество нужного наименования (столов, например). А регистр расчета умеет вытеснение производит относительно конкретного объекта расчета. Так что, как я уже и говорил ранее, регистр расчета для него не подойдёт.

Действительно интересная задача. Я тоже сначала подумал, что методологически поставлена неверно, две операции в одном документе и т.д.

Но задача вполне нормальная, отвечающая потребностям бизнеса. Вот представьте, сидит менеджер и принимает заказы на аренду. И ему каждый раз нужно ответить на вопрос: "Можем или не можем дать это количество на нужный период, с учетом всех уже принятых до этого заказов? Вот программа и должна отвечать на этот вопрос. Поэтому и даты в будущем, и возврат сразу регистрируется, чтобы были данные для ответа на вопрос.

Получается, нужно учитывать движения всех проведенных документов, независимо от дат в них. То есть, как сказано в (82), получать остатки с детализацией по каждой записи, и проверять, что нигде не уходим в минус.

(90) Ничего не "анальный" способ, нормальный. Для таких случаев и нужны остатки по каждой записи.

(90) В данной задаче не нужен пообъектный учет, нужен количественный. Поэтому РР не подходит.

(93) Спасибо за ещё одно повторение моих слов. А то вдруг до кого-то ещё не дошло.... ))))

(92) Анальный, анальный. Такой же как и сама постановка.
С точки зрения производительности вообще самый тормознутый.
Авторы платформы регистры накопления и все сопутствующие механизмы итогов и текущих итогов изобретали не для того, чтобы разработчики прикладных решений (конфигурасты) гланды через *опу удаляли да ещё и без наркоза (при проведении документов).

(95) Вот теперь - я точно понимаю, что не понимаю. Но не саму задачу, а что вы написать пытаетесь. То у вас "Напрашивается решение на регистрах расчета", то "регистр расчета для него не подойдёт". И задача, вполне себе тривиальная, у вас, почему-то, анальная.
А показалось, что прям есть супер-пупер решение на расчёте

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

(97) Да и справочник можно приспособить, ежели умеючи, чего уж там.

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

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

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

можно сделать регистр сведений,где будут даты изменения количества и количество на эту дату,оно будет действовать до следующего изменения срез на дату даст количество га текущий день,а выборка записей в периоде запрашиваемой аренды даст возможность узнать да или нет.
и никакого перебора каждый день(в ЗУП это построение перебора дат уже достало)