Кроме решения, о котором я писал раньше появилось одно уточнение. Подобная ошибка может появиться в случае использования разных версий платформы на узлах распределенной базы. В моем случае на центральной базе была версия 8.3.4, а периферийную базу обновили до 8.3.6. Решается без каких-либо манипуляций простым обновлением баз до одинаковой версии.
Если во время обмена между распределенными базами на периферийной базе возникает ошибка “Конфигурация не соответствует ожидаемой” и обмен не загружается, нужно выполнить следующие действия:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);ПланыОбмена.УстановитьГлавныйУзел(ТекущийУзел); В переменную ТекущийУзел нужно передать элемент из плана обмена, его можно сделать полем выбора в форме обработки. 
После этих манипуляций обмен должен пройти в обычном режиме.
В развитии конфигурации наступил важный этап – добавлен отчет “Финансовый результат”. Отчет строится по оборотам специального одноименного регистра. Теперь можно увидеть результат работы предприятия за любой период и, главное, проанализировать источники оборотов: суммы отчета можно развернуть по аналитике, периодам и по документам, сформировавшим движения.
В документе Инвентаризация товаров добавлен алгоритм очистки остатков от партий с отрицательным количеством. При рассчете списания создаются дополнительные проводки: сторно минусовой партии и списание этого-же количества из “нормальной” партии по правилу FIFO. Проводки формируются только по товарам, которые на момент инвентаризации имеют положительный общий остаток.
В списке товаров добавлена возможность включения второго столбца с ценой, т.о. теперь можно выбрать два типа цен, которые будут отображаться.
При двойном клике на ячейке с ценой появится запрос на ввод нового значения цены, так что теперь установку ноых цен можно делать прямо в списке товаров. Это работает для обоих столбцов.
Добавлено сохранение настроек списка – фирмы, склада и типов цен и автоматическое восстановление этих настроек при открытии списка.
В документе Приобретение услуг добавлен выбор базы для расчета распределения дополнительных расходов. Теперь вариантов три: сумма, вес и объемный вес.
В документе Инвентаризация товаров добавлены столбцы с суммами – по данным учета и разницы. Также сумма разницы выведена в печатную форму инвентаризации.
Обновлен Материальный отчет по розничной точке. Если сформировать его по обычному складу, будет выведена информация о приходах на склад, суммах приходов в продажных ценах, расчет дооценки товаров по данным установок цен и суммы реализации, реализованной наценки.
В состав конфигурации “Простой учет” добавлена обработка для поддержки обмена данными с интернет-магазином, использующим плагин WooCommerce для WordPress. Как и с остальными магазинами, есть возможность обновлять цены товаров на сайте по данным из 1С и загружать оставленные покупателями заказы сразу в документ “Расходная накладная”.
В процессе написания обработки пришлось разложить по полочкам схему данных магазина, при этом сначала меня удивила концепция: все основные сведения хранить в таблице posts. Т.е. там лежат и данные о товарах, и данные о заказах, сам WordPress там хранит данные постов. На деле оказалось, что для целей обмена данными к этой таблице обращаться практически не приходится – нужные параметры разбросаны по множеству дополнительных таблиц.
схема связи данных в таблицах WordPress и WooCommerce
Так например, чтобы узнать, есть-ли заказы ожидающие обработки, нужно прочитать из таблицы term_relationships записи со значением поля term_taxonomy_id равным коду статуса “ожидание”. Поле записи object_id будет содержать код заказа, а по сути это id записи в таблице posts соответствующей искомому заказу. Содержимое заказа лежит в таблице woocommerce_itemmeta, здесь надо сделать выборку по полю order_item_id (id заказа) и перечитать содержимое в полях meta_key и meta_value. Это еще одна “фишка” этого плагина: значения записаны не в отдельных полях таблицы, а вписаны в две колонки таблицы по принципу: одна колонка содержит ключ, вторая – значение. Т.е перебирая строки нужно анализировать значения ключа, к примеру в строке с ключом “_qty” получим количество, “_line_total” – сумма товара по строке и т.д. По такому-же принципу “спрятаны” данные и заголовка заказа с именем покупателя, телефоном и прочим, только уже в таблице postmeta.
Если реквизит имеет ссылочный тип, например, справочник, то если реквизит не заполнен, будем иметь у такого реквизита значение типа “пустая ссылка”. Но если реквизит составной и в качестве возможных типов указаны, к примеру, два справочника, то у пустого реквизита будем иметь “Неопределено”. Столкнулся, когда переделывал документ и сделал одному из реквизитов составной тип – вылезли ошибки в модуле документа при проверке значений в реквизитах.
Для того, чтобы проверить тип значения документа (а также и любой другой ссылки) в запросе, используется оператор ССЫЛКА.
Пример текста запроса с проверкой типа документа:
Использование оператора ССЫЛКА в запросе
Пришло время знакомиться с новой версией конфигурации “Простой учет”, теперь на платформе 8.3 в режиме управляемого приложения. Пока еще не все участки учета проработаны, конфигурация всё ещё в разработке. Основное внимание уделяется удобному и информативному учету реализации товаров, закупок, расчетов с покупателями и поставщиками.
Что уже реализовано: