Как в 1с включить режим mtom
Обновлено: 06.07.2024
В этом разделе рассматриваются сведения о реализации WCF для следующих протоколов, которые TextMessageEncodingBindingElement и MtomMessageEncodingBindingElement используются.
В этом разделе рассматриваются сведения о реализации WCF для следующих протоколов, которые MtomMessageEncodingBindingElement используют.
В этом разделе используются следующие пространства имен XML и соответствующие префиксы:
SOAP 1.1 и SOAP 1.2
Конверт и модель обработки
WCF реализует обработку конверта SOAP 1,1, следующую за базовым профилем 1,1 (BP11) и Basic Profile 1,0 (SSBP10). Обработка конверта SOAP 1.2 реализована в соответствии со спецификацией SOAP12-Part1.
В этом разделе объясняются некоторые варианты реализации, принимаемые WCF в отношении BP11 и SOAP12-Part1.
Обработка обязательных заголовков
WCF соответствует правилам обработки заголовков mustUnderstand , помеченных в спецификациях soap 1,1 и soap 1,2, со следующими вариантами.
Такая многоуровневая обработка обеспечивает разделение уровней инфраструктуры и уровней приложения узла SOAP:
B1112: WCF выдает mustUnderstand значения 0 и 1 для версий soap 1,1 и soap 1,2 конверта SOAP. WCF принимает все пространство значений xs:boolean для mustUnderstand заголовка (0, 1, false , true )
Ошибки SOAP
Ниже приведен список реализаций ошибок SOAP, зависящих от WCF.
B2121: WCF возвращает следующие коды ошибок SOAP 1,1: s11:mustUnderstand , s11:Client и s11:Server .
B2122: WCF возвращает следующие коды ошибок SOAP 1,2: s12:MustUnderstand , s12:Sender и s12:Receiver .
R2221: параметр действия application/soap+xml , если он присутствует в запросе SOAP 1.2, должен соответствовать атрибуту soapAction элемента wsoap12:operation в соответствующей привязке WSDL.
WS-Addressing
WCF реализует 3 версии WS-Addressing:
W3C Web Services Addressing 1.0 Core (ADDR10-CORE) и SOAP Binding (ADDR10-SOAP)
WS-Addressing 1.0 ― метаданные
Ссылки на конечные точки
Все версии WS-Addressing, которые WCF реализует, используют ссылки на конечные точки для описания конечных точек.
Ссылки на конечные точки и версии WS-Addressing
WCF реализует ряд протоколов инфраструктуры, использующих WS-Addressing и в частности EndpointReference элемент и W3C.WsAddressing.EndpointReferenceType класс (например, WS-RELIABLEMESSAGING, WS-SECURECONVERSATION и WS-Trust). WCF поддерживает использование любой из версий WS-Addressing с другими протоколами инфраструктуры. Конечные точки WCF поддерживают одну версию WS-Addressing на каждую конечную точку.
Например, если конечная точка WCF реализует WS-ReliableMessaging, AcksTo заголовок, возвращаемый такой конечной точкой в, CreateSequenceResponse использует версию WS-Addressing, которую EncodingBinding элемент определяет для этой конечной точки.
Ссылки на конечные точки и метаданные
В ряде сценариев требуется передача метаданных или ссылки на метаданные для определенной конечной точки.
B3121. WCF использует механизмы, описанные в разделе 6 спецификации WS-MetadataExchange (MEX), чтобы включить метаданные для ссылок на конечные точки по значению или по ссылке.
Параметры и свойства ссылок
WCF реализует обработку параметров ссылки на конечную точку и ссылочные свойства в соответствии с соответствующими спецификациями.
B3221: Если настроено использование WS-Addressing 2004/08, конечные точки WCF не различают ссылочные свойства и ссылочные параметры.
B3312: запрашивающая сторона может включить заголовки MessageID , ReplyTo и FaultTo . Инфраструктура принимающей стороны не учитывает их, и они передаются в приложение.
Запрос-ответ
R3321: инициатор запроса должен включать в запрос wsa:To , wsa:Action , wsa:MessageID и заголовки для всех ссылочных параметров или ссылочных свойств (или обоих), указанных ссылкой на конечную точку.
R3322: если используется WS-Addressing 2004/08, в запрос также должен быть включен параметр ReplyTo .
Ошибки Web Services Addressing
R3411: WCF создает следующие ошибки, определенные WS-Addressing 2004/08.
R3412: WCF создает следующие ошибки, определенные WS-Addressing 1,0.
Код в предыдущих таблицах соответствует параметру FaultCode в SOAP 1.1 и параметру SubCode (с Code=Sender) в SOAP 1.2.
Привязка WSDL 1.1 и утверждения WS-Policy
Указание использования WS-Addressing
WCF использует утверждения политики, чтобы указать поддержку конечных точек для определенной версии WS-Addressing.
Это утверждение политики дополняет спецификацию WS-Addressing 2004/08.
Элемент wsaw10:UsingAddressing заимствован из [WS-Addressing-WSDL] и используется в контексте WS-Policy в соответствии с этой спецификацией, раздел 3.1.2.
Полный код утверждения политики может выглядеть следующим образом.
Полный код утверждения политики может выглядеть следующим образом.
Определение действия
Спецификация WS-Addressing 2004/08 определяет атрибут wsa:Action для элементов wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] . Привязка WS-Addressing 1.0 WSDL (WS-ADDR10-WSDL) определяет аналогичный атрибут, wsaw10:Action .
Единственное отличие между этими двумя атрибутами заключается в семантике шаблона действия по умолчанию, описанной в разделе 3.3.2 спецификации WS-ADDR и в разделе 4.4.4 спецификации WS-ADDR10-WSDL соответственно.
Разумно, чтобы две конечные точки имели одинаковый portType (или контракт, в терминологии WCF), но использовали разные версии WS-Addressing. Однако с учетом того, что действие определяется параметром portType и не должно изменяться между конечными точками, реализующими portType , одновременная поддержка обоих шаблонов действия по умолчанию становится невозможной.
Чтобы устранить эту споров, WCF поддерживает одну версию Action атрибута.
Использование ссылки на конечную точку внутри порта WSDL
Раздел 4.1 спецификации WS-ADDR10-WSDL расширяет элемент wsdl:port , включая в него дочерний элемент <wsa10:EndpointReference…/> для описания конечной точки в терминах WS-Addressing. WCF расширяет эту служебную программу на WS-Addressing 2004/08, что позволяет <wsa:EndpointReference…/> отображаться как дочерний элемент wsdl:port .
R3531: если к конечной точке прикреплена альтернативная политика с утверждением политики <wsaw10:UsingAddressing/>``wsdl:port .
R3532: Если объект wsdl:port содержит дочерний элемент <wsa10:EndpointReference …/> , wsa10:EndpointReference/wsa10:Address значение дочернего элемента должно соответствовать значению @address атрибута родственного wsdl:port / wsdl:location элемента.
R3533: если к конечной точке прикреплена альтернативная политика с утверждением политики <wsap:UsingAddressing/>``wsdl:port .
R3534: Если объект wsdl:port содержит дочерний элемент <wsa:EndpointReference …/> , wsa:EndpointReference/wsa:Address значение дочернего элемента должно соответствовать значению @address атрибута родственного wsdl:port / wsdl:location элемента.
Сочетаемость с WS-Security
Примеры
Кодировка XML и механизм упаковки, описываемый [XOP], который оптимизирует информационные элементы XML, содержащие двоичные данные в кодировке base64, в отдельные двоичные части.
Инкапсуляция MIME пакета XOP, которая сериализует набор сведений XML и каждую двоичную часть пакета XOP в отдельную часть MIME.
Кодирование MIME XOP, примененное к конверту SOAP 1.x.
В спецификации [XOP], раздел 3.1, описывается процесс кодирования XML с информационными единицами элемента, содержащими base64-значения, в абстрактно определенный пакет XOP.
Приведенная ниже последовательность этапов описывает специфичный для MTOM процесс кодирования.
Создайте пустой пакет MIME.
Определите в исходном наборе сведений XML информационные единицы элементов, подлежащие оптимизации. Для оптимизированных элементов символы, составляющие [children] элемент сведений об элементе, должны быть в канонической форме xs:base64Binary (см. xsd-2, 3.2.16 base64Binary) и не должны содержать пробелов, предшествующих, встроенных в или следующих за содержимым, не являющимся пробелом.
Создайте конверт XOP SOAP, являющийся копией исходного конверта SOAP, но в котором дочерние элементы всех информационных единиц элементов, определенных на предыдущем шаге, заменены информационной единицей элементов xop:Include , построенной следующим образом:
Преобразуйте замененные символы в двоичные данные, обработав их как данные в кодировке base64.
Создайте уникальное значение заголовка Content-ID, удовлетворяющее требованиям R3133 и R3134.
Создайте заголовок Content-Transfer-Encoding MIME со значением binary.
Если оптимизируемая информационная единица элемента ([parent] вновь вставленной информационной единицы xop:Include ) имеет информационную единицу атрибута xmime:contentType , создайте заголовок Content-Type MIME со значением атрибута xmime:contentType .
Создайте новую двоичную часть MIME с содержимым, образованным двоичными данными, декодированными из замененных символов, обработанных как base64, заголовка Content-ID из шага 4b, заголовка Content-Transfer-Encoding из шага 4c, заголовка Content-Type, если он создан в шаге 4d.
Добавьте атрибут href в элемент xop:Include со значением cid: uri, полученным из значения заголовка Content-ID, созданного на шаге 4b. Удалите вложенные символы " <" and "> ", URL-адрес, чтобы отключать оставшуюся строку и добавить префикс cid: . В соответствии с RFC1738 и RFC2396 в escape-последовательности должен преобразовываться указанный ниже минимальный набор символов. Возможно преобразование в escape-символы и других символов.
Создайте корневую часть MIME с конвертом XOP SOAP из шага 4.
Запишите пакет MIME.
Убедитесь, что корневая часть MIME имеет Content-Type application/xop+xml .
Постройте конверт SOAP, проанализировав корневую часть MIME пакета как документ XML. Кодировка символов определяется параметром charset заголовка Content-Type корневой части MIME.
Для каждой информационной единицы элементов в построенном конверте SOAP, которая имеет, как единственный член своего свойства [children], информационную единицу элемента xop:Include :
Удалите префикс cid: и выполните обратное преобразование из escape-представления всех escape-последовательностей универсального кода ресурса (URI) (RFC 2396) в значении атрибута @href элемента xop:Include . Заключите результирующую строку в " <", "> ".
Найдите часть MIME в значении заголовка Content-ID, соответствующую строке, полученной на шаге 3a.
Замените информационную единицу элемента xop:Include , имеющуюся в свойстве children каждой единицы, информационными единицами символов, представляющими каноническую кодировку base64 (см. XSD-2, 3.2.16 base64Binary) тела сущности части MIME, указанной в шаге 3b (эффективно это означает, что надо заменить информационную единицу элемента xop:Include данными, восстановленными из части пакета).
Хотя требование использовать двойные кавычки в RFC 2387 не является явным, текст следит, чтобы все составные или связанные параметры типа мультимедиа, скорее всего, содержали зарезервированные символы, такие как " @ " или "/", и поэтому требуют двойных кавычек.
Часть Infoset MIME
Конверт SOAP 1.x инкапсулируется как корневая часть пакета XOP MIME и часто называется частью infoset .
R4142: часть SOAP Infoset должна содержать следующие заголовки MIME: Content-ID , Content-Transfer-Encoding и Content-Type .
Формат заголовка Content-ID определяется в RFC 2045 как
где msg-id определяется в RFC 2822 (которая заменяет RFC 822, указанную в RFC 2045) следующим образом:
и фактически является адресом электронной почты, заключенным в " <" and "> ". Префикс и суффикс [CFWS] были добавлены в RFC 2822 для внесения комментариев и не должны использоваться, чтобы не нарушать совместимость.
R4143: значение заголовка Content-ID для части Infoset MIME должно задаваться в соответствии с правилами для msg-id из RFC 2822 без частей с префиксом и суффиксом [CFWS] .
Ряд реализаций MIME неограниченные требования для значения, заключенного в " <" and "> ", в качестве адреса электронной почты и используемого absoluteURI в " <" , "> " в дополнение к адресу электронной почты. В этой версии WCF используются значения заголовка MIME Content-ID в формате:
R4144: процессоры MTOM должны воспринимать значения заголовка Content-ID, соответствующие следующему ослабленному требованию к msg-id .
R4145: часть SOAP Infoset должна содержать заголовок Content-Transfer-Encoding.
R4147: если для конверта SOAP принята кодировка символов UTF-16, значение заголовка Content-Transfer-Encoding должно быть binary.
В соответствии с [XOP], раздел 5,
R4148: компонент информационного набора SOAP 1.1 должен содержать заголовок Content-Type с типом носителя Application/XOP + XML и параметрами Type = "Text/XML" и charset
R4149: часть набора сведений SOAP 1,2 должна содержать заголовок Content-Type с типом носителя application/xop+xml и параметрами Type = " application/soap+xml " и charset .
Хотя в XOP параметр charset для application/xop+xml определяется как необязательный, он необходим для совместимости, аналогично требованию BP 1.1 к параметру charset для типа носителя text/xml .
R41410: в заголовке Content-Type части SOAP 1.x Infoset должны присутствовать параметры type и charset .
Поддержка MTOM конечной точкой WCF
R4151: любая информационная единица элемента, содержащая данные в кодировке base64, может быть оптимизирована.
B4152: WCF оптимизирует элементы сведений об элементе, содержащие данные в кодировке Base64, и длину более 1024 байт.
Утверждение WS-Policy для MTOM
WCF использует следующее утверждение политики для указания использования MTOM по конечной точке:
B4212. Если настроено использование оптимизации MTOM, конечная точка WCF добавляет утверждение политики MTOM к политике, прикрепленной к соответствующему объекту wsdl:binding .
Сочетаемость с WS-Security
Примеры
Использование признака ОбменДанными.Загрузка в обработчиках событий объекта
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Все действия в процедурах-обработчиков событий ПередЗаписью, ПриЗаписи, ПередУдалением должны выполняться после проверки на ОбменДанными.Загрузка :
Процедура ПередЗаписью(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// код обработчика
// .
КонецПроцедуры
Это необходимо для того, чтобы никакая бизнес-логика объекта не выполнялась при записи объекта через механизм обмена данными, поскольку она уже была выполнена для объекта в том узле, где он был создан. В этом случае все данные загружаются в ИБ «как есть», без искажений (изменений), проверок или каких-либо других дополнительных действий, препятствующих загрузке данных.
Кроме механизма обмена данными есть и другие случаи, когда это должно быть так. В общем виде следует руководствоваться следующим подходом: механизмы, не рассчитанные на особенности конкретных конфигураций, должны иметь возможность загрузить данные при установленном флаге загрузки так, как будто текста обработчика нет вообще:
Например, требуется загрузить всю базу из XML «как есть». Для этого должно быть достаточно установить записываемым объектам ОбменДанными.Загрузка = Истина и все данные должны загрузиться без искажений, проверок и дополнительных действий, т. е. так же как и при пустом обработчике.
2. Исключение составляет механизм обмена данными, который в ходе загрузке данных в базу регистрирует эти данные к выгрузке на других узлах плана обмена.
В тех случаях, когда в конфигурации используется подсистема «Обмен данными» БСП, и возникла необходимость отключить ее, следует устанавливать дополнительное свойство ОтключитьМеханизмРегистрацииОбъектов :
В случае других исключений, причина исключения из этого правила должна быть описана в комментарии к выполняемым действиям.
3. Требования выше также распространяются на обработчики подписок на эти события.
4. При этом вызывающая сторона, выставляя записываемому объекту признак ОбменДанными.Загрузка в Истина , берет на себя ответственность за целостность данных этого объекта.
Например, при записи объекта через механизм обмена данными в РИБ это обеспечивается корректным состоянием объекта в том узле, где он был создан (или изменен).
В других случаях вызывающая сторона должна принять меры по корректному заполнению записываемого объекта. Например, при загрузке данных через механизм обмена данными по правилам конвертации или с помощью формата EnterpriseData, следует выполнять все необходимые действия по (до)заполнению объекта. Эти действия рекомендуется размещать в экспортных процедурах самого объекта, которые используются вызывающей стороной при записи объекта в режиме обмена данными.
Мы значительно переработали механизм отладки. Для этого было несколько причин. Во-первых, мы хотели предоставить вам возможность отлаживать все имеющиеся на сегодняшний момент приложения. Во-вторых, прежняя архитектура отладчика требовала изменений для того, чтобы соответствовать текущим тенденциям, и иметь возможность будущего развития. В-третьих, был необходим универсальный интерфейс отладки, с которым мог бы работать не только конфигуратор 1С:Предприятия, но и Development Tools.
Основные преимущества
Чтобы вы могли представить себе объём выполненных нами изменений, коротко перечислим основные преимущества нового механизма.
Современная архитектура отладки
Особенностью прежнего механизма отладки была необходимость подключения к информационной базе с помощью конфигуратора. В результате разработчик, выполняющий отладку, имел полный доступ ко всем административным функциям.
Новый механизм отладки перестал нуждаться в соединении с отлаживаемой информационной базой. Главное, что требуется теперь отладчику, это такая же конфигурация, которая работает у клиентов. Для её получения нет необходимости подключаться к отлаживаемой информационной базе. Вы можете загрузить её, например, из файла.
Отладка мобильных приложений
Изменение переменных, свойств объектов и асинхронные вычисления выражений
Теперь в процессе отладки вы можете изменять значения любых переменных, которые доступны для записи. Для быстрого просмотра и изменения локальных переменных мы реализовали отдельное окно. А само вычисление выражений, отображаемых отладчиком, теперь выполняется в асинхронном режиме.
Отладка в Development Tools
При создании нового механизма отладки мы реализовали новый, универсальный программный интерфейс взаимодействия с ним. Этот интерфейс использует конфигуратор 1С:Предприятия, и этот же интерфейс использует теперь и новая среда разработки 1C:Enterprise Development Tools. Таким образом, все возможности отладки доступны теперь и при работе в Development Tools.
Архитектура процесса отладки
Новая архитектура отладки выглядит следующим образом:
В отладке участвуют отладчик, предметы отладки и новый элемент - сервер отладки.
Взаимодействие с сервером отладки выполняется по инициативе отладчика и предметов отладки. Для этого организуются дополнительные соединения. Их основное назначение - узнать, не появилась ли для них информация на сервере отладки. И если появилась, получить эту информацию.
Таким образом, взаимодействие получается одностороннее. Информация всё время передаётся с сервера отладки в отладчик, и в предметы отладки.
Идентификация информационных баз
В прежнем механизме для идентификации информационных баз использовалась строка соединения. Такое решение в некоторых случаях вызывало трудности с сопоставлением предметов отладки и конфигуратора. Потому что, во-первых, оно было регистрозависимым, а во-вторых, при отладке некоторых контекстов платформа формировала строку соединения автоматически. И она не всегда совпадала с той, которую вы указывали при подключении информационной базы в конфигураторе. Поиск и исправление таких ситуаций усложняли процесс отладки.
В новом механизме мы избавились от строки соединения. Теперь мы используем идентификатор информационной базы. В файловой информационной базе такой идентификатор генерируется при первом подключении клиентского соединения. В серверной информационной базе в качестве такого идентификатора используется идентификатор регистрации информационной базы в кластере.
Приятным дополнительным моментом здесь является то, что мы пока сохранили в платформе старый механизм отладки (в дальнейшем он может быть исключён). И вы можете пользоваться им при желании, или при необходимости. Так вот старый механизм мы доработали, и теперь он тоже использует идентификатор информационной базы, а не строку соединения.
Типичные сценарии отладки
С точки зрения прикладного разработчика типичные сценарии отладки не изменились. Единственным значительным отличием является то, что новый механизм отладки нужно включить. Потому что по-умолчанию он выключен.
Несмотря на это имеет смысл познакомиться с тем, что происходит теперь при запуске отладки. Потому что это может быть полезно вам в каких-то нестандартных сценариях работы.
Файловый вариант
Клиент-серверный вариант
Подключение предметов отладки
При запуске отладочных сеансов из конфигуратора, приложения выполняют автоматическое подключение предметов отладки (как клиентского, так и серверного) к серверу отладки.
При этом, как и раньше, у вас есть возможность настроить в конфигураторе автоматическое подключение предметов отладки независимо от того, каким образом они были запущены. Теперь эти возможности стали гораздо богаче.
Во-первых, теперь платформа предлагает вам для выбора все возможные предметы отладки.
А во-вторых, появился ещё один, более тонкий способ настройки. Это использование заранее созданных отборов.
Такие отборы вы можете использовать как при подключении предметов отладки, так и для просмотра доступных предметов отладки.
В отборе, кроме самих предметов отладки, вы можете указать конкретных пользователей, чьи сеансы вас интересуют, а также, если используется разделение данных, указать область информационной базы, которая будет отлаживаться.
Изменение переменных, свойств объектов и асинхронные вычисления выражений
Новый механизм отладки позволяет вам изменять значения переменных в процессе отладки. В прежнем механизме такая возможность отсутствовала.
Для удобного просмотра и изменения локальных переменных, что представляется наиболее частой задачей, мы реализовали окно «Локальные переменные».
Внешне оно очень похоже на привычное вам «Табло». Но, во-первых, это окно уже автоматически заполнено всеми локальными переменными, а во-вторых, значения переменных вы можете теперь менять.
Значения примитивных типов вы можете изменить прямо в ячейке «Значение»:
А для изменения других значений вы можете воспользоваться окном ввода выражений:
Приятным бонусом является то, что в этом окне полностью функционирует контекстная подсказка.
Точно таким же образом вы можете изменять и значения любых (не только локальных) переменных, свойств, доступных для записи. В окне вычисления выражений (которое вызывается командой Shift+F9) вы можете менять значения переменных как в ячейке «Значение», так и с помощью отдельного диалога.
Кстати, само вычисление выражений теперь выполняется асинхронно. Это означает, что конфигуратор заказывает вычисление предмета отладки. И некоторое время это вычисление ожидается на сервере. Если вычисление выполнено, то результаты сразу поступают в конфигуратор. Если вычисление выполняется продолжительное время, то результаты этих вычислений асинхронно приходят в конфигуратор позже. Такой подход позволяет вам не ожидать длительных вычислений в конфигураторе, и продолжить свою работу.
Зачем нужны настройки интерфейса в программах учета 1С? Это удобно, так как дает возможность создать самое эффективное рабочее пространство. При этом не трудно учесть потребности и вкус каждого пользователя.
Интерфейс систем редакции 3.0, которые работают на платформе «1С:Предприятие 8.3», менялся несколько раз. И в настоящее время пользователям доступны следующие варианты, которые можно настроить под свои требования:
- Стандарт;
- Такси;
- По аналогии с предыдущей редакцией.
Рассмотрим особенности настроек каждого из вариантов.
Стандарт
Здесь структура интерфейса 3.0 не отличается от редакции 2.0. По сути, изменилось только оформление. Если вы посмотрите на верхнее горизонтальное меню, то заметите, названий подпунктов стало больше и появились пиктограммы.
При этом подпункты имеют вкладок, а не как было ранее – в виде выпадающего списка.
Такой вид интерфейса остается на сегодняшний день самым популярным. Потому, что он появился первым, пользователи привыкли к нему.
У вас есть возможность поменять структуру интерфейса. Сделать это не трудно. Для этого зайдите в «Настройки программы» через «Администрирование» и далее работайте в разделе «Интерфейс».
Горизонтальное меню
Изучим горизонтальное меню. Здесь расположены следующие панели:
Обратите внимание, что подпункты меню позволяют производить настройки панелей, а конкретно – их содержания. Кроме того, можно настроить и сохранить их вид в программе.
Давайте поочередно настроим панели.
Панель разделов. С помощью этой панели вы можете управлять разделами: добавлять необходимые и удалять неактуальные, а также настраивать другие пункты данного меню.
Панель действий. Здесь вы можете использовать дополнительные окна, которые расположены под основным меню. Откроется нужная полезная информация, стандартные отчеты и возможность обратиться в техподдержку.
Вертикальная панель навигации
С ее помощью вы можете работать с пунктами из подменю. Нужные добавить, ненужные – удалить. Обратите внимание, что эта возможность настройки ранее не была доступна пользователю. Приходилось приглашать программиста, чтобы выполнить какую-либо операцию с пунктом подменю.
Настроим или доработаем учетную программу (1С:Підприємство или BAS) под нужны вашей компании
- Разграничение прав доступа
- Шаблоны договоров в автозаполнением
- Изменение/создание печатных форм
- Настройка консоли отчетов
- Отчет по валовой прибыли
- Ваш логотип в основные документы - Акт, Накладная, Счет
«Такси»
Давайте рассмотрим следующий вариант – интерфейс «Такси».
Панель разделов расположена здесь слева с самого начала. Чтобы перейти к их настройке, нужно перетащить и сгруппировать нужные вам панели. Делается это в специальном окошке редактора. Здесь расположены следующие панели:
- разделов;
- открытых
- инструментов;
- текущего раздела;
- избранного;
- истории.
Вы можете добавлять те панели, с которыми предстоит работать, и удалять те, которые не используете.
В окне редактора активными становятся те панели, которые расположены в верхней его части.
Далее нас будут интересовать подпункты разделов. Нужную кнопку для настроек вы легко найдете в правом верхнем углу вертикальной панели.
Настройка панели действий. Здесь можно проводить различные действия с разделами. Обычно это добавление или удаление.
Внимание! В интерфейсе «Такси» выбранные подпункты будут помечены звездочками.
Обычно какие-то разделы или отчеты бухгалтер использует ежедневно. Например, ОСВ или ОСВ по счету. Чтобы они всегда были под рукой, добавьте их в «Избранное». Для этого в разделе «Отчеты» находим оборотно-сальдовую ведомость. Наведите на нее указатель мыши, а затем нажмите на серую звездочку. Так вы добавите отчет в «Избранное», что в дальнейшем сделает вашу работу удобнее.
Если не устраивает интерфейс
У вас есть возможность вернуться к предыдущему интерфейсу, если вас чем-то не устраивает «Такси». Расскажем, как это сделать.
Идем в раздел «Администрирование и выбираем пункт «Интерфейс».
Здесь необходимо будет выбрать нужный вариант. Можно изменить интерфейс вашей системы 1С на такой, как версиях 8.3 или выбрать аналогичный Бухгалтерии редакции 7.7.
После того, как вы выберете нужный и удобный вам внешний вид программы, обязательно перезагрузите ее.
Как в редакции 7.7
Этот вариант очень напоминает стандартную версию.
Чтобы настроить под себя интерфейс 7.7, на верхней панели справа нажмите на стрелочку.
Вы сможете добавить или удалить кнопки.
Обратите внимание! Если у вас есть действующий договор 1С:ИТС, то вам доступен полный комплекс услуг и полезных сервисов. Ваша программа всегда будет актуальна, а вы получите круглосуточную поддержку по работе 1С, в том числе и по настройке интерфейса. Вам также будет открыт доступ к десятку справочников, необходимых в работе.
Если у вас остались вопросы, можете задать их нашим специалистам по телефонам, или посетив офис в своем городе.
Читайте также: