В конфигурации “Бухгалтерия для Ураины”, редакция 2.0, при подсчете количества часов не учитываются предпраздничные дни. Простой способ исправить ситуацию:
Модуль РасчетЗарплатыБазовый
Функция РабочихДнейЧасовВПериоде
было: РабочихДнейЧасов.Часов = РабочиеДни * 8 + ПредпраздничныеДни * 8;
нужно: РабочихДнейЧасов.Часов = РабочиеДни * 8 + ПредпраздничныеДни * 7;
Читать далее
Агент. Приложение для торговых представителей
Sic С 7 февраля 2017 бета-тестирование окончено, программа доступна в плей-маркете
Для округления чисел в запросе необходимо применять функцию ВЫРАЗИТЬ, для отсечения дробной части придется использовать конструкцию ВЫБОР.
Пример округления до целого:
ВЫРАЗИТЬ(ЦеныМагазина.Цена КАК ЧИСЛО(12, 0))
Пример получения целой части (отсечение дробной):
ВЫБОР
КОГДА (ВЫРАЗИТЬ(ЦеныМагазина.Цена КАК ЧИСЛО(12, 0))) > ЦеныМагазина.Цена
ТОГДА (ВЫРАЗИТЬ(ЦеныМагазина.Цена КАК ЧИСЛО(12, 0))) - 1
ИНАЧЕ ВЫРАЗИТЬ(ЦеныМагазина.Цена КАК ЧИСЛО(12, 0))
КОНЕЦ
Кроме решения, о котором я писал раньше появилось одно уточнение. Подобная ошибка может появиться в случае использования разных версий платформы на узлах распределенной базы. В моем случае на центральной базе была версия 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.