Программная инициация событий. Отправится ли сообщение?

Скажите, пожалуйста.

Если мы программно инициируем событие, будет ли отправлено сообщение, которое повешено на это событие?

Например, мы при обмене с 1С пишем трек номер в соотв. поле заказа сайта. Пишем напрямую в БД. По сути, мы вызываем событие "Изменить параметры доставки".
Сработает ли событие в этом случае? Если нет, то как осуществлять такие штуки?

Тоже самое касается других событий: добавить комментарий, выполнен, и тд.

5 ответов

  • 3
    Евгений Леман 19 января 2018 11:47 #

    "программно" и "напрямую в бд" это антонимы. Вообще у вас будет много проблем с различными плагинами, если вы напрямую в базу всё пишите. Плагины этого просто не увидят. Иными словами, ваша синхронизация некачественная. Даже костыльная :)

  • 1
    Семен Семеныч 20 января 2018 13:11 #

    А если возникнет следующая ситуация?

    На сайте у заказа есть определенный статус, который не предусматривает какое-то действие, например, "Отправлен".
    А мы программно пытаемся вызвать это действие. Что будет в этом случае?

    Суть в том, что мне надо, чтобы на сайте заказы были четко в том же статусе, который есть в 1С.
    В 1С, в УТ 11 есть состояния: На согласовании, В процессе отгрузки, Закрыт и тд.
    Эти состояния будут сопоставлены со статусами сайта. И мы будем приводить статусы сайта в соответствие с состояниями заказа в 1С. Инициатором изменений будет выступать 1С. И 1С является ведущей в этой связке, все заказы на сайте, в конце концов должны придти в тот же статус (или в терминологии 1С - в "состояние"), которое есть в 1С.

    Обработка заказов ведется в 1С, и оттуда данные идут на сайт: т.е. в 1С мы отмечаем согласование заказа, проводим оплату, отменяем заказы и тд. И все эти состояния 1С передаются на сайт как статусы (допустим, проведение определенного документа в 1С, вызывает определенное действие на сайте, которое инициирует перевод заказа на сайте в другой статус).


    Но, гипотетически может оказаться так, что на сайте изменят руками статус (это не штатная ситуация, но она возможна), он станет, например, "Удален", а в 1С этот же заказ в статусе "На согласовании", и 1С, при получении оплаты попытается провести этот заказ в состояние "В процессе отгрузки", и передать на сайт действие "Оплачен", но для статуса "Удален" не предусмотрено действие "Оплачен".

    Примерно так, у меня сейчас работает обмен 1С и ВА 301 версии. Но, там статусы пишутся жестко в БД. Т.е. никаких действий, событий и тд. 1С при изменении состояния заказа, лезет в БД сайта и там меняет статус заказа. 1С затирает своими данными, данные сайта.

    И еще вопрос: где хранятся действия? И где их вызывать? В БД не нашел.

    • +2
      info@ravencode.ru info@ravencode.ru 20 января 2018 14:08 #

      Повесьте событие на редактирование заказа (backend_order_edit) и отслеживайте изменения.

      Или добавьте mysql триггер на обновление статуса заказа, при обновлении добавляем запись в свою таблицу-лог. Ну и повесить на крон скрипт который будет раз в 10-15мин проверять лог, если он не пустой, то посылаем новые данные в 1с и очищаем лог.

      • +1
        Семен Семеныч Семен Семеныч 20 января 2018 14:18 #

        "Повесьте событие на редактирование заказа (backend_order_edit) и отслеживайте изменения."

        Хм, спасибо, но не понял что это даст нам в обсуждаемом контексте. Если мы редактируем заказ на сайте, то это и так можно отследить. Но, зачем это в данном случае?


        "Или добавьте mysql триггер на обновление статуса заказа, при обновлении добавляем запись в свою таблицу-лог. Ну и повесить на крон скрипт который будет раз в 10-15мин проверять лог, если он не пустой, то посылаем новые данные в 1с и очищаем лог."

        Тоже не понял, как именно это использовать. Вопрос то у меня сейчас в том, что будет если мы попытаемся программно выполнить действие, которое не предусмотрено для текущего статуса заказа.

        • +2
          info@ravencode.ru info@ravencode.ru 20 января 2018 14:28 #
          Но, гипотетически может оказаться так, что на сайте изменят руками статус

          вот эту гипотетическую ситуацию я и описал как отловить.

          • +1
            Семен Семеныч Семен Семеныч 20 января 2018 14:33 #

            Отловили ее. А дальше?

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

            Как я вижу это: после определенных действий в 1С, 1С передает на сайт инициацию определенного действия. Это действие вызывает событие, которое вызывает отправку сообщения или меняет статус заказа.
            Если 1С отправляет на сайт действие, которое неприменимо к тому статусу, который есть у этого заказа на сайте, то 1С принудительно перезаписывает статус заказа в БД на свой статус.
            Но, тут есть один вопрос: чтобы 1С знала, что ей надо принудительно писать статус в БД, ей надо получить с сайта инфу, что действие, которое 1С пытается передать на сайт недопустимо для этого заказа. Т.е. надо гонять данные туда сюда, а это долго.
            Либо, 1Су надо вызывать действие, а потом ВСЕГДА перезаписывать статусом 1С статус заказа в БД сайта.

            Так мы добьемся того, что статусы на сайте всегда будут соответствовать статусам в 1С, при условии, что 1С в этой связке главная.

            • +2
              info@ravencode.ru info@ravencode.ru 20 января 2018 15:44 #

              Я не понимаю что Вам мешает перед выполнением действия сравнить статус заказа в ss и в 1с? данные действия и статус передаются в гейт, гейт корректирует при необходимости статус и вызывает действие. Хотя если так рассуждать, то почему изменение статуса заказа произойти может, а скажем случайное удаление\списание товара нет? По мне так проще ограничить доступ к магазину просмотром.

              • +1
                Семен Семеныч Семен Семеныч 20 января 2018 19:51 #

                Я видимо просто не понимаю о чем вы говорите (т.к. я не прогер).

                Т.е. мы сравнили статусы. Если статусы на сайте и в 1С отличаются, то дальше что происходит?

        • +2
          info@ravencode.ru info@ravencode.ru 20 января 2018 14:32 #

          кстати что мешает заблокировать на сайте редактирование заказа через те же хуки? а если из 1с в магаз данные идут через wa api, то просто добавьте для этого пользователя\группы исключение.

      • +2
        Евгений Леман Евгений Леман 20 января 2018 14:35 #

        Тут староверы. Всем управляют через 1С(aka удобство и совершенство). Правда не совсем понятно зачем тогда на сайте соответствие статусов выполненных заказов, если процессы все ведутся через 1С.

        2ТС, отсутствие документации по workflow конечно недостаток. Раз в полгода-год появляются задачи по работе с ним. И тоже каждый раз приходится самому ковырять код, чтобы вспомнить и понять. Ковыряйте в сторону shopWorkflow. Для каждого заказа можно, например, узнать доступные действия. Их же можно настроить в настройках магазина(статусы заказов). Конкретно в описанном случае можно просто разрешить действие "отправлен" для удаленного заказа.

        Но да, документация с примерами не помешала бы. И новичкам проще, и другим шпаргалка.

        • +2
          Евгений Леман Евгений Леман 20 января 2018 14:39 #

          Либо просто обратитесь к Олегу Гаману(cms1c). Они за годы практики вроде научились делать качественную синхронизацию. Надо только попросить :)

          • +1
            Семен Семеныч Семен Семеныч 20 января 2018 14:51 #

            Я их модуль как раз и использую и на старом сайте, и сейчас на новом. Мне надо им поставить сейчас эту задачу, т.к. в типовом варианте они пишут именно в БД статус, а я хочу, чтобы они передавали на сайт действия.

            И я хочу сам еще понимать как это будет работать. А, то, буду думать, писать ТЗ, а потом окажется, что так сделать нельзя, и придется заново изобретать.

        • +1
          Семен Семеныч Семен Семеныч 20 января 2018 14:48 #


          кстати что мешает заблокировать на сайте редактирование заказа через те же хуки?
          Тут староверы. Всем управляют через 1С(aka удобство и совершенство). Правда не совсем понятно зачем тогда на сайте соответствие статусов выполненных заказов, если процессы все ведутся через 1С.

          Ваши вопросы обоснованы. Типа, зачем нам заморачиваться всем этим, если мы все равно с заказами работаем в 1С, а не на сайте.


          Но, это надо, т.к. в связке 1С-Сайт есть 2 звена: 1С и сайт. Если мы имеем возможность управлять заказами ТОЛЬКО из 1С, то при сбое в одном из этих двух звеньев, блокируется работа всего магазина. Вероятность сбоя в этом случае будет суммой вероятностей сбоев в каждом из звеньев.

          И такое уже было, когда ночью хакнули 1Совский сервак и он лег. В итоге, утром смогли продолжить работу как раз потому, что мы можем это делать как на сайте, так и в 1С. Когда восстановили сервак просто прогрузили все пропущенные заказы в 1С, провели по ним документы (оплаты, отгрузки и тд), и заказы на сайте пришли в соответствие с 1Сом. Т.е. всё стало опять единообразно, чинно и благородно.

          Т.е. мы можем работать с заказами как на сайте, так и через 1С. При этом на сайте мы видим какие заказы разрешены к отгрузке, по каким поступила оплата, по каким нет, и тд. Т.е. оператор видит там практически тоже самое, что и в 1С.

          А если мы не будем передавать из 1С на сайт все эти действия именно как действия, а будем просто писать в БД статус, то не будут срабатывать события, соответственно не будут отправляться уведомления, не будут начисляться или сниматься бонусы покупателям, еще что-то наверное.

          Сообщения сейчас отправляет 1С. Но, опять таки, иметь запасной канал, это хорошо.

          • +1
            info@ravencode.ru info@ravencode.ru 20 января 2018 16:10 #

            это надо решать созданием резервного сервера 1с, а не кучей проверок в корявом коде магазина. в итоге он будет тормозить из -за лишней нагрузки и пострадают продажи. Eсли SS у вас выступает в качестве витрины, то пусть ей и будет. даже если не будет резервного сервера 1с, то можно будет просто добавить менеджеров в группу с правами на редактирование одним кликом.

            • +1
              Семен Семеныч Семен Семеныч 20 января 2018 19:54 #

              Резервный сервер это деньги. У меня не Озон и не Юлмарт. Бэкапы делаются постоянно. Но, иметь возможность параллельной работы, это плюс.

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

              • +1
                info@ravencode.ru info@ravencode.ru 22 января 2018 08:57 #

                Аренда облачного сервиса 700р в месяц, эту сумму думаю может себе не только озон позволить))

                Честно говоря слабо представляю как Вы это сделаете без модификации кода самого приложения - права доступа и события в wa реализованы слабовато.

                • +1
                  Семен Семеныч Семен Семеныч 22 января 2018 15:03 #

                  За 700р 1С сервер не развернешь, либо если развернешь, работать на нем будет нереально, либо будет дырявый, т.к. общий, ну и тд. Вообщем, как начнешь погружаться в вопрос, эти 700 превратятся уже в несколько тыш ежемесячных расходов.

                  • +1
                    info@ravencode.ru info@ravencode.ru 22 января 2018 22:36 #

                    как резерв подобный вариант вполне возможен

                    • +1
                      Семен Семеныч Семен Семеныч 22 января 2018 22:43 #

                      А как например бонусы начислять, или списывать в случае возврата, если заказы не будут проходить через цепочку действий?

                      Как делать рассылки покупателям, которые купили то, но не купили что то другое? Ведь, эта инфа накапливается именно на сайте. В 1С этого функционала нет, и его надо специально пилить.

                      • +2
                        info@ravencode.ru info@ravencode.ru 22 января 2018 23:58 #
                        А как например бонусы начислять

                        SS это будет автоматически делать исходя из настроек,

                        или списывать в случае возврата

                        опять же SS.

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

                        • +1
                          Семен Семеныч Семен Семеныч 23 января 2018 11:02 #

                          Спасибо. В общих чертах я что-то понял, дальше уже буду общаться с синхронизаторами ВА и 1Са.

  • 1
    Семен Семеныч 19 января 2018 00:32 #

    Изменил трек номер руками в БД, событие не сработало :(

  • 1
    Семен Семеныч 19 января 2018 12:05 #

    Спасибо. А как правильно?

    Просто модуль синхронизации уже есть, но его надо доработать и мне надо правильно поставить задачу 1Сникам.

    Хочу, чтобы при передаче данных из 1С (запись в регистр или проведение документа или изменение какого-либо допреквизита и тд) срабатывали события.

  • 1
    Семен Семеныч 29 января 2018 20:27 #

    Поговорил с 1Сниками и возник вопрос: куда и что надо писать в БД, чтобы запустить какое либо действие? Если, конечно, вообще через БД можно запускать действия.

    И, может быть, вообще есть смысл просто передавать статусы из 1С на сайт сразу в БД и не париться? На что влияет то, что мы переведем в статус не с помощью действий, а директивно? Мне на ум ничего, кроме списания бонусов в случае возврата товара не приходит. МОжет быть что-то еще?

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите