Андрей: все верно. Кстати, можете объединить оба подхода. При появлении события изменения одного из нужных вам справочников проверяете возможность выполнить обмен, получаете всю регистрацию и отправляете на сайт (вместо работающего по расписанию регламентного задания).
Андрей: и я вас поздравляю. Видел очень многих, которые проходили сертифицированные курсы на программистов 1С, но после этого все равно оставались "дуб дубом". Все что вы пишите для них было бы полной тарабарщиной.
Андрей: На счет "нельзя" я не говорил. Еще в прошлом диалоге я отмечал, что можно сделать подписку на события. Т.е. записался какой-то справочник (не важно какой - поставить источником все нужные вам справочники системы) и тут же формируете пакет на отправку. Только в этой схеме план обмена будет лишний (разве что в разрезе узла хранить настройки подключения к одному из множества сайтов, с которыми вы обмениваетесь). Планы обмена как раз и придумали для того, что бы "редко да метко", а не для поддержки в актуальном состоянии одной единственной удаленной системы.
Андрей: справка - встроенный Синтаксис-Помощник, желтые книги "Руководство разработчика" (были вложена в коробку, если вы такую купили; возможно в виде pdf вложены в бесплатную поставку, которую можно скачивать с сайта 1С) и самая великая книга "библия" для всех программистов 1С - v8.1c.ru/metod/books/book.jsp?id=401
vendettametal: только для УТ10, которая у вас применяются обычные формы, а не управляемые. Если вы явно не переставили свойство конфигурации в совместное использование двух видов форм и явно не стали делать управляемые формы для ваших документов, то для вас путь красить строки только программный (первый вариант).
Настроить "План обмена" на отправку у вас не получится - это, грубо говоря, таблица для регистрации свежих изменений по отслеживаемым объектам в системе в целях уменьшения объема синхронизации. Хотя его событийная модель позволяет при регистрации делать еще какие-то другие действия. Можно их сразу же отправлять (или по заполнению некоторого буфера) на ваш веб-сервис и при получении подтверждения делать очистку. Получается альтернатива подписке на события только с приятным бонусом - в подписке вы знаете только про объект, который инициировал событие, а тут с помощью специальной обработки можно самому регистрировать произвольные объекты для "ручной выгрузки". Обработка регистрации встроена в большинство конфигураций, а для самописок ее можно взять с диска/сайта ИТС.
Все зависит от целей. Обычно создают константы. Если внешних приемников несколько и каждый со своими настройками, то создают справочник с настройками. Если нет желания, что бы какой-то хитрый манагер полез консолью отчетов в базу и узнал все пароли, то или прописывают прямо в коде (но это не гибко, так как при изменении пароля нужно код менять), или хранят в настройках пользователя, под которым проходит обмен.
Андрей: План обмена позволяет описать внешние по отношению к текущей базе 1С сущности. Это могут быть базы филиалов, или мобильные устройства сотрудников или сайт. При создании плана обмена указываются виды данных, которыми предполагается обмениваться. Далее при внесении изменений в каком-то справочнике (в тех же сотрудниках), этот элемент регистрируется на отправку в узлы (экземпляры данного плана обмена). Потом при обмене с конкретным узлом все объекты, которые зарегистрированы на отправку в него будут выгружены в XML-файл, а в свойствах узла счетчик выгруженных пакетов увеличиться на единичку. Если в рамках обмена приходит "квитанция о получении", то регистрация элементов в узле очищается (кроме тех, которые зарегистрировались между отправкой и получением обратного ответа); если обратной связи не было, то данные считаются потерянными в пути и при последующем обмене выполняется новая попытка их выгрузить.
Это стандартный механизм, которым можно пользоваться сразу же после создания в конфигураторе нового плана обмена. Если применить фантазию и навыки программирования, то можно сделать много чего полезного. К примеру, регистрировать не всех сотрудников для отправки в удаленный филиал, а только тех, которые работают в этом филиале и руководство компании; для отправки на сайт регистрировать только те товары, которыми предполагается он-лайн торговля (а вовсе не запчасти, бензин, бумагу для принтеров и прочие расходники ежедневной деятельности). Так же достаточно использовать узлы плана обмена в качестве регистратора изменений, а сами пакеты на отправку и получение формировать своими силами - это позволит отойти от XML-файликов к другим каналам коммуникации - к примеру, к отправке по веб-сервису файлов JSON.
agent1156: вы же в курсе, что 1С бесплатно раздает в учебных целях платформу для самостоятельного изучения вместе с учебной литературой и демонстрационными материалами? Начните от сюда - https://online.1c.ru/catalog/free/learning.php
ASDF13: обманчивый тренд, но выбор делать только вам.
У 1С есть еще большой запас для роста и ниши из которых она будет вытрясать конкурентов - в конце конов это не просто язык или платформа, но еще и целая экосистема. А какие перспективы для распространения PHP помимо занятых ниш? А на ноги наступают erlang, go и прочие серверные языки, не говоря про моностек JavaScript с их серверным движком Node.js
Дмитрий: менее болезненным будет выбрать то, что знаете. Если не знаете обе системы, то поставьте демо-базы и просто прощелкайте документы и отчеты. УТ10 более похожа на торговые решения 7.7, но УТ11 более функциональная и именно она будет развиваться (для УТ10 будут только делать косметические правки под изменения законодательства).
АртемЪ: т.е. ваше предложение в поднятии в локалке своего NS-сервера, который бы по имени интернет шлюза (1cserver.rogaIkoputa.ru) направлял бы на адрес реального сервера 1С в локалке? Это действительно удобнее чем делать записи в hosts на компах клиентов, но при наличии других сервисов в сети, которые находятся на других компьютерах локалки может привести к другим проблемам админу (собственно из-за этого мы даже не стали думать в таком направлении, а еще у нас доменное имя изменялось). Но в целом, идея хорошая :)
АртемЪ: не совсем понял как может помочь редактирование DNS, что бы с любой точки интернета попасть по netbios-имени либо по локальному айпишнику (в зависимости от настроек главного узла кластера) на шлюзовый сервер, который светит в интернет.
АртемЪ: условно работает, но далеко не "прекрасно"!
Сервер передает свое имя для колбека и когда кто-то из интернета пытается подключится к условному серверу 1c.server.com , где настроен форвардинг портов 15** на сервера Server1C в его локальной сети, то выдается ошибка "Server1C не найден". Разве что каждому из клиентов прописать в файле hosts названию Server1C ай-пишник сервера, который светит в интернет - то такой путь действительно работает, но мы отказались от этой идеи, так как админить домашние компы удаленных сотрудников очень сложно и проще пустить через remoteApp.