Андрей Шамин

1. Рекомендую сначала написать модуль и продать его. Далее, если удасться продать модуль более чем одному заказчику, то уже задуматься об оформлении интеллектуальной собственности (ИС).
2. ИС рекомендую оформлять на организацию, а не на физлицо.
3. Оформление ИС на программу ЭВМ занимает 4 часа работы - заявка заполняется онлайн и подписывается ЭЦП при наличии, ну или в бумажном виде. Через 2 мес вам выдадут свидетельство.
4. Чтобы продавать программный продукт вовсе не обязательно иметь свидетельство. Ваше право на программу ЭВМ возникает в момент создания программного продукта, а не в момент регистрации. Не все юристы это знают, поэтому и требуют на каждом шагу свидетельство.
5. Госпошлина - порядка 4к руб. Срок 2 мес.

Удачи!

Для документа создаем реквизит ДатаСоздания
В модуле объекта (документа) пишем код:

Если ЭтоНовый() Тогда
		ДатаСоздания = ТекущаяДата();
	КонецЕсли;

Код будет работать для новых документов.

В текущей постановке вопроса - без остановки базы - никак.
Однако, если определить требования простоя, то возможно.
Например, простой базы 60 минут недопустим. В то время как простой базы 5 мин для обновления вполне приемлем.
Если допускается простой для обслуживания в 5 мин, то в этот интервал можно уложиться.

Что такое обновление базы 1С.
В процессе обновления выполняется накатывание нового кода, а также реструктуризация базы. Накатывание кода происходит быстро.
Основное время обновления занимает реструктуризация ИБ.
Вопрос в том - как сократить время реструктуризации ИБ.
Не каждое обновление затрагивает таблицы базы данных. Поэтому не каждое обновление будет долгим.
Рассмотрим случай, когда внесли изменение в большую таблицу.
Выполнение реструктуризации средствами 1С процесс долгий. Сначала создается новая таблица с новой структурой. Далее в эту новую таблицу перекладываются записи (по одной!) из старой таблицы. Мощность оборудования мало что решает при таком подходе. Какие бы мощные сервера не были, они не могут сильно ускорить процесс перекладывания записей "по одной".
Решение:
1. Организационное. Заранее определять "тяжелые" и "легкие" релизы. Т.е. релизы, которые затрагивают тяжелые таблицы, и которые не затрагивают.
2. Технические. Не вносить изменения в существующие поля "тяжелых" таблиц, а только добавлять новые поля, сбоку. При таком подходе можно вмешаться в процесс реструктуризации ИБ.
Дело в том, что когда вы добавляете новое поле, то 1С все-равно выполняет реструктуризацию, даже, если это поле пустое. Такая 1С-ка "тупая". Ничего не поделаешь. Однако это можно компенсировать при работе на уровне СУБД. На этапе реструктуризации можно подменять имена таблиц таки образом, что 1С-ка будет реструктуризировать пустую таблицу. Далее заменять таблицу обратно. Например:
Дано:
Таблица - А - большая и тяжёлая
В таблицу А добавили новое поле АБ
Задача:
Надо выполнить реструктуризацию таблицы А максимально быстро.
Решение:
На уровне скуля переименовываем таблицу А в _А
Включаем реструктуризацию 1С
Реструктуризация создает недостающую таблицу А в соответствии с конфигурацией
Перекачиваем данные из _А в А средствами СУБД - на уровне скуля это делается максимально быстро.
Запускаем 1С, убеждаемся в работоспособности данных
Удаляем _А

Как-то так.

P.S. Динамическое обновление НЕ советую применять никогда.

В общем случае задачу обмена 1С с сайтом можно решить так.
На стороне 1С:
1. Создаем ПланОбмена и включаем в состав плана обмена объекты, изменения которых требуется выгружать на сайт
2. Создаем РегламентноеЗадание, которое раз в сутки или чаще запускает процесс обмена данными с сайтом
3. Пишем код на 1С, который забирает из ПланаОбмена новые зарегистрированные изменения, сереализует их в заданный формат - XML или JSON, и отправляет на сервер сайта через HTTPS-запрос.
4. После успешной выгрузки данных на сайт получаем от сайта номер квитанции, которая ранее была отправлена на сайт. По номеру квитанции снимает с регистрации изменения на плане обмена, т.к. они подтверждены сайтом как принятые.

На стороне сайта:
1. Реализуем REST API для взаимодействия с 1С - чтобы 1С могла через HTTPS-запросы отправлять и получать данные.
2. Реализуем таблицу для хранения квитанций для ПланаОбмена 1С
3. Реализуем парсинг полученных данных из XML или JSON
4. Реализуем запись в базу полученных данных

PS На стороне 1С можно обойтись и без ПлановОбмена и выгружать данные выборкой запросом
Соответственно можно обойтись и без квитанций, т.к. это сущность для ПланаОбмена
Можно выгружать по одному объекту и снимать его с регистрации в ПланеОбмена сразу после 200 от сайта.

Вариантов много. Зависит от задачи и требований.