Теперь вы можете выбрать удобный именно вам способ нумерации заказов, при этом изменить его, используя предложенные шаблоны, можно в любой момент как в новом интернет-магазине, так и в уже работающем. Смена шаблона генерации осуществляется без потери заказов или остановки работы магазина.
Нумерация заказов применяется как для административного, так и для публичного разделов и поддерживается всеми основными компонентами.
Выбор шаблона генерации номера заказа осуществляется в настройках модуля Интернет-магазин:
[spoiler]
Рассмотрим каждый из шаблонов
Не используется: новый функционал генерации номера не используется, т.е. нумерация осуществляется как и прежде, начиная с 1 и увеличиваясь на единицу в новом заказе (настройка включена по умолчанию).
Нумерация с определённого числа: вы сможете выставить любое число, с которого должна начинаться нумерация. Число может содержать от 1 до 7 цифр, должно быть больше текущего ID заказа, и может быть изменено в любой момент на большее.
Выставляем число 17500, делаем новый заказ в административном разделе и видим, нумерация началась с 17500:
Обратите внимание, добавлен новый столбец Номер заказа.
Используя схему нумерации с нужного числа, вы сможете для нового магазина скрыть информацию, что он только запустился.
Новая нумерация отработала и в письме, которое пришло после оформления заказа клиенту:
В списке заказов в публичном разделе клиент тоже видит новую нумерацию:
В решении (bitrix.sitestore) новая схема нумерации пока не поддерживается. В ближайшее время выйдет обновление данного решения.
Префикс перед номером: шаблон позволяет задать префикс от 1 до 7 символов (латинские буквы, цифры, тире, знак подчеркивания).
Например, зададим префикс как «Prefics» и сделаем новый заказ:
Случайный уникальный номер: номер генерируется случайным образом из цифр и букв латинского алфавита, возможная длина (от 5 до 10 символов) указывается в настройках.
Ставим генерацию номера из семи символов, получилось:
При такой схеме нумерации конкуренты не смогут отследить, сколько заказов выполняет ваш магазин за сутки, час, месяц и т.д.
Идентификатор и номер заказа пользователя: при использовании данного шаблона номер заказа будет иметь вид: «ID пользователя» «нижнее подчеркивание» «номер заказа».
Например, заказ № 1_2, где
1 - это идентификатор пользователя, сделавшего заказ
2 - это номер заказа для текущего пользователя (цифра два говорит о том, что это второй заказ пользователя)
При такой нумерации менеджеры смогут сразу видеть, сколько заказов уже оформлял данный пользователь.
Нумерация за определённый период: данный тип нумерации удобен для магазинов с большим потоком заказов и быстрого отслеживания, сколько было заказов за определённый период. Поддерживается уникальная нумерация в пределах: дня, месяца, года.
Нумерация будет выглядеть следующим образом:
- В пределах дня: 24062013 / 5
- В пределах месяца: 062013 / 4
- В пределах года: 2013 / 3
Оформленный заказ оказался девятым в текущем году. В следующем году нумерация начнётся опять с единицы.
Данный функционал вышел в модулях catalog и sale 12.5.4, в настоящее время оба обновления находятся в статусе alpha, т.е. доступны только партнерам.
А еще можно будет сделать агенты, который раз в 5 минут запускается и меняет "стартовый номер заказа", тем самым увеличивая оборот в разы даже для въедливых конкурентов
Опять таки, не очень красиво получается. В заказах у пользователя Номер заказа, а в таблице купленных ресурсов - ID
"sale", "OnBeforeOrderAccountNumberSet"
и использовать свою схему.
По сути достаточно еще одного события - на построение списка, чтобы туда свой вариант добавить.
А то клиент выбирает в списке одно, используется другое. Непонятки.
OnBuildAccountNumberTemplateList
Пример использования:
AddEventHandler("sale", "OnBuildAccountNumberTemplateList", "MyAccountNumberHandler3");
function MyAccountNumberHandler3($arFields)
{
return array("CODE" => "SOME_CODE", "NAME" => "Some name");
}
AddEventHandler("sale", "OnBeforeOrderAccountNumberSet", "MyAccountNumberSetNumber");
function MyAccountNumberSetNumber($ID, $template)
{
if ($template == "SOME_CODE")
return randString(6, array("ABC"));
}
А какие гарантии, что номер будет уникальным?
И где можно изменить принцип генерации, что бы он составлялся только из цифр
За дополнение спасибо, давно такое требовалось, доработать только еще чуть
Изменить схемы заложенные нами нельзя, а вот сделать свою схему пожалуйста, для этого есть два события, которые позволят это сделать, в комментариях выше они написаны и даже даны примеры.
Если их все таки нет, вам стоит обратится в техническую поддержку, для выяснения причин их отсутствия.
ps не знал, что версия движка и версии отдельных модулей не совпадают.
Для какой цели отправлять их в 1С, насколько это необходимо и для чего, почему бы так и не использовать внутри ID? Были бы интересны ваши аргументы.
А теперь, когда появились настройки нумерации на сайте, можно загружать заказы с разных сайтов и номера будут уникальными.
Я закладывал что клиентам нет разницы, какой там у вас номер в 1С, главное что бы в документах были мои данные и мой товар.
Проблем со звонками не должно быть, ID остался как в 1С так и в Магазине, соответственно, если клиент назовет номер по ID менеджер его легко найдет, если назовет номер по схеме генерации, опять таки легко найдет но уже не в 1С.
Учтем этот момент, спасибо!
Без передачи префикса в 1С имеем "кашу" заказов из разных ИМ. И что более печально - эта каша разъезжается по ИМ.
А префиксы в ID прекрасно ее решали бы (или хотя бы модуль в 1С обмена понимал связи заказ-сайт),
Ребят, если есть еще проблемы с нумерацией и интеграцией оной с 1С, пишите, в новом релизе запланированы работы по 1С, постараемся учесть как можно больше моментов и решить их,
Номер заказа на сайте: FGSH8
Префикс на странице обмена: A1-
В 1С номер заказа будет иметь вид: A1-FGSH8
Если поле не заполнено, префикса не будет.
Комментарии приветствуются, решает ли это задачи описанные вами?
У нас народ работающий с заказами сидит только в 1С и битрикс им не нужен, даже мешает. Когда клиент звонит - он может сказать только свой заказ по битриксу (другого не знает) - и это работу сильно усложняет - пришлось генерацию пока отключить, т.к. лазить в битрикс только ради того что бы реальный номер заказа узнать это слишком трудозатратно.
Вариант когда номер подменяет нумерацию в 1С:
критика и комментарии заинтересованных лиц приветствуются, пока идет работа над этим.
Если быть совсем точным то нам нужен номер сделанный из цифр (т.к. клиенты по телефону буквы диктуют тяжело) и почему-то OnBeforeOrderAccountNumberSet мне результата не дал (событие срабатывало, но получал я всегда пустоту на выходе), но это я уже буду копать дальше, после того как номера потянутся в 1С в этом появится смысл.
В квитанции Сбербанка есть проблема, будет исправлена.
Самый простой вариант развернуть демку и скопировать из нее шаблон данного компонента или весь компонент к себе.
Либо использовать компонент с дефолтным шаблоном.
На текущий момент крайняя версия от 8 июля.
В своих шаблонах я поправил. Уже разобрался что к чему.
В квитанции сбербанка до сих пор:
И кстати, в компоненте sale.personal.order.list не переделана работа формы фильтрации заказов, там идет проверка по ID.
Понимаете стоит задача, на уже оформленый счет (номер сгенерированый cms), дать возможность исправить на свой внутрений. Пример ранее оформленый онлайн счет имеет номер 1, нужно после в ручную изменить на 00001? И желательно, чтобы последнее значение перезаписалов в базе, но а при оформлении достаточно идти дальше, 2..3..4.. (только прошу не задавайте логичных вопросов, они все отметаются, сами в ступоре и не можем понять заказчика).
1. Битрикс отбрасывает незначащие нули, но вы можете начать нумерацию с любой нужной, но не меньше уже существующего номера заказа.
2. 1С без проблем отображает номера в виде 0001, если приходит с Битрикса заказ 1, то в 1С он будет то же 1, но его можно поменять там на 0001 и значение останется.
3. Сейчас мы добавим префиксы, выйдут в релизе, не чего не мешает сделать префикс "ООО" Буквами
ну а теперь если моих пояснений недостаточно, перефразируйте вопрос пожалуйста.
1. оформляется заказ (онлайн) и есть счет с номером для распечатки (пример №1 счета) - этот момент запомнили
2. теперь сотрудник компании заходит в ПУ (а еще лучше в личный кабинет пользователя) и редактирует тот самый счет, на свой номер примеру с №1 на №2222 и он доступен для клиента на распечатку.
У клиентов могут быть желания из области фантастики, им не кто не может этого запретить, но в реальной жизни можно или объяснить, или кастомизировать логику и подменить номер на любой нужный. Можно попробовать через события, которые были сделаны и рассказаны выше в комментариях.
Но в штатной поставке такого не предусмотрено, это будет слишком частный случай, который может повлечь очень много проблем, особенно при интеграции с 1С.
Почему речь о базе? Так потому что еще будет создаваться отчет и тут риск что информация будет подтягиваться с № который был сгенерирован движком, но вот реального номера нет, может конечно показывать два номера в отчетах.
Спасибо.
Предположим клиент покупает определеную услугу, это услуга/сервис на сайте, есть минимальная стоимость и есть максимальная стоимость. Так вот при покупки по минимальной стоимости с его счета списывается счет - точнее цена/стоимость, но не дождавшись окончания срока действия услуги/сервиса - клиент решает приобрести услугу сервис по Максимальной стоимости и здесь, нужен онлайн алгоритм, перерасчета за ранее выполненую оплату с доплатой для новой услуги/сервиса. На примере куплено на 100 р. использовано не полное время а треть скажем, значит перерасчет за минусом 30% (это будет в точной сумме), далее при переходе на сервис за 200 р. идет оплата с первой суммы + доплата (конечно списание с личного счета).
Схема возврата и перезаказ не устраивает, так как бухгалтер ни хочет возится с документами.
Мы планируем ввести в продукт, понятие услуга, но это будет через релиз скорей всего, но ввод услуги не решит вашу задачу, он будет немного не в таком ключе.
Самый простой вариант сейчас, это услуги сделать товарами, отменили заказ с товаром, деньги вернули на внутренний счет, купил клиент новую услугу как товар, доплатил, как то так, но без отслеживания срока действия. С отслеживанием это смотреть подписки, но они очень не тривиальные и немного опять не под вашу задачу.
Подсмотрели один функционал в ПУ одного хостинга, там списание происходит по дням. Как раз то что нужно (по примеру). Если писать с нуля в обход системы, но тогда в общий отчет заказов он не попадает. Здесь привязка происходит: время, стоимость (плавующая, так как может быть перерасчет), переход на другую стоимость (правда без возвратно на дешевое решение). И только на основании этого бухгалтер сможет разносить акты в личные кабинеты клиентов после оказания услуг.
Возникает вопрос при заказе услуги (если мы оформляем как при покупки товара), примеру услуга "У" стоимостью ограничена на время "В" (нам известно: цена + время + сама услуга). Время может быть абстрактным, просто написаным от руки, а нужно его сделать динамичным, ведь цена "Ц" обусловлена временем "В" за услугу "У". Иначе говоря при истечении "В" за "У" она становится (если не заплатить повторно "Ц") не активной.
Само "В" поделено на единицы "Е", а значит по истечению "Е" + "В" за которую оплатили "Ц", нам нужно автоматический сформировать закрывающий акт. Для акта у нас известна информация: реквизиты клиента, "Ц", "В", "У". Нужно запустить событие, только проблема к чему его привязать.
Если мы смотрим на панель партнера здесь на сайте, мы оформляем лицензию, получаем счет, после получения денег ваша бухгалтерия активирует акты. Вот этот момент он сделан в ручную и это понятно. Но в нашем случае заказ услуги происходит путем списания с личного счета, а значит в необходимости перепроверки нет надобности. Может вы сталкивались с этим?
Спасибо за понимание.
Сугубо ИМХО - префикс он и есть префикс, чтоб за ним сразу номер шел. Если мне нужно, я сам подчеркивание добавлю.
Согласитесь, крайне нелепо выглядит номер заказа BC-_2401 или BC/_2401
Боюсь себе представить, что придет в выписке и с номером BC_2401.
Бух точно убъет за это
В целом мысль правильная и нужная, но хотелось бы еще поддержку кириллицы в номерах.
Если кириллицу клиент еще в состоянии озвучить, то вот при номере заказа WY23VC - это точно на пару минут....
Обновили битрикс, появилась генерация. Выставили префикс "G_"
Но префикс высвечивается только в карточке товара. В списке просто номер, без префикса. Письма отсылаются без префикса , все формы печатные тоже.
В чем может быть проблема?
Но! Если клиент переходит в раздел Мои заказы, то в заголовке окна браузера 555, а вот в заголовке самого компонента в списке и при детальном просмотер отображается не номер заказа, а ID = 55: Заказ № 55 от 14.10.2013 23:24:14.
Никак не могу исправить ни в параметрах, ни в шаблоне компонента.
Кто-нибудь сталкивался с этим же? Подскажите, пожалуйста, что сделать?
Мы внесли все правки во все места, но правки вносились в свежие компоненты, которые на данный момент являются текущими для реализации. А частенько клиенты ожидают это увидеть в компонентах которые скопированы в свое пространство или изменены, естественно там не каких изменений не будет.
Поэтому, если вы нашли место где что-то не работает, большая просьба сбрасывать это в виде багов в нашу техническую поддержку, и если не трудно скидывать номер обращения мне.
Если ошибка будет выявлена с нашей стороны мы ее конечно поправим, если компонент скопирован и изменен на вашей стороне, вам нужно будет или подправить ваш компонент или использовать наш.
Мой адрес для номеров обращений по данному вопросу: myth@bitrix.ru
А тем у кого версия до 12.5.4 и кому хотелось бы скрыть объемы заказов от конкурентов, можно заменить стандартный автоинкремент ID заказа значением текущего unix-времени (кол-во секунд с 01.01.70).
для этого поправить /bitrix/modules/sale/mysql/order.php - перед строкой INS ERT IN TO b_sale_order... вставить
$DB->Query("ALT ER TABLE b_sale_order AUTO_INCREMENT = ".time(), false, "File: ".__FILE__."<br>Line: ".__LINE__);если номер кажется вам длинным, можно уменьшить его до 9 разрядов (уникальности хватит на 30 лет)
Огромный плюс способа - не возникает проблем со ссылками и отображением ID в разных местах сайта, т.к. мы модифицируем непосредственно ключевое поле базы заказов ID.
этот способ хорош еще тем, что не возникает проблемы с уникальностью генерируемого ID - даже если два заказа пройдут в одну секунду, mysql при добавлении записи автоматом увеличит ID второго заказа на 1
Подскажите как сделать что бы сайт делал безналичный счет без дроби и цифри? В 1С этот заказ ложится без этого....