3,2
рейтинг
9 февраля 2012 в 13:19

Управление → Интеграция сайта с 1С — риски и немного реальности

Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено 75%. То есть, в трех случаях из четырех — придется что-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…

… Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Слоган, который, наверное, никогда не умрет.

Рассмотрим процесс интеграции с точки зрения клиент-исполнитель. Сценарий продажи может превратиться в сущий адъ из-за пары неловких движений менеджера.



Так что знакомимся с горьким опытом и делимся своим:


Фаза предпродажи:




Анализ диалога:

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

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

Как правило, это гарантирует, что штатной интеграции не хватит.

Фаза утверждения технического задания:




Анализ диалога:

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

Договоритесь с заказчиком, чтобы он организовал вам переговоры с программистом, добейтесь того, чтобы программист либо дал вам доступ к выгрузке, либо 100% согласился обеспечить выгрузку и настройки под ваши требования. Зафиксируйте договоренности письменно.

Фаза разработки:




Анализ диалога:

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

Фаза сдачи проекта:




Анализ ситуации:

Ну все, фэйл случился. Теперь проджект-менежер будет пытаться «рулить» удаленным программистом, который не стоит у него в подчинении, и которого он не нанимал. Все зависит от того, какое чувство собственной важности у программиста на стороне клиента… И не дай бох оно будет >9000 :-)

Фаза приемки проекта:




И — дальнейшее развитие событий:



Анализ диалога:

Если давить на программиста заказчика — можно выяснить, что он либо не разобрался в спецификации, либо пробовал, но у него не получилось, либо уже нагородил какого-то своего говнокода или какой-то свой «универсальный» формат, от которого теперь не хочет отступать. Особенная жесть начинается, если ваш клиент платит своему 1С-нику — почасовую ставку, и 1С-ник утверждает, что работа с его стороны займет неделю, из-за ваших «необоснованных» требований (или уникальности «нашей базы»).

Через неделю:



Анализ диалога:

Для краткости показаны только самые сильные ходы ПМ-а. На самом деле можно протрахаться значительно дольше. Вырулить можно, но о попадании в бюджет и срок — уже речи не идет. Виноват — клиент, (в договоре формально закреплено, что выгрузка будет предоставлена в требуемом формате), но это неважно, поскольку цель ПМ-а — запустить проект, а не доказать «виноватость».

Главное, не вестись на разговоры вроде «вы же профессионалы, должны были предусмотреть». Вы предусмотрели и решили продолжить интеграцию, имея открытый риск. А риск, увы, — сработал.

Лечится, как правило, увеличением цены на 2-3-4 человеко-дня со стороны программистов студии, и еще часов 8-16 нервных переговоров со стороны менеджера проектов и клиента. Собственно, отсюда и разница в цене — $N за штатную интеграцию, $MMM — за нештатную.

Нервные клетки не восстанавливаются.

Итого, примерно такой расклад, по основным рискам:


Риск/ситуация Последствия Противодействие
Выгрузка запрошена на этапе пресейла.
  • Клиент поищет кого-то попроще.
  • Слишком много времени уйдет на пресейл, а проект — сорвется.
  • Вынести интеграцию на отдельный этап.
  • Дать «вилку» на лучший и худший случаи.
  • Сообщить заказчику о возможных рисках.
Выгрузка не предоставлена на этапе составления ТЗ.
  • Неправильно спроектирована структура каталога.
  • Срыв сроков и бюджета.
  • Настаивать на предоставлении выгрузки.
  • Вынести интеграцию в отдельный этап.
  • Письменно сообщить заказчику о возможных рисках.
Интеграция вынесена в отдельный этап.
  • Придется переделывать всю структуру каталога.
  • Получить выгрузку до начала проектирования.
1С был модифицирован сторонним разработчиком, имеет устаревшую версию или плохо структурированный каталог.
  • Невозможность выполнить штатную интеграцию.
  • Длительные переговоры с программистом заказчика, потеря времени.
  • Настаивать на соблюдении подписанных требований.
  • Выполнить настройку выгрузки на стороне клиента своими силами.
Выполнение настроек 1С на стороне клиента своими силами.
  • Непрогнозируемая трудоемкость и возможные сложности с нетиповой конфигурацией. Риск «закопаться» в проект.
  • Риск получить в нагрузку к сопровождению сайта — бесплатные консультации по 1С или попасть на исправление каких-то глюков в 1С, которых «не было до вас».
  • Настаивать на соблюдении подписанных требований к выгрузке.
  • Поручить настройку 1С надежному третьему лицу (к которому в случае чего будут все претензии). Кандидатуру согласовать с заказчиком.
Студия настаивает на соблюдении протокола.
  • Риск разрыва отношений по причине отсутствия возможности у клиента — реализовать требования самостоятельно.
  • Затягивание сроков сдачи проекта.
  • Вынести интеграцию с 1С на отдельную фазу.
  • Выполнить настройки 1С самостоятельно.
  • Принять данные в том формате, в котором их способен предоставить клиент.
Программист на стороне заказчика — неуправляем.
  • Длительные, тяжелые переговоры.
  • Срыв сроков.
  • Организовать ежедневные трехсторонние call-ы с заказчиком, его программистом и студией. Решить проблему на более высоком уровне (эскалировать).
Студия прогнулась и согласилась изменить требования протокола под любой формат.
  • Переделка структуры каталога, трудоемкое программирование по интеграции «за бесплатно», сорванные сроки.
  • Закладывать на интеграцию — очень много денег.
  • Запомнить полученный опыт и более не попадаться.
Владимир Завертайлов @zevvssibirix
карма
108,0
рейтинг 3,2
Главный бармалей
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (91)

  • +1
    На мой взгляд, ПМ должен на пальцах максимально просто донести заказчику технические требования не техническим языком. Соответственно, если этот этап будет успешным, то, возможно, заказчик заинтересован в четком соблюдении требований, доведение каждого вопроса до конца и, возможно, чаще будет «пинать» 1С-программиста. Но, конечно, все зависит и от ПМ'а, и от заказчика, и от конфигурации и требований.
    • 0
      ПМ на пальцах должен донести риски до заказчика, их стоимость, а о технических требованиях разговаривать только потом. Из диалогов с Клиентом видно, что о технических вопросах с ним лучше не говорить.
  • 0
    .. от 30% до 50% ... То есть, в трех случаях из четырех

    Не вяжется )
    • 0
      строчку пропустил. Спасибы за замечание =)
  • +6
    Вопрос не стоит выеденного яйца. Не парьте мозг заказчику, он же говорит — в каком формате надо, в таком и сделают. Напишите — формат XML, со структурой: Код, Наименование, Единица измерения, Группа. Волки сыты, овцы целы.
    • +1
      Вот и я также подумал, читая всё это. У нас 4 сайт сейчас поднимается со связью с 1с. Вообще по хорошему программисту 1с и web программисту достаточно пол часа, чтобы чётко определиться с форматом и структурой.
    • +5
      Наверно сайт на Битриксе, другого объяснения краеугольности Commerce ml 2 — не придумывается.
  • 0
    Обычно формат данных который используется при интеграции с внешними системами идет приложением к договору. Это решает кучу проблем. Заказчик до заключения договора может показать формат программистам и узнать трудозатраты со своей стороны. Со стороны студии трудозатраты тоже четко определены до заключения договора.
    • 0
      Последующая гибкость страдает. Хотя, конечно, все зависит от отношений между заказчиком и командой.
      • 0
        Совершенно не страдает. При этом существенно уменьшаются риски. На этапе пресейла согласовывается формат обеими сторонами. Если клиент говорит, что сделают любой формат, то в приложение идет стандартный формат. Если говорят что не могут в стандартном формате, то со специалистами с их стороны обсуждается формат, который устроит обе стороны. Он и идет в договор. При этом на момент заключения договора эта часть работ уже совершенно четко оценена и риски сведены к минимуму.
        • 0
          Согласен с Вами. В таком варианте главное адекватность сторон.
        • 0
          Боюсь, что не всегда так получается. При интеграции сайта с 1С львиная доля затрат уходит не столько на разработку формата и обмена данными, сколько на менеджмент и на согласования, а также на проверки, выгрузки, загрузки данных.
  • +1
    Как спин-офф от сабжа.

    Какой вариант синхронизации лучше?
    1. Выгрузка номенклатуры (помеченной «изменено») из 1С в файл с последующей загрузкой на сайт.
    2. Автоматически, при изменении номенклатуры в 1С, отправлять конкретному скрипту на сайте пакет с данными об измененной позиции.

    • +1
      а как часто нужно менять цены на сайте? проще совместить два варинта: измененная номенклатура где-то копится, а потом отсылается раз в N минут на сайт.
      • 0
        В том то и дело, что смена цены может производиться достаточно часто и в случайном порядке номенклатуры/времени. Сейчас в работе первый вариант, но учитывая объем, который накапливается между расписанием синхронизации, то сама синхронизации может быть достаточно длительной. Руководство планирует сделать задержку между обновлениями цен (1С -> сайт) не более чем на одну минуту, поэтому рассматриваю второй вариант, как максимально приближенную альтернативу к «real-time» режиму.
        • 0
          Я с 1С никогда не работал, но вот такой вопрос.

          А при изменении цены, он может обращаться по сокету на другую машину?

          К примеру на машине где стоит сайт, есть демон который слушает порт и всегда ждет от 1С данных.

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

          1С теоретически такое делать может?
          • 0
            Низкоуровных операций с сокетом выполнять нельзя, добавить триггер на обновление цены можно.
          • 0
            Да, может. Во всяком случае, так утверждает наш 1С-программист: «1С в принципе может все тоже, что и PHP, к примеру».
            • –1
              Штатного класса для работы с этим нет, и скорей всего не будет.
              Через костыли типа ComОбъект(«MSWinsock.Winsock») конечно можно, но получившаяся конструкция будет ужасна.
              А выражения насчет «1с может что и PHP» характерно программистам, для которых 1с — один из очередных изученных языков, а не основной хлеб.
              • 0
                Буду иметь ввиду. Спасибо.
                • +1
                  1С может и гораздо чем больше PHP :)
                  Для обмена (если обмен через файлы) можно использовать систему флагов (текстовых файлов) сервере.
                  Можно обмен делать через XMLRPC со стороны 1С — тогда вообще проблем нет с обновлениями на сайте.
              • +2
                Уж сильно тучи сгущаете.
                1с7, а особенно 1с8 очень хорошо может работать и с сокетами и с базой MySQL напрямую, и через ODBC, и по SSH. На крайний случай можно и по http запросу реализовать.

                Немало организовывал таких обработок. Самый ходовой способ обновления цен и номенклатуры = ssh на сервер MySQL. Как вариант может быть еще: подготовить SQL скрипт, положить на ftp средствами 1С, а там cron уже обработает все это дело.
                Разница в обновлении 1С и сайта будет точно меньше 1 минуты. 1С сама подготовит запрос.

                Вопрос только в том, что нужен грамотный спец по 1С. Он должен и в MySQL сечь, да и в php желательно.

                Очень легко реализуется так же и обратная связь: сайт -> 1С. Хоть напрямую из базы MySQL, хоть по спецстраницам, которые будут выдавать хмл, а 1С будет их парсить.

                В общем, нужно искать спецов, которые ориентируются не только в 1С или php, а которые реально понимают и в том, и в том, да и к тому же могут и в VB или C# что-нить написать несложное. И вот эта связка гарантирует, что вы не попадете в ситуацию, которую описывает автор.
                • 0
                  Это хорошо все делать у себя. Но вот как обязать поставщиков выгружать остатки? Ладно 1с8, там это из коробки, но что делать в случае 1с7?
                  • 0
                    Обязать вообще никак. Мы сейчас с целью объединения «адекватных» поставщиков (ну и разумеется с целью срубить бабла заработать, портал создаем, но подключаем поставщиков только за деньги- эдакая проверка на адекватность… С точки зрения сложности подключения, нам без разницы что там у них за 1С — у нас универсальный шлюз обмена, свой протокол передачи данных (не commerceML2) и даже сильно перепиленный кастом подключаем без проблем…
                    • 0
                      Можно ссылку на ваш портал и направления?
                      • 0
                        Agorab2b.ru про направления не понял, если про отрасли речь, то все, которые представленны в ecommerce. Только начало проекта пока поставщиков крайне мало…
                        • 0
                          А, ну это и есть centrobit, сразу о вас и подумал. Самый последний комментарий Goobs от твоего партнёра. Только шлюз раньше стоил 10т.р.
                          Интеграции в магазин и связывание товаров магазина и поставщика не появилось?
                          API заказа товара появился?
                          • 0
                            Да, это мы:) шлюз отдельно от web- части никогда не продавался. И дешевле 230 000 руб. не стоил никогда. Интеграция остатков поставщика с интернет- магазинами появится в первую очередь для Insales, как доп. модуль. Примерно одновременно выйдет и API. Но это все будет работать только с теми поставщиками, которые подключатся а порталу.
            • 0
              Он явно заблуждается.

              У меня коллега как раз пишет обвязку через COM объекты для реализации варианта 2 именно потому, что штатными методами из 1С это в адекватном виде выполнить нельзя.
          • 0
            Я лично, не знаю, не работал. Основываюсь на описаниях 1с-программиста.
          • 0
            Я видел интеграцию с 1С 7 где она напрямую в mysql изменения писала :)
            • +2
              Делали такой фокус с восьмёркой. Она подключала по ODBC базу на mySQL и заливала туда выгрузку самостоятельно. Весьма эффективно работает.
          • +1
            1C спокойно через com создает у себя xml.http объект, который может в синхронном режиме или асинхронном, делать POST или GET запросы, дальше уже зависит от фантазии на обоих сторонах.
            Типично небольшой вебсервис, который отдает что либо в xml и принимает что либо так же в xml формат xml меняется от случая к случаю, механизм один и тот же. В 1С обработка, которая кончаит с этим сервисом.
            ЧЯДТ?
            Зачем народ до сих пор морочиться с файлами?
            • 0
              Примеров можно надергать с QIWI ищите по слову 1С, качаете смотрите как там работают с вебом.
              Для 7.7. код практически такой же кому интересно могу выложить.
            • 0
              *контачит, сори очепятка
            • 0
              Накопитель очереди на случай временного отсутствия связи так же нужно писать, так? Из коробки это же нет?
              • 0
                много путей реализации, от простого флага в табличке 1с (реквизит справочника), то задействования механизма репликации в v8.x
                Но это намного мощнее чем простые файлы
          • 0
            Давайте определимся с термином «изменение цены». В 1С данный процесс происходит при проведении документа «Установка цен» (название и конкретная реализация зависят от типа конфигурации 1С и ее версии ). То есть, если воспринимать ваше предложение «в лоб», то вешаем триггер на момент проведения документа, и по срабатыванию данного триггера сбрасываем данные в базу сайта тем или иным способом.

            Минусы такого подхода:
            • 0
              1. при проведении документа 1С выставляет определенный набор блокировок, и замедлять процесс проведения документов строго не рекомендуется.

              2. Представьте себе процесс перепроведения ВСЕХ документов установки цен с начала времен.
              • 0
                красиво это в 8ке реализуется через план обмена и регламентные задания, ну может быть ещё через подписки на события. логика типовой даже не пострадает при этом.
                перепроведение разом всех документов установки цен… а зачем?! (но даже это можно в последних версиях отследить и отсечь)
          • 0
            С учетом возможности написания компонентов для 1С есть возможность дергать любые веб-сервисы при изменении цены или количества на складе, а так же опубликовать веб-сервис для получения информации при продаже для уменьшения товара на складе. Но это уже не из коробки и за разумные деньги.
        • 0
          а какой объем номенклатуры?
          • 0
            Около 35 тысяч позиций. Ежедневно, несколько раз в день, может обновляться до 4-5 тысяч.
            • 0
              это не особо большой объем. спокойно можно вешать в модуль проведения документа выгрузку. только в коде надо предусмотреть возможность отключения выгрузки при перепроведении задним числом, или при групповом проведении документов
    • 0
      У нас делается так, выгружается раз в 5-10 минут файлик, содержимое: 2 столбика — код товара, цена.
    • 0
      На мой взгляд второй вариант лучше, однако в нашей практике ещё никто из 1С-программистов клиентов не согласился на такой вариант по различным формальным поводам.

      Как минус второго варианта — при полном обновлении/заполнении базы накладные расходы будут повыше, чем в первом.
    • 0
      Я вот сейчас ищу как в 1С 8.2 УТ понять какая номенклатура изменялась за какой-то промежуток времени. Вроде бы есть Журнал регистрации, но не могу пока что его осилить, к тому же он усекается время от времени. Т.е. если что-то случилось, необходимо повторять полную выгрузку всей базы.
      • 0
        посмотрите регистры сведений. вам нужно изменение конкретных полей?
        • 0
          Скорее какая номенклатура и когда изменялась.
          • 0
            ЖР не лучшее решение. создайте свой регистр сведений. вставьте обработчик в модуль объекта справочника номенклатуры. у вас будет список измененной номенклатуры с указанием всех нужных полей. его можно анализировать и чистить. при таком подходе, при обновлении конфигурации на новый релиз, будет достаточно просто сделать перенос измененных данных.
            • 0
              Спасибо за совет. Мне так все единодушно и говорят: пилите конфигурацию. Потому что плюшек хочется много и разных, но запихать обработку их похоже не удастся.
              • 0
                внешка тоже возможна — но вызывать то ее все равно придется из основной, так что так или иначе конфигурацию править придется.
                • 0
                  Посоветуете какое-то чтиво по написанию своих конфигураций? А то я в 1С-ке еще дошкольник…
                  • 0
                    8,2 — фаритовские курсы однозначно. у них сейчас началась новая программа для начинающих. или за деньги здесь www.spec8.ru (оформление аляповатое, но содержание отличное, поверьте), или бесплатно на всех торрентах страны ))) по книгам — габец «реализация прикладных задач в системе 1с 8.2» она сложная и невнятно написана, но ответы в ней найти можно, совсем для начинающих поищите вот такой файл 1Cv82__Prakticheskoe_Posobie_Razrabotchika__Radchenko_2009.djvu
  • 0
    Поделюсь опытом написания подобных интеграций:
    • 0
      Случайно ctrl+enter нажал:
      Существует штатная обработка фирмы 1С, называется ВыгрузкаЗагрузкаДанныхXML8х.epf
      Она сериализует любой объект системы 1С в xml, плюс если имеются данные по ссылкам — цепляет их.
      В случае потребности в выгрузке данных из 1с клиенту дается эта типовая обработка, показывается как с ней работать и этап настройки выгрузки с 1с на этом закончен.
      Минусом конечно будет являться парсинг этого формата на сайте, но тут карты уже находятся в руках менеджера проекта.
    • 0
      А может быть подскажете как побеждают наличие нескольких магазинов\складов при штатной интеграции 1С и 1С Битрикс?

      Очень был бы благодарен, ибо гугл дает только ссылки на разного рода топики с вопросами, но ни единого ответа. :( тут нужен чей то личный опыт.
      • 0
        Была попытка победить на 90+ точек.
        В результате отказались от Битрикса.
        Правда источник данных — не 1С.
        • 0
          Еще пара нюансов
          Номенклатура 30000+
          Цена на позицию из разных партий в разных точках — разная.
          И обновляется довольно часто.
          XML выгрузка получается ну просто совсем неприличных размеров.
      • +1
        При штатной их не победить. Я переписывал выгрузку номенклатуры с остатками по нескольким складам, в битриксе хранил остатки по разным складам в отдельных свойствах элемента. Но переписывалось это добро не только из-за складов — компании требовалось кастомное решение, сильно отличающееся от типовой выгрузки.
        Также читал о варианте, где в дополнение к штатной интеграции дописали отдельную обработку, выгружающую только остатки по номенклатуре.
      • 0
        Здесь решается все индивидуально:
        1) Базы имеют репликацию и общий каталог справочников.
        2) Базы отдельные и никак не синхронизированы
        3) Если применяется РБД — то какая иерархия баз
        Напиши — в личку подскажу
  • +11
    Есть ещё один нераскрытый в статье нюанс. На моей личной практике, из 14 случаев интеграции с 1С, предварительные работы по приведению в порядок клиентской базы моим 1С специалистом не проводились только 1 раз. И то потому, что мой специалист 1С эту базу изначально и сопровождал. Во всех остальных случаях работы занимали от нескольких недель до 4 месяцев (!).

    Особенно тревожный признак — когда клиент уверенно говорит что ему необходимо показывать на сайте остатки. В 95% случаев это означает, что нас ожидает период ожидания пока клиент не проведёт качественную, полную инвентаризацию.

    Если клиент отказывается от услуг моего специалиста, и сообщает, что у него есть свой штатный программист, то я принимаю решение о работе над проектом только после личного контакта с его программистом.

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

    А вообще, я в таких проектах сразу довожу до клиента, что мы не просто решаем задачу создать ему каталог. Задача намного шире. В результате проведённых работ мы так или иначе будем вынуждены привести в порядок его учётную систему.
    • 0
      А вообще, я в таких проектах сразу довожу до клиента, что мы не просто решаем задачу создать ему каталог. Задача намного шире. В результате проведённых работ мы так или иначе будем вынуждены привести в порядок его учётную систему.
      Этот момент как то указывается в ТЗ и в расчетах стоимости?
      • 0
        Конечно надо указывать в тз не поденитесь написать лист A4 (а то и больше) где опишите всю систему взаимодествия и оюъем работ с возможными рисками. Типовой договор где просто написано мы вам сделаем сайт это удел мелких не профессиональных конторок которые перебиваются от проекта к проекту и врятли пойдут дальше
      • +1
        Да, в ТЗ указывается и на стоимости сказывается.

        1. Услуги 1С-ника выносятся из проекта в отдельный договор. Потому как практически всегда начальная задача «нужна выгрузка» превращается в отдельную задачу «но сначала надо… привести в порядок базу… инвентаризация… (и где-то через месяц) ...».

        2. ТЗ на разработку сайта содержит минимум 2 этапа: эскизное проектирование и вёрстка+программинг. В ТЗ чётко пишется, что второй этап, он конечно наступает по плану такого-то числа, но если к этому моменту выгрузка не будет предоставлена, то второй этап откладывается на столько на сколько мы ждём выгрузки. Это при том, что над выгрузкой работает наш же специалист.

        Это позволяет клиенту тоже почуствовать ответственность за сроки проекта. Я работаю с весьма грамотным 1С-ником, поэтому как только он начинает работать с клиентом, у того обычно отпадает желание катить бочку на пустом месте. Сориться со спецом который решает ему очевидные проблемы с учётной системой клиент уже не хочет. Если заказчик неадекватен на столько чтобы такое вытворять, то это проявляется ещё на предпродажах, и ТЗ с такими заказчиками даже не появляется на свет.

        Вообще, главное в этих проектах не испытывать иллюзий самому, и как можно быстрее возвращать клиента на землю. Тут всё просто, либо он понимает что есть объективные проблемы, но есть и Исполнитель в нашем лице, который их решит, либо клиент ищет кого-то ещё, а мы берёмся за следующий проект.
    • 0
      А интегрируйте с 1С-Битрикс или с произвольными системами с обязательной прической 1С стороны?
  • +7
    Пока читал скриншоты потерял 146 нервных клеток.
  • +7
    Есть еще такое правило — «не работать с идиотами». Что не говорите но в студии должно присутсвовать такое понятие как «выбор клиента», когда еще на этапе обсуждения становится понятно, что все будет плохо, наждо оценивать такие риски и возможно дешевле не работать с клиентом.
    Самое главное правило — это клиент обычно не разбирается в тонкостях да и вообще в вопросах программировани и это нормально! Ваша задача как менеджеров предвидеть проблемы, информировать о них клиента, если требуется письменно обговаривать их в договоре. И если клиент на этом этапе не может и не хочет услышать вас, не принимает участие в дискуссия и не отвечает на вопросы, сотрудничество бесполезно.
    для таких клиентов существует только 1 вариант сотрудничество: наш час стоит 30евро (или какая там у вас цена) и мы готовы выполнять любые ваши пожелания ))
    • 0
      Одним из очевидных плюсов фриланса, является право «уволить клиента». Если уже наработано портфолио и репутация и есть постоянный поток заказчиков, то появляется возможность управлять описанными в топике рисками.
      У менеджера в студии может просто не быть шанса отказать «клиенту-идиоту». И это печально опыт.
      • +1
        Это в каком плане не быть шанса? Если клиент к вам пришел и он не адекватен, то зачем с ним работать? Денег с него все равно не поиметь. А если у вас подписан договор по которому клиен тс вами творит что угодно за копейки, то это уже вы простите «лох» и тут медицина бессильна.
        • 0
          Если вы простой менеджер в шаровой конторе которая принципиально берётся за всё, ибо такова политика руководства — у вас может не быть шансов «уволить клиента» не будучи уволенным самому. А может и быть. Зависит от политики в этой компании.

          Но честно, вот тот кошмар который описывает автор топика, он по какой причине стал явью? Почему клиента не развернул и не пожелали удачи? Видимо всё-таки были обстоятельства заставляющие взяться за откровенно клинический случай. Что-то же не позволило «уволить клиента»?
          • 0
            В компании которая берется за все обычно и менеджеров нет а если и есть то сидит 1 убогий. Во вторых вам зп платят? Договор подписывали ну и ок. Пришел тупой клиент от которого будут одни проблемы. поставил в известность руководство и сиди себе делай свое дело, если все выльется в полну ж** это уже не твои будут проблемы.
  • +3
    Может, кому-то будет полезно.
    В моей организации большая база абонентов на 1С, почти полмиллиона.
    Написал на питоне скрипт, который соединяется с 1С через COM-соединение, выполняет различные запросы (список лицевых счетов, оплаты, начисления, долги, показания счетчиков) и выгружает их в SQLite-базу, к которой потом можно подключиться из любого языка. Скрипт грузит данные только ночью, в рабочее время из базы идет только чтение. Таким образом, можно получать актуальные данные в личном кабинете, в платежных системах и др.
  • +1
    Все эти Commerce ml не раотают на больших и сложных объёмах, приходится писать на прямых SQL запросах.
  • 0
    Был случай, когда сайт написался за 5 дней, и 2 месяца шла интеграция с 1С, при том, что выгрузку сделали в удобном всем CSV. Проблемы:
    1. Разговор слепого с глухим. Термины программиста на 1С и веб-разрабочтика немного различаются. На 100% они друг друга не понимают.
    2. Передача данных тоже требует костылей. Хорошо если админ сможет настроить выгрузку-загрузку на хостинг CSV(или XML ит.д.) файлов по раписанию.
    3. Все тонокости выгрузки можно учесть только во время обработки полных данных.
    • 0
      Ваш случай, к сожалению, типовой. Всё упирается в то, что у клиента попросту база не может быть выгружена нормально, т.к. по остаткам там адъ и много проведённого задним числом.

      1. На счёт разговора веб-разработчика и 1С-ника, тоже чистая правда. Со своим 1С спецом работаю уже 8-й год, но и то бывают пробуксовки. Когда писал SOAP библиотеку на Perl для вызова внутренних процедур 1С — мы оба чуть не рехнулись. У него всё работает, а КАК оно работает на уровне HTTP протокола он не знает. И обвинить его ни в чём нельзя — более высокоуровневое программирование. Мне пришлось писать снифер, который ловил передаваемые 1С-кой данные.
      С другой стороны это ещё цветочки. Мы вместе собственно потому и работаем что в целом нашли общий язык и клиент не страдает от проблем нашего взаимопонимания.

      2. Лично убедился что этот пункт сильно зависит от компетенции даже не админа, а 1С-ника. Один сам сделает так, что 1С и выгрузку по расписанию сделает, и по FTP всё на сайт выложит, и скриптину-обработчик сама дёрнет, а то и вообще по ODBC прямо на SQL-сервер всё сайта зальёт. А другой с умным видом кинет CSV по почте — и попробуй ещё спасибо не скажи.

      3. истинно.
  • 0
    Судя по описанию получается, что это сайт на 1С-Битрикс, так?
    • 0
      Фигурирует слово инфоблок. Он вроде только в битриксе есть, в других местах по-другому называется.
      • 0
        В том-то и дело, что не факт. Я бывает его использую и вне контекста битрикса если нужно объяснить схожий концепт и я знаю, что собеседник работал с битриксом.

        Как по мне, так вполне удачный термин. Короткий, информативный и не такой абстрактный как «объект».
  • 0
    Блин… волосы дыбом встали от воспоминаний.

    Два года назад мы пытались сделать интеграцию с SAP на одном проекте, причем со своей стороны сделали абсолютно ВСЕ для этого — даже сделали простенький stub server для тестирования, когда они протормозили с выдачей доступа к sandbox SAP web services. Потом нам таки выдали тот тестовый доступ на sandbox… и для этого пришлось поднимать проприетарный VPN. Который естественно не работал под Linux, под которым работало наше веб-приложение. Технари конторы надули губы и сказали — «сами дураки! Вот еще, нашлись тут гики… сайты под линуксом хостят, школота какая. Windows наше все!» Точка в разговоре по интеграции с SAP была поставлена QA-менеджером, которая сказала прямо: «интеграции не будет, потому что это запрещено нашими протоколами» — и это после того, как была сделана вся почти вся техническая работа, не говоря уже о согласовании ТЗ с менеджером по проекту. Смутно помню, как после многонедельной (и весьма нервной) разработки слоя интеграции я объяснял шефу вслух, кого и в какие дыры я бы хотел уестествить самым садистским образом… он грустно улыбался, поддакивал, и говорил — «то ли еще будет». Время показало — он был прав, но это уже другая история.

    Коллеги, я когда-нибудь напишу про это статейку, но сейчас хочу сказать — если менеджмент в компании болен на голову, то проект с ними точно приведет к потреблению успокоительных, и надо четко решать, стоит ли оно того.
    • 0
      ну какбы предоплата рулит:)
      • 0
        Цифра контракта была ну совсем не та для 100% предоплаты, и размер заказчика имел некоторое значение.
  • +4
    Ещё один простой и эффективный тест по теме, из личной практики.

    В 1С есть стандартная функция выгрузки прайса. «Напечатать прайс» — как-то так, не помню точно. Вы просто спрашиваете у потенциального заказчика, может ли он сейчас, вызвав эту функцию, получить прайс который ему будет не стыдно положить на стол его покупателям/клиентам.

    Если нет, если «ну у нас там нюансы в базе» — похороните все мечты, что вы обойдётесь стандартными загрузками. Этому не бывать. Там как минимум вас ждут нюансы. Им есть там где быть: по ценообразованию, складской учёт (будь он неладен), кое-где задвоенная номенклатура, и ещё что- нибудь от чего их штатный 1С-программист спит некрепким сном.

    Задача связать сайт с 1С — это вскрытие многих косяков в работе 1С-ника. Не всем это понравится, от сюда и соответствующее поведение «отстранённого 1С-гуру» который на деле саботирует процесс. Очень мало профессионалов которые сядут и вместе с вами разработают структуру передаваемых данных и согласуют её, естественно письменно.
    • 0
      Пожалуй, у вас самый простой, быстрый и действенный способ проверки качества базы. Спасибо.
  • –1
    Из данной статьти понятно, что Программист 1С идиот.

    У нас в компании мягко говоря не типовая конфигурация. Все это скрещиваем с приложением на ruby'on'rails. Ни разу, НИ РАЗУ я не слышал слов от программиста: «Мы так делать не будем, т.к бла-бла-бла..». Какие требования выдвигали разработчики части на рельсах, такие и делали. Это программирование, тут частота слов «так нельзя» равна уровню безграмотности программиста.
    • 0
      Да, чуть не забыл. Программист на стороне заказчика управляем, если сразу расставить все точки на i. Если программист пасется на свободном выгуле(нет айти директора), то да. 99% что хамло с завышеным ЧСВ.
  • –1
    Гребанные монополии.
  • 0
    Спасибо, буду менеджерам ссылку на пост давать. Спросят — сколько по времени занимает интеграция с 1С — отвечу вот ссылка там всё написано.
  • +1
    Отличная статья демонстрирующая как делать НЕ надо.

    У нас в договоре прописано жирным шрифтом, что мы делаем настройку стандартного модуля CMS интеграции с 1С Предприятие 8.2 Управление торговлей на стороне сайт. Все работы по программированию и настройке со стороны ПО 1С Заказчик осуществляет самостоятельно.
    Только за то что мы расставим галочки в нужных места на стороне сайта мы выставляем счет в 40 часов!

    Мы громко и внятно доносим эту мысль до Заказчика на этапе пресейл 100 раз акцентируя его внимание на этом.

    Если Закачика это не устраивает — это не наш пассажир.
    При таком подходе риск минимален, а 99,9% контрактов заканчиваются успешно!

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

    Тоже самое с минимальными техническими требованиями к хостингу.

    Всё моё имхо.
  • 0
    Статья хороша!
    Единственно, очень неудобно читать с телефона скриншоты мессенджера. Неужели нельзя было просто текстом оформить переговоры?
  • 0
    Многие производители CMS утверждают, что решают вопрос интеграции сайта с платформой 1С. При этом, никто не объясняет на каком уровне и насколько универсально это реализовано. С проблемами cталкиваешься уже в процессе работы над проектом.

    Первичный анализ самых популярных CMS показывает, что почти со всеми из них 1С взаимодействуют через модуль “Обмен с сайтом”. Боюсь показаться не оригинальным, но этот обмен морально устарел и вот почему:

    1. Протокол CommerceML — это вообще не протокол, а формат, который постоянно приходится менять под каждый проект. Он разрабатывался не для обмена с сайтом, а для обмена между двумя системами 1с, например для синхронизации заказов между двумя филиалами.
    2. Возможности ограничены обменом номенклатурой и заказами (причем заказы отправляются только с сайта в 1С).
    3. Изменить формат обмена можно только разобравшись в кодах.
    4. Расширить количество объектов обмена можно только глубоким программированием, как со стороны сайта так и со стороны 1С.
    5. Диагностировать неисправности обмена и его остановку не возможно.
    6. Главное — не предусмотрена пообъектная отправка и обработка данных. Это не позволяет понять успешно ли обработан запрос от 1С к сайту или часть запроса не обработалась. Например, 1С получает с сайта 2 заказа, при создании одного из них происходит ошибка и заказ не создается. На этом обмен заканчивается и второй заказ никогда больше в 1С не выгрузится, только при помощи ручной правки.

    Я могу перечислять ещё долго, но думаю этого хватит. В нашем стартапе Centrobit.ru (создаем B2B системы электронной коммерции на собственной платформе Agora), мы решаем эти проблемы, разработав собственные модули обмена для каждой платформы 1С (7.7,8.1 и 8.2) и других ERP. У нас даже есть обмен с сайтом для CMS Bitrix, возможно их заинтересует наше решение.

    Суть нашего подхода в следующем “Меньше программируй, больше настраивай”. Если настройки не достаточно, то не надо ковыряться в кодах, можно просто использовать API функции нашего обмена. Формат обмена легко меняется через XDTO пакет (для 1С 8.1 и 8.2) без программирования.

    В заключение могу сказать — проблема эта у всех на слуху, но пока никто не предложил хорошее решение, надеюсь, нам это удастся.

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