как сделать произвольный номер заказа?

[raskenx]

Всем привет, в опенкарте каждому заказу присуждается свой номер по порядку 1, 2, 3... и т.д. Как сделать чтобы этот номер начинался скажем так со 100 или 1000? спасибо

[Гість]

в БД изменить id  =)

[Lazdakon]

20 минут назад, nexus сказал:

в БД изменить id  =)

Дополню ответ предыдущего комментатора — в базе данных через phpmyadmin в таблице oc_order изменить  id у последнего заказа на нужный, но также не стоит забывать изменить id всех сопряженных таблиц, а то есть:
 

oc_order_history 

oc_order_option 

oc_order_product   

oc_order_status 

oc_order_total 

и так далее

[raskenx]

Только что, Lazdakon сказал:

Дополню ответ предыдущего комментатора — в базе данных через phpmyadmin в таблице oc_order изменить  id у последнего заказа на нужный, но также не стоит забывать изменить id всех сопряженных таблиц, а то есть:
 

oc_order_history 

oc_order_option 

oc_order_product   

oc_order_status 

oc_order_total 

и так далее

спс. буду пробовать

[baster789]

13 минут назад, raskenx сказал:

спс. буду пробовать

Вы хотите чтобы новые заказы тоже начинались с этого с большего числа?
Тогда выполните SQL запрос

ALTER TABLE oc_order AUTO_INCREMENT=1001;

Вместо 1001 то число с которого хотите заказы чтобы продолжались, а то что выше вам сказали для этой цели не подойдет)

[raskenx]

1 час назад, baster789 сказал:

Вы хотите чтобы новые заказы тоже начинались с этого с большего числа?
Тогда выполните SQL запрос

ALTER TABLE oc_order AUTO_INCREMENT=1001;

Вместо 1001 то число с которого хотите заказы чтобы продолжались, а то что выше вам сказали для этой цели не подойдет)

выдало ошибку, сделал по первому варианту, поправил БД... Но все равно большое спасибо

 

Скрытый текст

 

Змінено 8 травня 2017 користувачем raskenx

[baster789]

выдало ошибку, прикрепил скриншот

Сначала откройте базу опенкарт и потом выполните запрос)

Отправлено с моего IQ4511 Octa через Tapatalk

[chukcha]

Полная х-ня

 

Номер заказа имеет сои привязки

 

Есть номер инвойса

Вам нужен уникальный, случайный, не упорядоченный номер заказа, аот и играйтесь его номером иновойса - и при этом НИЧЕГО Не сломаете

 

 

[baster789]

20 минут назад, chukcha сказал:

Полная х-ня

 

Номер заказа имеет сои привязки

 

Есть номер инвойса

Вам нужен уникальный, случайный, не упорядоченный номер заказа, аот и играйтесь его номером иновойса - и при этом НИЧЕГО Не сломаете

 

 

Простите кончено, но причем здесь номер инвоиса? На мыло клиенту приходит номер заказа, и думаю первоначальная цель автора темы, создать видимость активной деятельности магазина. Альтерацией инкремента в базе ничего не сломается, вся система заказов танцует от order_id и каким образом вы себе представляете поломку, я не очень понимаю) Фактически мы просто внушаем системе, что было уже нужное нам колличество заказов, а что там в конце номера счета - конечному пользователю до лампочки. Для пущего тумана можно сделать генерацию счетов с перфиксом в виде даты заказа, тогда вообще идеально)

[chukcha]

Фикция!

Я знаю, откуда и где и зачем, и как єто потом ломает всю строгость

 

Номер инвойса это тоже признак заказа, хотите его делать уникльным, вот и пользуйте это поле

[baster789]

6 минут назад, chukcha сказал:

Фикция!

Я знаю, откуда и где и зачем, и как єто потом ломает всю строгость

 

Номер инвойса это тоже признак заказа, хотите его делать уникльным, вот и пользуйте это поле

Не подумайте, что я докапываюсь или еще что-то, просто стало интересно, для общего развития, да и другим как урок будет: можете привести пример в какой ситуации подобное решение навредит системе?
Я, просто, не могу представить подобный кейс, а красота решения, это уже больше из вопросов "быдло-небыдло кодинг", которые владельцев магазинов не волнуют, если это не поломает сам магазин)
Вы ведь сами понимаете, что сложность в реализации увеличения инкремента и рандомизации номеров малеха разная, -  для людей с пыхой и структурой карта не знакомых

[chukcha]

ок..

Тупо

 

перед добавлением вам нужно сгегенировать "уникальный" id

а поле autoincrement

Затем у вас там индекс по этому полю, и нужны связи

Ну, вроде ничего страшного..

Но!!! зачем эта головная боль?

 

Есть номер инвойса, а это тупое математическое действие

10 минут назад, baster789 сказал:

какой ситуации подобное решение навредит системе?

Не будет учтено в каком-нибудь кривом модуле..

[baster789]

Только что, chukcha сказал:

ок..

Тупо

 

перед добавлением вам нужно сгегенировать "уникальный" id

а поле autoincrement

Затем у вас там индекс по этому полю, и нужны связи

Ну, вроде ничего страшного..

Но!!! зачем эта головная боль?

 

Есть номер инвойса, а это тупое математическое действие

Не будет учтено в каком-нибудь кривом модуле..

А как же естественные гэйпы межде айдишниками в случае операций добавления/удаления тех же товаров например? Или например было у меня 1200 заказов, я удалил первые 1000 так как ненужны? Вроде как естественный процесс выходит

[chukcha]

Да причем здесь  естественный процесс?

 

Вот вап простейший пример

 

Вы генерите случайный номер id

 

Вот вам пример

1 нужно сегенриовать

2. проверить на наличие и в случае наличия - перейти к п.1

 

Второй

Кривой модуль который удаляет заказ, но не удаляет что-то из связанных таблиц (забыл, не учел, не знал!!!!)

 

Генерация, попадает на ранее существующий  - опа-на - потеря заказа!