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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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