По теме из базы знаний
Найденные решения
Вот решение от CHat GPT:
Функция ПолучитьМесяцыПериода(ДатаНач, ДатаКон)
Месяцы = Новый Список;
ДатаТек = ДатаНач;
Пока ДатаТек <= ДатаКон Цикл
Месяц = Месяц(ДатаТек);
Если НЕ Месяцы.Найти(Месяц) Тогда
Месяцы.Добавить(Месяц);
КонецЕсли;
ДатаТек = ДобавитьМесяц(ДатаТек, 1);
КонецЦикла;
Возврат Месяцы;
КонецФункции ПоказатьОстальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Вот решение от CHat GPT:
Функция ПолучитьМесяцыПериода(ДатаНач, ДатаКон)
Месяцы = Новый Список;
ДатаТек = ДатаНач;
Пока ДатаТек <= ДатаКон Цикл
Месяц = Месяц(ДатаТек);
Если НЕ Месяцы.Найти(Месяц) Тогда
Месяцы.Добавить(Месяц);
КонецЕсли;
ДатаТек = ДобавитьМесяц(ДатаТек, 1);
КонецЦикла;
Возврат Месяцы;
КонецФункции Показать
(4)
1. Этот код не компилируется, ибо 1С не знает про такой тип как список.
2. После того как я его поправил - заменил список массивом (по вкусу, можете чем-то еще, хоть списком значений, мне лень), более ничего не делал, код заработал.
Но, даже тут натворил (впрочем, проверьте, может я ошибаюсь, код ниже, см. ПОСЛЕДНИЙ метод, остальные наваял для проверки) чудесатых дел.
2.1. Условие Если НЕ Месяцы.Найти(Месяц) намекает на то, что он своеобразно понял условие, как получение просто уникальных номеров. Т.е. переход через год/годы он обрабатывает "верно" (на самом деле все равно НЕ ВЕРНО), но только не так, как от него, скорее-всего ожидалось.
Но в таком случае, надо быть странным человеком на букву "м", чтобы в цикле пробегаться, например, по 15 годам, не понимая, что больше 12 месяцев в массиве, по такому условию, быть не может.
2.2. Он может потерять месяц (а может и нет, вы готовы это каждый раз контролировать?) при переходе через год, даже при таком понимании задачи.
Т.е. ИИ не справился с простейшей задачей даже при понимании вопроса "в лоб", не говоря уж о том, что можно запарится уточняя задачу, которую обычный программист поймет за 10с.
А ведь это даже не задача на junior, это что-то с азов курсов введения в программирование.
P.S. Я не пытался запихать месяцы в ТЗ, проверять начальные значения и т.п., т.к. меня заинтересовал именно код ИИ.
Функция ПолучитьМесяцыПериода(ДатаНач, ДатаКон)
1. Этот код не компилируется, ибо 1С не знает про такой тип как список.
2. После того как я его поправил - заменил список массивом (по вкусу, можете чем-то еще, хоть списком значений, мне лень), более ничего не делал, код заработал.
Но, даже тут натворил (впрочем, проверьте, может я ошибаюсь, код ниже, см. ПОСЛЕДНИЙ метод, остальные наваял для проверки) чудесатых дел.
2.1. Условие Если НЕ Месяцы.Найти(Месяц) намекает на то, что он своеобразно понял условие, как получение просто уникальных номеров. Т.е. переход через год/годы он обрабатывает "верно" (на самом деле все равно НЕ ВЕРНО), но только не так, как от него, скорее-всего ожидалось.
Но в таком случае, надо быть странным человеком на букву "м", чтобы в цикле пробегаться, например, по 15 годам, не понимая, что больше 12 месяцев в массиве, по такому условию, быть не может.
2.2. Он может потерять месяц (а может и нет, вы готовы это каждый раз контролировать?) при переходе через год, даже при таком понимании задачи.
Т.е. ИИ не справился с простейшей задачей даже при понимании вопроса "в лоб", не говоря уж о том, что можно запарится уточняя задачу, которую обычный программист поймет за 10с.
А ведь это даже не задача на junior, это что-то с азов курсов введения в программирование.
Процедура КнопкаВыполнитьНажатие(Кнопка)
рез = ПолучитьМесяцыПериодаЧислами(Дата(2021, 5, 3), Дата(2022, 6, 1));
Сообщить(рез);
рез = ПолучитьМесяцыПериода(Дата(2021, 5, 3), Дата(2022, 6, 1));
Сообщить(рез);
рез = ПолучитьМесяцыПериодаGPT(Дата(2021, 5, 3), Дата(2022, 2, 1)); //месяц с номером 2 потеряет!
Сообщить(рез);
КонецПроцедуры
Функция ПолучитьМесяцыПериодаЧислами(Знач ДатаНачАрг, Знач ДатаКонАрг)
Результат = Новый Массив();
ДатаНач = НачалоМесяца(ДатаНачАрг);
ДатаКон = НачалоМесяца(ДатаКонАрг);
Пока ДатаНач <= ДатаКон Цикл
Результат.Добавить(Месяц(ДатаНач));
ДатаНач = ДобавитьМесяц(ДатаНач, 1);
КонецЦикла;
Возврат Результат;
КонецФункции
Функция ПолучитьМесяцыПериода(Знач ДатаНачАрг, Знач ДатаКонАрг)
Результат = Новый Массив();
ДатаНач = НачалоМесяца(ДатаНачАрг);
ДатаКон = НачалоМесяца(ДатаКонАрг);
Пока ДатаНач <= ДатаКон Цикл
Результат.Добавить(ДатаНач);
ДатаНач = ДобавитьМесяц(ДатаНач, 1);
КонецЦикла;
Возврат Результат;
КонецФункции
Функция ПолучитьМесяцыПериодаGPT(ДатаНач, ДатаКон)
Месяцы = Новый Массив();
ДатаТек = ДатаНач;
Пока ДатаТек <= ДатаКон Цикл
Месяц = Месяц(ДатаТек);
Если НЕ Месяцы.Найти(Месяц) <> Неопределено Тогда
Месяцы.Добавить(Месяц);
КонецЕсли;
ДатаТек = ДобавитьМесяц(ДатаТек, 1);
КонецЦикла;
Возврат Месяцы;
КонецФункции
ПоказатьP.S. Я не пытался запихать месяцы в ТЗ, проверять начальные значения и т.п., т.к. меня заинтересовал именно код ИИ.
(35)
А если шутки в сторону, то:
SQL запросы позволяют делать сложные манипуляции с данными достаточно простым и наглядным образом. Особенно если это не 1С запросы с обрезанным форматом SQL-92 30-летней давности.
"несколько ноябрей" - года же разные. Это разные "ноябри".
Опять запросы...
- а за что Вы так не любите запросы? Они Вас чем-то обидели? :-) Пожалуйтесь на эти запросы нам, мы им сделаем а-та-та. :-)
А если шутки в сторону, то:
SQL запросы позволяют делать сложные манипуляции с данными достаточно простым и наглядным образом. Особенно если это не 1С запросы с обрезанным форматом SQL-92 30-летней давности.
"несколько ноябрей" - года же разные. Это разные "ноябри".
(41)
Представил. При открытии любой формы документа средней руки сложности, данных передаётся на порядок больше, чем короткий текст запроса, который даже не лезет в физические таблицы БД.
А в случае передачи этой ТЗ сервер-клиент, вам нужно будет ТЗ стерилизовать, т.е. ТЗ разобрать, например, на массив структур и ещё прочей мутью заниматься. Вас же это не смущает. Так зачем, что-то на клиенте создавать, если необходимо это будет куда-то передавать. Может сразу на сервере и создавать? Об этом не думали?
А вот нужно куда-то передавать или нет мы уже не узнаем. Автор исчез.
Ещё раз подчеркну. Мое решение будет правильным, если передача этой ТЗ куда-то происходит. Я уже не знаю какими буквами это написать. :-)
А представьте (С), что SQL сервер находится не рядом с сервером 1С, а за пяток хопов по сети.
Представил. При открытии любой формы документа средней руки сложности, данных передаётся на порядок больше, чем короткий текст запроса, который даже не лезет в физические таблицы БД.
А в случае передачи этой ТЗ сервер-клиент, вам нужно будет ТЗ стерилизовать, т.е. ТЗ разобрать, например, на массив структур и ещё прочей мутью заниматься. Вас же это не смущает. Так зачем, что-то на клиенте создавать, если необходимо это будет куда-то передавать. Может сразу на сервере и создавать? Об этом не думали?
А вот нужно куда-то передавать или нет мы уже не узнаем. Автор исчез.
Ещё раз подчеркну. Мое решение будет правильным, если передача этой ТЗ куда-то происходит. Я уже не знаю какими буквами это написать. :-)
(48)
Вы не слышите главного. Если нужно передавать в запрос ТЗ, но есть возможность генерировать ТЗ сразу запросом, то не надо ничего создавать и передавать в этот запрос. Сам факт передачи этой ТЗ в запрос можно исключить из этой цепочки действий. Зачем лишние телодвижения, которые нагружают систему передачей данных, лишний процедурный код?
А вот уже потом при необходимости передавать этот список/массив на сервер (если уж очень хочется получить ТЗ или передать в запрос, например).
Вы не слышите главного. Если нужно передавать в запрос ТЗ, но есть возможность генерировать ТЗ сразу запросом, то не надо ничего создавать и передавать в этот запрос. Сам факт передачи этой ТЗ в запрос можно исключить из этой цепочки действий. Зачем лишние телодвижения, которые нагружают систему передачей данных, лишний процедурный код?
(43) Хорошо, спущусь на твой уровень.
1С, детишки, это трехзвенная система. Это означает, что она работает на трех компьютерчиках - на SQL серверочке на серверочке приложений и на клиентике. При выполнении запроса данные бегают туда-сюда между первым и вторым компьютерчиком: SQL и приложений. А уже потом отправляются в путешествие к третьему, к клиентику. И если SQL серверочек находится далеко в сети, то байтики опаздывают и задерживаются, от этого серверочку приложений очень грустно. А когда серверочку приложений грустно, клиентики начинают плакать.
Вот так вот это, детишки работает. А то, что вы называете работой с формочками и "стерилизацией", хи-хи, оно только в самом конце, когда данные с компьютерчика серверочка приложений на клиента отправлюятся. И к нашему случаю отнощения не имеют, это другая сказка.
Так тебе понятней?
1С, детишки, это трехзвенная система. Это означает, что она работает на трех компьютерчиках - на SQL серверочке на серверочке приложений и на клиентике. При выполнении запроса данные бегают туда-сюда между первым и вторым компьютерчиком: SQL и приложений. А уже потом отправляются в путешествие к третьему, к клиентику. И если SQL серверочек находится далеко в сети, то байтики опаздывают и задерживаются, от этого серверочку приложений очень грустно. А когда серверочку приложений грустно, клиентики начинают плакать.
Вот так вот это, детишки работает. А то, что вы называете работой с формочками и "стерилизацией", хи-хи, оно только в самом конце, когда данные с компьютерчика серверочка приложений на клиента отправлюятся. И к нашему случаю отнощения не имеют, это другая сказка.
Так тебе понятней?
(34) Я говорил про 10с применительно к пониманию поставленной задачи, а не времени/способу ее решения.
А по запросу я бы подумал вот о чем:
Во-первых, идти на сервер SQL за такой ерундой, скорее-всего, получится медленнее, чем посчитать все на клиенте или сервере 1С. Да еще и будет забивать кэш запросов (это придирка, конечно, но если таких вот решений много, то...).
Во-вторых, ежели что-то где-то пойдет не так, то программист, причем скорее-всего не вы и не с вашей квалификацией, будет тратить несколько лишних минут на вникание в код.
Хотя я и сталкивался с подобными решениями, основанными на декартовых произведениях, но, честно говоря, завис минуты на 3 и желания перепроверить все равно не возникло.
Я так понимаю, что про скромные возможноcти ИИ возражений нет?
В нашем случае, вероятно, не будет проблемой научить ИИ выдавать верное решение, даже в нескольких вариантах.
Беда придет, когда вы попытаетесь серьезно усложнить задачу и будете вводить элементы еще не известные ИИ и исходить еще и из нечеткой/многовариантной постановки задачи.
А обычно программист с такими задачами и работает.
Т.е. будете требовать от ИИ не шаблонов, а новых (сколь угодно относительно новых) решений.
А возможности ИИ как продвинутой базы данных готовых шаблонов и идей по их сочетанию я и не отрицаю.
А по запросу я бы подумал вот о чем:
Во-первых, идти на сервер SQL за такой ерундой, скорее-всего, получится медленнее, чем посчитать все на клиенте или сервере 1С. Да еще и будет забивать кэш запросов (это придирка, конечно, но если таких вот решений много, то...).
Во-вторых, ежели что-то где-то пойдет не так, то программист, причем скорее-всего не вы и не с вашей квалификацией, будет тратить несколько лишних минут на вникание в код.
Хотя я и сталкивался с подобными решениями, основанными на декартовых произведениях, но, честно говоря, завис минуты на 3 и желания перепроверить все равно не возникло.
Я так понимаю, что про скромные возможноcти ИИ возражений нет?
В нашем случае, вероятно, не будет проблемой научить ИИ выдавать верное решение, даже в нескольких вариантах.
Беда придет, когда вы попытаетесь серьезно усложнить задачу и будете вводить элементы еще не известные ИИ и исходить еще и из нечеткой/многовариантной постановки задачи.
А обычно программист с такими задачами и работает.
Т.е. будете требовать от ИИ не шаблонов, а новых (сколь угодно относительно новых) решений.
А возможности ИИ как продвинутой базы данных готовых шаблонов и идей по их сочетанию я и не отрицаю.
(42)
Пока ИИ не способен писать код - даже порой простой код. Но это на сегодня на 2023 год. А как будет в 2030 году не известно. Может так же будет не способен. Опять же ИИ не решает задачу, а ищет уже готовые решения и компонует их.
По ИИ сейчас прошла массовая реклама из каждого утюга. И не нужно отрицать, что успехи действительно есть. Диплом написать и пройти собеседование на работу ИИ удалось. Тут конечно вопрос не к интеллектуальным возможностям ИИ, а скорее к системе приема диплома и критериев проведения собеседования при приёме на работу. Но факт остается фактом.
Это типовой простой код. Он и подобный очень часто встречается.
Я так понимаю, что про скромные возможности ИИ возражений нет?
Пока ИИ не способен писать код - даже порой простой код. Но это на сегодня на 2023 год. А как будет в 2030 году не известно. Может так же будет не способен. Опять же ИИ не решает задачу, а ищет уже готовые решения и компонует их.
По ИИ сейчас прошла массовая реклама из каждого утюга. И не нужно отрицать, что успехи действительно есть. Диплом написать и пройти собеседование на работу ИИ удалось. Тут конечно вопрос не к интеллектуальным возможностям ИИ, а скорее к системе приема диплома и критериев проведения собеседования при приёме на работу. Но факт остается фактом.
Хотя я и сталкивался с подобными решениями, основанными на декартовых произведениях
Это типовой простой код. Он и подобный очень часто встречается.
(44)
Вот насчет диплома счас обидно стало :). Потому, что показывает реальное значение таких вот рефератов, дипломов, кандидатских, индексов цитирования, "художественных произведений" и т.п.
Вместо реальных знаний и умений получаем шлак в голове, шлак на входе и шлак на выходе.
Это было всегда, но с появлением ИИ, количество точно перейдет в качество.
Это уже сейчас по уровню некоторых научных статей видно. Сегодня читал про установку солнечных панелей на участках дорог (во Франции, ежели что).
Вроде и какие-то цифры есть, например хотя бы КПД в вакууме привели, и текст связный, а на выходе полное недоумение: как считалась эффективность, каковы затраты на производство, укладку панелей, утилизацию, поддержку, качество сцепления с дорогой в зависимости от погодных условий, как меняется КПД от износа, загрязненности, какое количество повреждений участок может выдержать до потери нужного тока зарядки...
Как обеспечивается связь с остальной энергосистемой и т.д и т.п.
И ведь не бином ньютона требуется, никто не требует обычной публике рассказывать про ротор дивергенции вектора А, а понятные любому технарю цифры.
Т. е. полное впечатление, что статью писал ChatGPT, а единственной целью былосдать диплом, добыть бабки, потом объяснить почему не пошло и попросить поддержки от государства.
ВНИМАНИЕ! Я оригинал не читал, чего там напел автор "статьи про статью", то и оценил, но автор изложений на великий и могучий тоже претендует на лавры технического специалиста.
Диплом написать.
Вот насчет диплома счас обидно стало :). Потому, что показывает реальное значение таких вот рефератов, дипломов, кандидатских, индексов цитирования, "художественных произведений" и т.п.
Вместо реальных знаний и умений получаем шлак в голове, шлак на входе и шлак на выходе.
Это было всегда, но с появлением ИИ, количество точно перейдет в качество.
Это уже сейчас по уровню некоторых научных статей видно. Сегодня читал про установку солнечных панелей на участках дорог (во Франции, ежели что).
Вроде и какие-то цифры есть, например хотя бы КПД в вакууме привели, и текст связный, а на выходе полное недоумение: как считалась эффективность, каковы затраты на производство, укладку панелей, утилизацию, поддержку, качество сцепления с дорогой в зависимости от погодных условий, как меняется КПД от износа, загрязненности, какое количество повреждений участок может выдержать до потери нужного тока зарядки...
Как обеспечивается связь с остальной энергосистемой и т.д и т.п.
И ведь не бином ньютона требуется, никто не требует обычной публике рассказывать про ротор дивергенции вектора А, а понятные любому технарю цифры.
Т. е. полное впечатление, что статью писал ChatGPT, а единственной целью было
ВНИМАНИЕ! Я оригинал не читал, чего там напел автор "статьи про статью", то и оценил, но автор изложений на великий и могучий тоже претендует на лавры технического специалиста.
(10) У меня нет такой проблемы. :-)
Вопрос зачем это нужно и что дальше с этим планируется делать. Если планируется куда-то ТЗ передавать для работы с данными, то проще сразу запросом создавать уже эту таблицу с датами и работать уже с ней.
Если бы был список месяцев, то это могло быть нужно для диалоговой формы например. Предложенный алгоритм как раз список, а не ТЗ создает. В задаче автору нужна именно ТЗ. Вот и хотел узнать для чего. Если не для запроса, то можно тот же алгоритм, только результат не в список помещать, а в ТЗ. А если далее с этими месяцами работать с данными, то сразу уже запросом и формировать таблицу и дальше использовать. Мне так видится более логичным.
Вопрос зачем это нужно и что дальше с этим планируется делать. Если планируется куда-то ТЗ передавать для работы с данными, то проще сразу запросом создавать уже эту таблицу с датами и работать уже с ней.
Если бы был список месяцев, то это могло быть нужно для диалоговой формы например. Предложенный алгоритм как раз список, а не ТЗ создает. В задаче автору нужна именно ТЗ. Вот и хотел узнать для чего. Если не для запроса, то можно тот же алгоритм, только результат не в список помещать, а в ТЗ. А если далее с этими месяцами работать с данными, то сразу уже запросом и формировать таблицу и дальше использовать. Мне так видится более логичным.
(13)
А в продуктиве надо бить по зарплате. Причем с оттяжкой так и наглядно - не прошел код ревью -> не уложился в спринт -> задача не пошла в релиз -> на тебе пистон от бизнеса и понижение довольствия.
не только по рукам.
В тестовых форумных песочницах достаточно прилюдно обоссать и сжечь. Невзирая на потрясание седыми регалиями типа "да я вообще технический директор с сертификатом MCSE, а вы чернь". Пусть обижается и в черный список вносит.
А в продуктиве надо бить по зарплате. Причем с оттяжкой так и наглядно - не прошел код ревью -> не уложился в спринт -> задача не пошла в релиз -> на тебе пистон от бизнеса и понижение довольствия.
(13) Во-первых я написал про надобность или не надобность сначала определить. Если далее данные об этих периодах или месяцах будет использоваться, то сразу создавать данные в запросе.
Во-вторых создание маааааленькой таблицы в памяти, объектно в менеджере временных таблиц это не обращение к БД. Обычный параждающий запрос решит данную задачу без обращения к БД.
Во-вторых создание маааааленькой таблицы в памяти, объектно в менеджере временных таблиц это не обращение к БД. Обычный параждающий запрос решит данную задачу без обращения к БД.
(25) Вы специально читаете только то что хотите читать, а не то что написано?
Представьте, что у автора задача состоит в том, что бы построить такую таблицу месяцев, а потом по этой таблице построить отчет.
В этом случае вы создадите ТЗ. И не просто создадите, а с типизацией колонок. Займете место в памяти. Потом эту ТЗ так же передадите в менеджер временных таблиц и займете место в памяти там. А только потом начнёте по этим данным строить какой-то отчет.
Я писал про такую задачу. И если ТЗ далее где-то используется таким образом, то нет смысла её где-то отдельно создавать - проще сразу в запросе. Я уже не знаю как разжевать.
Почему у меня возникла такое предположение. Автору понадобился не список месяцев, который можно в диалоге сразу использовать, а именно ТЗ.
Представьте, что у автора задача состоит в том, что бы построить такую таблицу месяцев, а потом по этой таблице построить отчет.
В этом случае вы создадите ТЗ. И не просто создадите, а с типизацией колонок. Займете место в памяти. Потом эту ТЗ так же передадите в менеджер временных таблиц и займете место в памяти там. А только потом начнёте по этим данным строить какой-то отчет.
Я писал про такую задачу. И если ТЗ далее где-то используется таким образом, то нет смысла её где-то отдельно создавать - проще сразу в запросе. Я уже не знаю как разжевать.
Почему у меня возникла такое предположение. Автору понадобился не список месяцев, который можно в диалоге сразу использовать, а именно ТЗ.
(28) Зачем я представил - уже писал. Мне не понравился тип данных, который автору понадобился на выходе.
Ему в ответе сразу не ТЗ нарисовали, а список значений, как если бы данные ему необходимы были для какой-то диалоговой формы например. Но автору же на выходе нужна была именно ТЗ. Вот и возник вопрос "Зачем?".
Ему в ответе сразу не ТЗ нарисовали, а список значений, как если бы данные ему необходимы были для какой-то диалоговой формы например. Но автору же на выходе нужна была именно ТЗ. Вот и возник вопрос "Зачем?".
(15) Я не разрабатываю типовой ЗиУП. У меня вообще много вопросов к реализации, что 2.1, 2.5, 3.0 и 3.1 версии. Более того вообще много вопросов к РР.
В ЗиУП часто данные таскают менеджерами временных таблиц, так как сама решаемая задача в ЗиУП достаточно сложная и сразу необходимо много разных данных иметь под рукой и для разных объектов расчета (Сотрудников) по разным ВР, которые друг от друга ещё и зависят...
Есть как есть. Ничего простого в ЗиУП быть не может по определению.
В ЗиУП часто данные таскают менеджерами временных таблиц, так как сама решаемая задача в ЗиУП достаточно сложная и сразу необходимо много разных данных иметь под рукой и для разных объектов расчета (Сотрудников) по разным ВР, которые друг от друга ещё и зависят...
Есть как есть. Ничего простого в ЗиУП быть не может по определению.
(37) Что такое "февраль, март, апрель, май" для работы с данными, без указания года?
Элементарно при анализе продаж по месяцам сравнивают не просто продажи за разные месяцы, но и месяца по годам. Кто-то складывает все январи за какой-то период, не все "августы", так как за какой-то год август не попал в период? Никто этим не занимается.
Любой из этих месяцев не просто строка название месяца, а вполне конкретный период времени с датой начала и датой окончания. Представление этого периода может быть любым - хоть по Китайски иероглифами. Но период вполне определённый.
Элементарно при анализе продаж по месяцам сравнивают не просто продажи за разные месяцы, но и месяца по годам. Кто-то складывает все январи за какой-то период, не все "августы", так как за какой-то год август не попал в период? Никто этим не занимается.
Любой из этих месяцев не просто строка название месяца, а вполне конкретный период времени с датой начала и датой окончания. Представление этого периода может быть любым - хоть по Китайски иероглифами. Но период вполне определённый.
(30) Ну не знаю вроде GPTChat более менее нормально отрабатывает
Функция Название Месяца(ДатаНач, ДатаКон) Экспорт
// Получаем номер месяца из даты начала
НомерМесяцаНач = Месяц(ДатаНач);
// Получаем номер месяца из даты конца
НомерМесяцаКон = Месяц(ДатаКон);
// Проверяем, что даты находятся в одном году
Если Год(ДатаНач) <> Год(ДатаКон) Тогда
Возврат "Невозможно определить месяц между датами, так как они находятся в разных годах.";
КонецЕсли;
// Составляем список названий месяцев
СписокМесяцев = Новый СписокЗначений;
СписокМесяцев.Добавить("Январь");
СписокМесяцев.Добавить("Февраль");
СписокМесяцев.Добавить("Март");
СписокМесяцев.Добавить("Апрель");
СписокМесяцев.Добавить("Май");
СписокМесяцев.Добавить("Июнь");
СписокМесяцев.Добавить("Июль");
СписокМесяцев.Добавить("Август");
СписокМесяцев.Добавить("Сентябрь");
СписокМесяцев.Добавить("Октябрь");
СписокМесяцев.Добавить("Ноябрь");
СписокМесяцев.Добавить("Декабрь");
// Определяем порядковый номер первого месяца
ПорядковыйНомерПервогоМесяца = Макс(1, НомерМесяцаНач);
// Определяем порядковый номер последнего месяца
ПорядковыйНомерПоследнегоМесяца = Мин(12, НомерМесяцаКон);
// Формируем список месяцев между заданными датами
СписокМесяцевМеждуДатами = Новый СписокЗначений;
Для НомерМесяца = ПорядковыйНомерПервогоМесяца По ПорядковыйНомерПоследнегоМесяца Цикл
СписокМесяцевМеждуДатами.Добавить(СписокМесяцев[НомерМесяца]);
КонецЦикла;
// Возвращаем список месяцев через запятую
Возв
ПоказатьПрикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот