Алексей Кирсанов

Объединенные скидки торгового каталога и магазина

Thu, 10 Nov 2016 18:03:34 +0300

Совсем недавно мы выпустили в альфу обновления sale 16.6.0, catalog 16.6.0 и iblock 16.6.0.
Альфа-версии доступны по NFR ключам только партнерам. Цель альфа-версий в том, чтобы вы заранее могли посмотреть, что у нас получается, подготовиться к выпуску обновления клиентам и повлиять на нас в плане доработки решения.

Итак, теперь вам доступны объединенные скидки торгового каталога и магазина. Что это означает?
Это позволит гибко управлять зависимостями между скидками, даст возможность в нужный момент останавливать выполнение скидок или устанавливать необходимый приоритет выполнения.

Подробнее...

БП и PHP код

Thu, 16 Jun 2016 09:18:09 +0300

Это сообщение будет, прежде всего, полезно тем, кто разрабатывает шаблоны БП на коробочной версии КП и БУС. Потому что речь в нем пойдет о действии PHP код, которое недоступно в облаке.

Рассмотрим следующий кейс: допустим у нас есть параметр БП типа множественный список, который содержит проекты. Соответственно при запуске БП можно выбрать один или несколько проектов из этого списка. Далее допустим у нас в БП для каждого проекта есть переменная, в которой хранится руководитель или руководители данного проекта.
Задача - отправить сообщение / поставить задание всем руководителям всех проектов, которые были выбраны при запуске БП.

Задачу конечно можно решить пачкой условных конструкций. Но это решение будет громоздким.
А можно воспользоваться действием PHP кода. Давайте посмотрим, как это сделать.

Подробнее...

Калькулятор в БП

Thu, 10 Mar 2016 11:57:43 +0300

Как вы знаете, БП поддерживают вычисление значений выражений в параметрах действий. Для практически любого параметра действия можно в качестве значения указать не только какое-то фиксированное значение (например, "Привет", не только переменную, параметр или поле документа (например, {=Variable:myVar}), но и вычисляемое выражение
====code====

="Автор: " & {=Document:CREATED_BY} & ", " & "Конечный срок: " & Dateadd({=Document:DATE_CREATE}, "1d")

=============
Этот функционал можно использовать, например, чтобы задать период ожидания (жизни) действия ознакомления с документом не в секундах, а какой-то датой со временем. Это может быть полезно, если ждать выполнения действия ознакомления надо не определенное время, а до какого-то времени. Например, нет смысла ждать ознакомления с отгулом после даты отгула.

С использованием вычисляемых выражений эту задачу можно решить так: в поле ввода "Период ознакомления" нужно написать строку вида
====code====

={=Template:Parameter1 > int}-{=System:Now > int}

=============
где Template:Parameter1 надо поменять на ту сущность, где хранится время. Например, это может быть Variable:MyVariable, если дата/время хранится в переменной, или Document:CREATE_DATE, если дата/время хранится в поле документа.
Тип периода надо оставить в секундах.
Обратите внимание, чтобы нигде у вас не было суффиксов _printable.
Если с таймзонами все в порядке, то вы сразу получите ожидаемый результат. В противном случае надо будет прибавить или отнять столько секунд, чтобы компенсировать сдвиг.
Подробнее...

Особенности совместимости нового магазина со старым

Mon, 15 Feb 2016 17:39:34 +0300

Мы готовимся к выпуску нового модуля Интернет-магазина. Физически это - тот же самый модуль sale, но существенно переработанный. В новом магазине у одного заказа может быть множество отгрузок и оплат/счетов, систематизирована оплата с внутреннего счета, переработаны платежные системы и службы доставки с целью их универсализации и поддержки новых возможностей, переработан жизненный цикл заказа, доработаны публичные компоненты и добавлено множество других улучшений и функциональных возможностей.

При разработке мы старались максимально обеспечить совместимость нового магазина со старыми версиями, но обеспечить 100% совместимость при такой масштабной переработке невозможно. Ниже в статье я опишу места, на которые надо обратить особое внимание при переходе на новый магазин. Если у вас есть вопросы, предложения, пожелания или требуется консультация - обращайтесь к нам через службу техподдержки.

Существенно изменилась структура таблиц в базе данных.
Мы всегда говорили, что прямой доступ к таблицам - это не правильный вариант работы с обновляемым продуктом. Но если вы все же по тем или иным причинам напрямую запрашиваете базу данных, то велика вероятность, что вам придется внести изменения в свои алгоритмы. Правильный доступ к данным должен производиться через АПИ модуля.

Заказ, оплаты, доставки – связь «один-ко-многим».
Раньше в магазине была одна сущность - заказ, который представлял собой одну запись в таблице заказов. В этой таблице было поле, в котором хранился код платежной системы, поле со статусом оплаты и т.д. В новом магазине у каждого заказа может быть неограниченное число (частичных) оплат/счетов, а так же неограниченное число отгрузок. У каждой оплаты свой статус оплаченности, своя дата оплаты и т.п.
Другими словами появляется связь «один-ко-многим» между заказом и оплатами/отгрузками. Соответственно если выбрать из базы пару значений "заказ - оплата", то либо оплата там будет какая-то одна из имеющихся (не все), либо один и тот же заказ будет в нескольких парах (по числу оплат).
Мы постарались обеспечить максимально возможную совместимость. Если у вас не используется разделение на несколько оплат для одного заказа, то через старый АПИ можно выбрать сразу и заказ и его одну оплату. Но как только у вас появится разделение - результат выборки может оказаться не такой, на который вы рассчитываете.
Все, что сказано про оплаты, верно и для отгрузок.
Рекомендовать тут можно только либо постепенно переходить на новый АПИ в ваших решениях (рекомендуется), либо всегда для одного заказа иметь только одну оплату и только одну отгрузку.

Оплата с внутреннего счета.
Раньше при оплате с внутреннего счета просто в таблице заказа проставлялась соответствующая сумма. В новом магазине внутренний счет - такая же платежная система, как и все остальные. Соответственно оплата с внутреннего счета - такая же запись (частичной) оплаты, как и для любой другой платежной системы. Таким образом облегчается отслеживание оплат, а кроме того на внутренний счет можно наложить условия и ограничения (как на любую другую платежную систему).

Полностью переработан жизненный цикл заказа.
Так как изменилась структура и работа заказа, то соответственно изменился и жизненный цикл заказа. Мы восстановили основные события того жизненного цикла, который был раньше. Они включаются и выключаются в настройках модуля. Но места вызова старых событий в новом магазине не соответствуют старым местам вызова (потому что старых мест уже нет). В большинстве случаев это не должно повлиять на успешное выполнение вашего обработчика события, но лучше после перехода на новый магазин перепроверить, что все работает правильно. Еще лучше, конечно, перейти на новые события.

Новый АПИ автоматически всегда поддерживает арифметическую целостность заказа.
Раньше программно можно было записать в любые поля заказа любые значения, и это успешно сохранялось, даже если логически данные не соответствовали друг другу. Например, при использовании старого АПИ можно было создать заказ стоимостью 1 руб., в котором было товаров на 500 руб. В новом магазине стоимость такого заказа будет 500 руб. (плюс возможно стоимость доставки).

Меняются реальные ID платежных систем и служб доставок.
В связи с изменением структуры и работы платежных систем и служб доставок, меняются их реальные ID. У служб доставок теперь нет архитектурного разделения на настраиваемые и автоматизированные, соответственно нет и строковых идентификаторов, они теперь числовые. Все внутренние данные и сущности сами переходят на новые ID при конвертации. Если вы где-то используете связывание внешних по отношению к модулю данных с платежными системами или службами доставок, то вам необходимо убедиться в корректном сохранении связей. А вообще правильнее такие связи делать через внешние ключи или мнемонические коды.

Ограничения платежных систем и служб доставок.
Раньше ограничения платежных систем и служб доставок (например, по сайтам, типам плательщика и т.п.) – были поля в таблицах соответственно платежных систем и служб доставок. Как следствие схема была не множественной и не расширяемой. Сейчас ограничения задаются с помощью новой сущности - ограничений. Они стали набираемыми для каждой службы доставки и платежной системы. Соответственно они могут быть множественными, можно расширять набор ограничений и т.д. Но следует учитывать, что это - больше не поля в таблице.

Пользовательские платежные системы.
Обратите внимание, что пользовательские обработчики платежных систем должны лежать в папке /bitrix/php_interface/include/sale_payment/. Они не могут лежать внутри /bitrix/modules/sale/. Внутри ядра продукта вы не должны ничего менять самостоятельно. Это прямо указано в документации.
Так же обратите внимание на то, что в общем случае нельзя напрямую (через include) подключать файлы из ядра продукта в свои скрипты. Если вы копировали какие-то обработчики в пользовательскую папку для изменения, то вы должны скопировать все файлы обработчика, а не подключать часть из них из ядра.

Если у вас есть вопросы, предложения, пожелания или требуется консультация - обращайтесь к нам через службу техподдержки.
Подробнее...

Бизнес-процессы и управление компанией

Thu, 06 Aug 2015 16:45:52 +0300

Часто новое дело, новый бизнес организуется и начинает работу в виде небольшого "дружеского" объединения, сплоченного общей идеей. В коллективе единомышленников каждый выполняет свои действия творчески, ответственно и самостоятельно. Сотрудники работают не только за зарплату, но во многом за идею. Директор в курсе всех происходящих в коллективе процессов и может оперативно реагировать на возникающие проблемы. Такой стиль управления называется "стихийное руководство", "управление в зависимости от ситуации" или "ситуационный менеджмент".

И этот стиль управления зачастую оправдывает себя при зарождении и становлении бизнеса, так как позволяет реагировать на различные ситуации более гибко. При этом он требует от руководителя знания эффективных методов управления, умения прогнозировать последствия применения разных методов управления, умения правильно распознать сложившуюся ситуацию, навыков выбора оптимального для данной ситуации решения. То есть накладывает на квалификацию и мотивацию руководителя довольно сильные ограничения.

Но с ростом компании, с появлением большого числа наемных сотрудников, в том числе на руководящих должностях, в определенный момент наступает такая ситуация, когда управлять "как прежде" становится невозможно. Новые руководители и работники не всегда имеют достаточную квалификацию и/или мотивацию, чтобы эффективно, творчески, ответственно и самостоятельно действовать в меняющейся ситуации. Руководители зачастую оказываются завалены лавиной мелких вопросов, которые решались через них, когда компания была маленькой, но компания то растет. Отсутствие системы в работе компании приводит к ошибкам в управлении. Как следствие рентабельность бизнеса может постепенно начать снижаться.

И в этой ситуации надо что-то менять. Один из вариантов - это внедрение в компании регулярного менеджмента. То есть такого менеджмента, при котором процессы внутри компании регулируются (регламентируются) строгими написанными правилами.

При применении ситуационного менеджмента сотрудник может действовать по разному в одинаковых ситуациях, принимая решение на основании своего опыта, интуиции, настроения, фазы луны и т.п. При внедрении же регулярного менеджмента действия сотрудника будут регламентированы, сотрудник всегда будет действовать и принимать решения в соответствии с установленными руководством правилами и ценностями. Имея строгие написанные правила сотрудник всегда знает, что делать в той или иной ситуации и как это делать самостоятельно, не отвлекая руководство.

Как составить оптимальные для компании правила и регламенты - это вопрос, выходящий за рамки данного текста. А вот инструментом для автоматизации создания, исполнения и контроля исполнения правил может стать модуль Бизнес-процессов.

Модуль Бизнес-процессов позволяет визуально формировать процессы, правила и наборы правил, а так же исполнять их и контролировать их выполнение. При этом выполнение процесса всегда идет по заранее утвержденным регламентам так, что сотрудник не может ошибиться, обойти или игнорировать какие-либо действия. У сотрудника, в том числе нового, не возникает вопроса, как делать. Потому что ответ на него простой: запустить бизнес-процесс и следовать дальнейшим инструкциям. У руководителя же есть инструмент, с помощью которого он может оперативно видеть, как движутся процессы и где они тормозятся. Модуль Бизнес-процессов позволяет работать практически с любым видом информации на сайте. Конкретные процессы могут запускаться как автоматически при возникновении какого-то события, так и вручную конкретным сотрудником.

Таким образом модуль Бизнес-процессов поддерживает основные принципы регулярного менеджмента: он позволяет задать набор правил и регламентов, при этом правила задаются в письменном виде, а ключевые моменты исполнения правил подконтрольны руководству.
Подробнее...

Магазин и каталог 12.5

Fri, 19 Apr 2013 15:45:56 +0400

Последние обновления привнесли существенные изменения в связь между магазином и каталогом. Базовые принципы остались неизменными: магазин ничего не знает о каталоге (точнее не знает основной функционал магазина), связь осуществляется через через специальный обратный вызов. Соответственно магазину все равно, кто кормит его товарами. Это может быть вовсе не модуль каталога. Магазину важно только, чтобы ему дали интерфейс, по которому он может актуализировать цены, проверять количество, сообщать о фактической продаже товара и т.п.

И интерфейс этого канала изменился.

Старый интерфейс представлял собой набор методов, имена которых записывались в поля соответствующего элемента корзины (для каждого элемента). Магазин по необходимости запускал соответствующие методы. Например, для актуализации цены и доступности товара он запускал метод из поля CALLBACK_FUNC, а при оформлении заказа - ORDER_CALLBACK_FUNC.

Для реализации нового функционала каталога и магазина 12.5 (складской учет, резервирование и отгрузка товаров,...) нам потребовалось существенно расширить интерфейс общения между каталогом и магазином. И экстенсивное расширение путем добавления в корзину новых полей с новыми именами новых функций было признано не эффективным.
Магазин продолжает поддерживать старый интерфейс в старом объеме функционала. Но с текущей версии общение магазина и каталога базируется на новом интерфейсе. И новый функционал тоже основывается уже на новом интерфейсе.

В корзину добавлено одно новое поле PRODUCT_PROVIDER_CLASS, которое содержит имя класса, реализующего интерфейс IBXSaleProductProvider. Этот интерфейс и определяет интерфейс общения магазина и сущностей, которые кормят магазин товарами. Каталог записывает в это поле имя класса CCatalogProductProvider.

Обратите на это внимание, если вы пользовались какими-то хаками, чтобы добиться нужного вам поведения. Возможно вам потребуется отнаследоваться от класса CCatalogProductProvider или сделать свою собственную реализацию IBXSaleProductProvider.
Подробнее...

Модуль Бизнес-процессов

Tue, 13 Dec 2011 16:40:11 +0400

С момента выпуска модуля Бизнес-процессов прошло некоторое время. Мы смогли оценить его возможности. Поняли, что было сделано в модуле правильно, а что - не совсем. Узнали его сильные и слабые стороны. В результате анализа стало ясно, что сам движок модуля работает достаточно успешно. Но требуются некоторые изменения его окружения и оснастки. Часть из этих изменений должна быть направлена на обеспечение большей понятности и удобства пользования модулем, другая должна добавить модулю еще больше универсальности. Ну и конечно необходимо исправить накопившиеся ошибки.

Сейчас пришло время очередных обновлений модуля Бизнес-процессов.

Подробнее...

Бизнес-процессы: создание

Wed, 21 Apr 2010 10:11:17 +0400

Компонент "Бизнес-процесс" (bitrix:bizproc.wizards) служит для создания и управления произвольными бизнес-процессами (далее БП). Такими БП могут быть оформление командировки, согласование отпуска или подотчетных денег, заявки на приобретение техники или материалов, организация технической поддержки пользователей и т.п.

Компонент позволяет "не программистам" создавать и изменять произвольные БП с помощью визуальных средств. Он дает специалисту возможность отобразить его специфичные знания с помощью высокоуровневых абстракций. Другими словами, компонент позволяет изложить свое видение решения наглядным способом, который другой человек будет в состоянии понять (и изменить по необходимости).

Рассмотрим процедуру создания БП на примере алгоритма согласования подотчетных денег. Пусть в нашей условной организации согласование подотчетных денег осуществляется следующим образом:
1. Составляется заявка на выдачу подотчетных денег;
2. Заявка согласуется с руководителем (или несколькими руководителями). Пусть согласование производится по очереди с двумя заранее известными руководителями;
3. Оформление заявки в бухгалтерии;
4. Выдача денег;
5. Предоставление отчета;
6. Проверка отчета в бухгалтерии.
Пусть при этом подать заявление на подотчетные деньги может любой сотрудник, а видеть все заявления может только руководство.

Подробнее...

Добавление закладки в социальную сеть

Fri, 26 Feb 2010 12:41:21 +0300

Появилась возможность добавить произвольную закладку в социальную сеть без изменения стандартных компонентов. Для этого необходимо написать обработчики специальных событий.

Подробнее...

Очные курсы для программистов

Wed, 25 Apr 2007 12:51:43 +0400

С 17 по 19 апреля в Москве прошли трехдневные очные курсы для разработчиков посвященные технологиям разработки Web приложений с помощью продукта "Битрикс: Управление сайтом". Курсы читал я

Официальные результаты этого мероприятия должны быть сегодня опубликованы, а я хочу сказать несколько неофициальных слов.

Подробнее...