iebelokamentsev / 1c-workout Goto Github PK

Бумага в дефиците, поэтому хочу счётчик печати.
Чтобы был отчёт, который покажет: кто, когда, из каких документов и какие печатные формы формировал.

В УПП есть документ "ЗаказПокупателя", у него есть форма списка. Нужно добавить там колонку, в которой будет отображаться % отгрузки заказа. Процент считать по сумме.

Ну типа есть заказ был на 100 рублей, а отгрузили на 35 рублей, то % отгрузки = 35%.

Только учтите, господа программисты: у нас заказы ведутся с 2010 года. Очень здорово будет, если форма списка не будет вставать колом.

Нужен механизм прекращения деятельности контрагентов. Типа мы вот знаем, что контрагент больше не работает, и нам это надо как-то в системе отметить. Что важно: деятельность прекращается с определённой даты.

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

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

У нас БП3, есть программисты, и мы хотим ставить им задачи прямо в программе.

1. Пусть будет какой-то инструмент постановки задачи, чтобы там можно было написать текст, поставить срок, и чтобы автор задачи сохранялся;
2. Пусть программисты отмечают, когда приняли задачу в работу и указывают конкретного исполнителя из своих рядов;
3. Они у нас шутники, могут поставить кладовщика исполнителем - надо, чтобы могли только программиста;
4. Надо, чтобы принимать в работу и ставить исполнителя тоже могли только программисты. И чтобы не могли принять, не указав исполнителя;
5. Когда сделают, пусть ставят галку какую-нибудь, типа сделали и пишут комментарий, где что смотреть;
6. А у автора задачи пусть будет своя галка, типа "результат принят";
7. Ну и чтобы удобные списки были: "Задачи от меня" (для авторов), "Задачи принять" (для программистов), "Задачи проверить" (тоже для авторов), ну и общий список без фильтров.

В нашей УПП единственный живой регистр по товарам - "ТоварыНаСкладах". Там все данные настоящие, и мы можем им доверять.

Руководство поставило задачу: выцепить и отслеживать неликвиды (это товары, которые очень давно лежат без движения, в смысле поступили на склад и ни туда, ни сюда).

Был бы у нас партионный учёт - конечно бы по нему посмотрели, там же есть документ партии, и можно от его даты до сегодняшнего дня посчитать время "лежания" товара. Но, увы, только "ТоварыНаСкладах".

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

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

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

Хотим запретительный механизм, которые позволит нам указать:

1. Пользователя, которому мы хотим запретить менять реквизиты;
2. Документ или справочник, в котором хотим запретить;
3. Перечень реквизитов, которые нельзя менять (для каждого пользователя и документа/справочника этот перечень будет своим).

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

В УПП есть такая штука, как партионный учёт - формирование движений по регистрам накопления, в названии которых присутствует "ПартииТоваровНаСкладах...". В типовой конфигурации движения по этим регистрам формируются стандартно, при проведении документа, в той же транзакции.

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

Нужно сделать отчёт по себестоимости кассовым методом в УПП.

Себестоимость кассовым методом считается очень просто: это приход денег минус расход денег. Что в итоге получилось - и есть себестоимость.

Правда, мы хотим сделать этот расчёт сценарным, т.е. считать по разным моделям.
Модель - это сохранённый заранее перечень статей движения денежных средств, отдельно по приходу, отдельно по расходу.

Ну типа есть у нас модель "Оптимистичная" - там будет один набор статей, модель "Пессимистичная" - там другой набор статей. Может ещё какие модели придумаем - нам нужен, получается, какой-то инструмент настройки и хранения моделей.

В отчёте хотим выбирать модель и период.

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

Вот пусть отчет покажет, чего и сколько нам не хватает.

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

Нужно сделать инструмент, который будет фиксировать просмотр всех документов. Чтобы была информация кто, когда и какой документ смотрел.

У нас 100%ный входной контроль всех товаров и материалов, которые мы покупаем. Прям каждую позицию тащим на ОТК и проверяем.

Результаты проверки надо куда-то вносить. Только не в документ поступления - не хотим давать на него права ОТК. Что-то своё им надо. Для каждой позиции поступления они должны будут поставить количество годной и количество бракованной продукции.

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

В нашей любимой БП всё хорошо, даже есть отчёт "Продажи". Но в нём нет цен, только количество и сумма. Приходится копировать, вставлять в эксель, добавлять колонку... Ужас.

Сделайте, пожалуйста, отчёт "Продажи" с ценами (сумма / количество).

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

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

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

Да, и справки эти мы хотим писать в режиме предприятие. И чтобы красиво было, как в обычных справках - с картинками, жирным шрифтом и т.д.

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

Но жизнь чуть сложнее. У нас есть СБ, которая хочет контролировать отгрузки. Точнее, разрешать отгрузку по конкретному заказу - у них там какие-то свои проверки, критерии, это нас не интересует (всё равно не узнаем).

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

Внутри разрешения пусть будут дата (она может отличаться от даты отгрузки), номер (его потом пишут вручную на пропуске), кто согласовал (ФИО).

При этом нельзя давать права СБ на изменение заказов и реализаций - они сами попросили. Типа а то вдруг случайно испортим.

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

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

Как нам кажется это примерно должно выглядеть:

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

Мы - завод. У нас есть ЕРП. И ещё - программисты, которые постоянно что-то конопатят.
Мы очень хотим знать, что именно они там делают, какие документы, отчеты, регистры, справочники и т.д. - и создают, и дорабатывают, и, главное, во сколько нам всё это обходится.

Как примерно видим себе эту штуку:

1. Пусть у программистов будет какая-то хрень, в которой они будут указывать, что (какой именно объект) они создали, доработали в конкретный день.
2. Пусть там же будет фамилия программиста и потраченные часы, и какой-то комментарий, что именно программист делал;
3. Ой, а пусть ещё будет фамилия заказчика, внутреннего нашего. Ну там тётя Дуся из бухгалтерии, или кто эту штуку заказал;
4. Где-то отдельно мы должны ввести стоимость часа каждого программиста. Вообще, у них оклады, но они разные, и мы пересчитаем стоимость часа и вобьём;
5. Ну и отчёт, отчёт конечно! Хотим видеть количество часов и стоимость доработки объектов конфигурации! И по программистам, и по объектам, и по заказчикам!

Мы - компания активная. Наши сотрудники постоянно вносят предложения по развитию компании, но всё где-то вечно теряется, застревает, не реализуется. Хотим упорядочить этот процесс. Учёт мы ведём в УНФ, пусть там и предложения по развитию живут. Без изменения типовой конфигурации, разумеется.

Итак:

1. Пусть будет какая-то штука для подачи предложения. Любой пользователь системы может написать свою идею, изложить суть и всё, что посчитает нужным;
2. Пусть будет какая-то "каста" пользователей, которые могут выносить вердикт относительно предложения - надо ли его реализовывать. Любой из "касты" может как-то указать в предложении, что оно отклонено (и обязательно должен написать, почему) или принято;
3. Если предложение принято, то принявший это решение должен сразу указать конкретного исполнителя предложения;
4. Должна быть какая-то форма с разными списками предложений: "я - автор", "я - исполнитель", "предложения в работе", "отклонённые предложения", и просто общий список.
5. Когда исполнитель реализует предложение, пусть ставит соответствующую отметку и пишет комментарий, что конкретно сделано.
6. Ну и нужен отчёт, который покажет предложения по авторам и исполнителям, чтобы мы могли его настраивать. Например, посмотреть в разрезе авторов количество и суть предложений, или в разрезе исполнителей. И пусть там можно будет выбирать период отчёта - или по дате подачи предложения, или по дате его исполнения.

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

Хотим это дело автоматизировать:

1. Нужен перечень книг - с названием, автором и аннотацией (Ксюша вобьёт);
2. Нужен какой-то механизм выдачи и возврата книг, по сотрудникам;
3. Конечно, нужен отчёт, который покажет, у кого какая книга сейчас находится (книги "на полке" он тоже должен показать);
4. Ну и нужен отчёт, который покажет злостных должников - тех, у кого книга находится на руках более месяца.

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

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

У нас инженерное предприятие - чертим чертежи, по ним изготавливаем продукцию. Учёт ведём в БП3. Хотим и учёт чертежей организовать.

1. Нужно где-то хранить в системе эти чертежи. В принципе, достаточно длинного наименования - туда же и код чертежа вставим;
2. Нужно как-то привязывать чертежи к номенклатуре (на чертежах же номенклатура продукции начерчена). Чтобы и из чертежа в номенклатуру можно было провалиться, и наоборот;
3. На конкретную номенклатуру чертёж может меняться, т.е. был один, стал другой;
4. Один чертёж не может быть назначен двум номенклатурам;
5. Ещё к чертежам бывают извещения, эти типа изменения в чертежах. Надо где-то их тоже хранить, в привязке к конкретным чертежам, чтобы можно было из чертежа в них провалиться;
6. Нужен отчёт, который покажет номенклатуру без чертежей;
7. Нужен отчёт, который покажет чертежи, не привязанные к номенклатуре.

Конфигурация, разумеется, должна остаться без изменений.

Создать в УПП документ "Дефицит", в котором будет собираться информация о позициях номенклатуры, которые надо купить.

Работает просто:

1. Берёт неотгруженные заказы покупателей;
2. Добавляет невыполненные заказы на производство;
3. Вычитает остатки на складах;
4. Вычитает заказы поставщикам;
5. Что получилось в итоге - это и есть дефицит.

Дефициты нужны в разрезе номенклатуры.

Хотим учитывать принтеры и картриджи, у нас этого добра много, и вечный бардак.

Нужно, чтобы в системе был справочник принтеров и справочник картриджей.

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

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

Ну и хотим фиксировать снятие/установку картриджей на принтеры. Чтобы был отчёт, который покажет, на какой принтер установлен какой картридж.

Очень просто. Надо сделать внешнюю обработку, которая напечатает любой документ.

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

Сделать в общем интерфейсе УПП кнопку, по которой будет открываться форма списка метаданных - справочников, документов и т.д. (как в функциях технического специалиста). Выбираешь объект - открывается соответствующая форма. Например, при выборе документа, справочника, регистра открывается форма списка. Выбираешь отчёт или обработку - открывается форма отчёта или обработки.

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

Да, и список объектов должен быть в виде дерева, как в функциях технического специалиста. На первом уровне - тип (Документы, Справочники и т.д.), на втором - конкретные документы, справочники и т.д.

Делать в демобазе БП 3. Выбираешь любой документ, и делаешь в нём команды помещения в буфер и чтения из него. Команда должна быть универсальной, т.е. такой, чтобы её можно было скопировать и прицепить к другому документу, не переписывая код.

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

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

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

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

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

Заходим, выбираем схему, жмём кнопку, данные выгружаются в файл в формате JSON.
Ссылки, естественно, не должны выгружаться в виде представлений.

Есть в УПП документ "Заказ покупателя". У него есть ТЧ "Товары". Надо сделать так, чтобы там отображались текущие остатки товара на всех складах. Остатки лежат в регистре накопления "ТоварыНаСкладах".

Например, заходишь в старый заказ покупателя - видишь остатки.
Или создаёшь новый заказ, добавляешь строку товаров, выбираешь номенклатуру - показывается её остаток. Меняешь номенклатуру - остаток обновляется.

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

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

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

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

У нас такое дело: торгуем одним и тем же товаром, продаём одним и тем же клиентам, почти не меняя количества и цены. Соответственно, каждый раз ищем подходящий прошлый заказ клиента, копируем, заполняем... Долго и неудобно.

Нам бы такой механизм, такой механизм... Чтобы можно было как-то назначить конкретные заказы типа как шаблонами. Ну там с десяток их будет, может. Каждому какой-нибудь комментарий напишем.

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

Хотим ограничивать продажи по количеству, в день.

Ну, чтобы мы такие указали конкретную номенклатуру, и что не больше 10 штук за день в одни руки, и программа не даст отгрузить больше одному контрагенту.

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

Бывает так: на остатках по материальным складским счетам (10, 21, 41, 43 и т.д.) зависают суммы без количеств. Они бывают отрицательные, положительные, большие, маленькие. Они считаются проблемой - это ж числится товар на складе, но в нулевом количестве, однако чего-то стоит, в деньгах.

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

Девать их можно в следующие места (в порядке убывания приоритета):

1. Идеально - найти ту же номенклатуру, но с нормальным количеством, на другом складе, и перекинуть сумму на неё;
2. Если п.1 не сработал, то раскидать на всю номенклатуру того же склада, пропорционально суммовым остаткам других номенклатур (чтобы было не заметно);
3. Если и п.2 не сработал (например, на этом складе больше ничего нет, кроме нашей ошибочной номенклатуры), то раскидать на всю номенклатуру всех складов, по тому же принципу.

Хочу внешнюю обработку, которая будет запускать любую доступную процедуру или функцию в фоновом задании.

На форме обработки должно быть возможно ввести:

1. Имя модуля и процедуры/функции;
2. Произвольное количество параметров (мы ж не знаем, сколько их там, у процедуры/функции). Количество параметров и типы - на совести пользователя.
3. Потом кнопка "Запустить", которая запускает выполнение фонового задания. Дальше обработка должна следить за выполнением фонового задания и сообщить, когда оно будет выполнено, отменено или завершено с ошибками.
4. Если в процессе выполнения фонового задания будут сообщения пользователю - их надо выводить.

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

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

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

Видим это так:

1. Нужен справочник туалетов;
2. Нужен документ, в который мы перебьём данные из СКУД, кто ходил в туалет. Туалет пусть указывается в шапке, а в табличной части - перечень людей и количество посещений для каждого;
3. Нужен справочник туалетных принадлежностей (бумага, мыло, полотенца и т.д. - сами вобьём);
4. Нужен документ расхода туалетных принадлежностей по дням, в разрезе туалетов. В шапке указываем туалет, в таблице - туалетные принадлежности с количеством и стоимостью;
5. Ну и главное - отчёт, который распределит п.4 на п.2 и покажет, кто сколько чего "употребил", в количестве и стоимости. Распределять тупо по количеству посещений конкретного туалета в конкретный день.

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

Что требуется:

1. Создать некий документ "Заказ канцелярии", который будут оформлять сотрудники, указывать номенклатуру и количество канцелярии. Документ оформляется от имени конкретного подразделения;
2. Люди не должны видеть чужие документы заказа канцелярии;
3. В документе должна быть возможность утверждения - это делает офис-менеджер. После утверждения никто не может менять документ;
4. При этом, у офис-менеджера должна быть возможность отметить документ, как выполненный. Сделать это можно только после утверждения;
5. Нужен отчёт, который покажет общий список заказанной утверждённой канцелярии по ещё не выполненным заказам.

У нас частенько проводятся точечные ревизии на складах. При этом важно, чтобы во время ревизии никаких операций по складу в УПП не отражалось. Ревизия может длиться от пары часов до нескольких дней.

Хотим, чтобы в УПП появилась возможность организовать такой запрет. Как примерно представляем себе этот механизм:

1. Мы где-то указываем, с какой даты и времени и до какой даты и времени действует запрет на конкретный склад;
2. В этом интервале времени никакие документы по складу не могут проводиться и распроводиться. Нас интересует только оперативный контур (количественный учёт, который мы видим в отчёте "Товары на складах");
3. Если ревизия вдруг отменится, сократится или продлится по времени - хотим иметь возможность быстро скорректировать или вообще удалить данные, введённые в п.1.

Конечно, хотелось бы, чтобы типовые объекты остались без изменений.

Нужно сделать отчёт "Товары на складах" для бухгалтерии предприятия. Отчёт должен содержать группировки Склад, Номенклатура, и ресурсы Начальный остаток, Приход, Расход, Конечный остаток (все ресурсы - про количество).
Как мы знаем, в БП нет РН для хранения товародвижения, всё лежит в регистре бухгалтерии. Вот оттуда и надо брать.

При этом мы не знаем точного списка счетов учёта, по которым надо брать данные. Потому что он постоянно меняется. Будем считать, что нам нужны счета, у которых ровно три субконто - "Номенклатура", "Склады" и "Партия". Вычисление перечня этих счетов должно происходить при формировании отчёта (т.е. их нельзя определять жёстко или заставлять пользователя их вводить).

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

Ну и кнопка какая-то, которая:

1. Почистит все движения корректировки регистров, если какие-то были;
2. Поднастроит корректировку, чтобы у неё были движения только по выбранному нами регистру;
3. Возьмёт все остатки по выбранному регистру и спишет их, создав соответствующие движения у корректировки.

Сделать расширение для ЕРП - автозаполнятор реквизитов документов.

Думаю, там должен быть регистр сведений, в котором мы сможем указать:

1. Имя документа (например, "ЗаказКлиента");
2. Имя реквизита (например, "Комментарий");
3. Значение реквизита (например, "Создан мной!").

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

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

В УПП есть прекрасный механизм - "Произвольные отчёты". А в ЕРП такого нет. И это беда.
Хотим такой же, хоть примерно, в ЕРП.

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

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

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

Сделать отчёт/обработку, которая покажет, какие помеченные на удаление ссылки в базе нельзя удалить, потому что на них есть ссылки. Ну и, соответственно, скажет, где есть ссылки на указанные объекты.

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

В УНФ есть прекрасный отчёт, называется "Задолженность покупателей по срокам долга" (правда, имя у него другое - "РеестрСтаренияДебиторскойЗадолженности"). Этот отчёт показывает, как давно возникла задолженность покупателя, просрочена она уже или нет, как-то делит эту задолженность по интервалам.

Сроки задолженности он определяет по договору - в нём можно указать, сколько дней отводится на оплату. Соответственно, во всех документах по договору (заказы, отгрузки) - один и тот же срок оплаты в днях.

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

Разумеется, наша вручную установленная дата должна отобразиться в отчёте.

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