столкнулся с ситуацией, которую считаю багом.
Предположим, Иванов И.И. зарегистрировался, оформил заказ, получил его. Через какое-то время решает оформить новый и меняет (не важно для чего, просто потому, что может) свои данные на Петров П.П.
В следствие этого предыдущий уже закрытый заказ тоже меняется на Петрова П.П.
Это категорически неправильно. А если такой финт делает покупатель не Персона, а Компания, это трижды неправильно.
1С, в которую перегружаются заказы, вообще с ума сходит от этого.
Можно ли сделать так, чтобы
1) в закрытые заказы никаких изменений не вносилось?
2) установить запрет для клиента на редактирование некоторых полей в ЛК?
8 комментариев
Аналогичная история тут и до сих пор с декабря 2019 года рассматривается https://support.webasyst.ru/forum/34504/ischeznovenie-telefona-i-pochty-klienta-iz-zakaza/
Вот у кого-то такая ситуация сложилась https://support.webasyst.ru/forum/28950/zakaz-bez-imeni/
И тут https://support.webasyst.ru/forum/35695/zamena-uchyotnykh-dannykh-v-bekende-pri-oformlenii-zakaza-v-korzine/
И до кучи https://support.webasyst.ru/forum/31949/novye-polya-dlya-kompanii-ne-poyavlyayutsya-pri-dobavlenie-zakaza-v-adminke-poka-ne-ukazat-ikh-v-nastroykakh-lyubogo-oformleniya-zakaza/
Запретить редактировать телефон и почту и всякие другие поля можно, но что в таком случае останется от ЛК покупателя? Смотрелка статусов заказов и личных данных? На стадии оформления заказа заменить данные точно так же можно и всё перезапишется снова. Пока WA полностью не поменяют подход к работе с идентификационными данными контакта!!! и идентификационными данными контакта в заказе!!! (это должны быть данные из разных хранилищ), ничего хорошего в этом плане не придумать. На это всё ещё наслаивается поиск по заказам и покупателям, который должен уметь вытаскивать данные из хранилища заказов, а не только контактов. При наличии разных хранилищ данных (часть из которых клиент подменить уже не может) можно вообще историю изменения данных контакта выстроить по цепочке заказов. Это даже бонусом будет для администратора, т.к. иной раз история коррекции данных нужна, чтобы отследить на каком этапе что менялось и когда Иван стал Марьей.
Уже прорабатывал варианты второго набора данных контакта, которые кладутся в заказ на момент оформления в виде запаски, но всё равно это костыли и помогут только не потерять данные совсем (при остутствии СМС и/или почтовых отправок на момент проверки), а работать с ними без модификации шаблонов и запросов в админке всё равно неудобно. Проблема в неправильной логике основы этого процесса.
да уж... ошибка глубинная. на уровне непонимания архитектуры БД.
Немного лирики. :)
Думаю, что дело не в архитектуре БД, а в том, что хотели всё упростить до предела и данные контактов выносили так, чтобы доставать их из разных приложений системы. И на этом этапе забыли, что заказы остались без своего запасного набора данных. Связь между контактом и заказом конечно же есть. А какой толк от этой связи, если она связывает заказ с контактом с неправильными данными?
Теперь мы не имеем правильных данных на момент оформления, потому что их попросту нет в заказе! Любые поля контакта (ФИО, адрес/индекс, почта, телефон, ИНН и т.п.) при оформлении заказа должны быть сразу же сохранены в заказ и выводиться в заказе доп. информацией. Данные эти может поменять только админ и только в конкретном заказе, если это необходимо.
Очень хочется иметь функциональный личный кабинет покупателя, но сейчас этого не сделать без риска потери критичных данных в заказах.
Если обратить внимание на клиентов с несколькими заказами, то часто мы видим такое
Это те самые данные из нескольких заказов, утащенные в таблицу wa_contact_data с разными ключиками sort по мере поступления заказа с новым набором, но касаются они только адреса в момент оформления. В заказе эти же данные лежат в неприкосновенности. И это хорошо в отношении только этих данных.
Кстати, вся эта история - хорошая идея для плагина, который бы организовывал в таблице заказов ещё одно хранилище полей данных и страховал магазин от их потери. Даже название рабочее есть "Важные данные клиента в момент оформления заказа".
Объясните почему, пожалуйста.
клиент юр.лицо оформляет из своего ЛК сегодня от имени ООО "Рога и Копыта", а завтра от имени ИП Пупкин. после этого первый заказ становится тоже заказом Пупкина.
при этом клиент id.1 перегружен в 1С с ИНН 1111, а потом под id.1 оказывается клиент с ИНН 2222
Михаил, мне стыдно это Вам объяснять. Честное слово.
Вредительство со стороны сотрудника ныне уволенного, а ранее оформлявшего заказы от компании не рассматривали?
Обиделся на весь мир. Заменил учетные данные и поменял пароль. Все заказы компании в этом магазине обезличились.
Только вот навредил он не компании, а магазину. Это беда не для компании, а для магазина! Но сотрудник бывший этого даже и не понял, а магазину теперь расхлебывать кашу т.к. при поступлении нового заказа сопоставление и коррекцию делать надо. Старый аккаунт корректировать, с новым аккаунтом этой фирмы всё объединять, чтобы заказы передались новому. Целая история однако.
можно было бы копнуть так глубоко, если бы на поверхности не лежало достаточного количества проблем
Становится невозможным однозначный ответ на вопрос "что было?". Кому отправили товар? А если возврат, обращение по гарантии, бухгалтерская сверка, налоговая проверка, из полиции в конце концов придут и начнут задавать вопросы... Да что угодно... Мы же тут не домашние странички делаем, а интернет-магазины, которые работают с клиентами за деньги и иногда довольно не маленькие!