Pull to refresh

Comments 91

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

Не вяжется )
строчку пропустил. Спасибы за замечание =)
Вопрос не стоит выеденного яйца. Не парьте мозг заказчику, он же говорит — в каком формате надо, в таком и сделают. Напишите — формат XML, со структурой: Код, Наименование, Единица измерения, Группа. Волки сыты, овцы целы.
UFO just landed and posted this here
Наверно сайт на Битриксе, другого объяснения краеугольности Commerce ml 2 — не придумывается.
Обычно формат данных который используется при интеграции с внешними системами идет приложением к договору. Это решает кучу проблем. Заказчик до заключения договора может показать формат программистам и узнать трудозатраты со своей стороны. Со стороны студии трудозатраты тоже четко определены до заключения договора.
Последующая гибкость страдает. Хотя, конечно, все зависит от отношений между заказчиком и командой.
Совершенно не страдает. При этом существенно уменьшаются риски. На этапе пресейла согласовывается формат обеими сторонами. Если клиент говорит, что сделают любой формат, то в приложение идет стандартный формат. Если говорят что не могут в стандартном формате, то со специалистами с их стороны обсуждается формат, который устроит обе стороны. Он и идет в договор. При этом на момент заключения договора эта часть работ уже совершенно четко оценена и риски сведены к минимуму.
Согласен с Вами. В таком варианте главное адекватность сторон.
Боюсь, что не всегда так получается. При интеграции сайта с 1С львиная доля затрат уходит не столько на разработку формата и обмена данными, сколько на менеджмент и на согласования, а также на проверки, выгрузки, загрузки данных.
Как спин-офф от сабжа.

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

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

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

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

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

1С теоретически такое делать может?
Низкоуровных операций с сокетом выполнять нельзя, добавить триггер на обновление цены можно.
Да, может. Во всяком случае, так утверждает наш 1С-программист: «1С в принципе может все тоже, что и PHP, к примеру».
Штатного класса для работы с этим нет, и скорей всего не будет.
Через костыли типа ComОбъект(«MSWinsock.Winsock») конечно можно, но получившаяся конструкция будет ужасна.
А выражения насчет «1с может что и PHP» характерно программистам, для которых 1с — один из очередных изученных языков, а не основной хлеб.
Буду иметь ввиду. Спасибо.
1С может и гораздо чем больше PHP :)
Для обмена (если обмен через файлы) можно использовать систему флагов (текстовых файлов) сервере.
Можно обмен делать через XMLRPC со стороны 1С — тогда вообще проблем нет с обновлениями на сайте.
Уж сильно тучи сгущаете.
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# что-нить написать несложное. И вот эта связка гарантирует, что вы не попадете в ситуацию, которую описывает автор.
Это хорошо все делать у себя. Но вот как обязать поставщиков выгружать остатки? Ладно 1с8, там это из коробки, но что делать в случае 1с7?
Обязать вообще никак. Мы сейчас с целью объединения «адекватных» поставщиков (ну и разумеется с целью срубить бабла заработать, портал создаем, но подключаем поставщиков только за деньги- эдакая проверка на адекватность… С точки зрения сложности подключения, нам без разницы что там у них за 1С — у нас универсальный шлюз обмена, свой протокол передачи данных (не commerceML2) и даже сильно перепиленный кастом подключаем без проблем…
Можно ссылку на ваш портал и направления?
Agorab2b.ru про направления не понял, если про отрасли речь, то все, которые представленны в ecommerce. Только начало проекта пока поставщиков крайне мало…
А, ну это и есть centrobit, сразу о вас и подумал. Самый последний комментарий Goobs от твоего партнёра. Только шлюз раньше стоил 10т.р.
Интеграции в магазин и связывание товаров магазина и поставщика не появилось?
API заказа товара появился?
Да, это мы:) шлюз отдельно от web- части никогда не продавался. И дешевле 230 000 руб. не стоил никогда. Интеграция остатков поставщика с интернет- магазинами появится в первую очередь для Insales, как доп. модуль. Примерно одновременно выйдет и API. Но это все будет работать только с теми поставщиками, которые подключатся а порталу.
Он явно заблуждается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всё моё имхо.
Статья хороша!
Единственно, очень неудобно читать с телефона скриншоты мессенджера. Неужели нельзя было просто текстом оформить переговоры?
Многие производители 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) без программирования.

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

Articles