Лет пять назад пытались состыковать с ним 1С в одной строительной компании, куда меня взяли главбухом. Дело двигалось, но со страшным скрипом. Гендир там был очень молодой, слегка неотесанный, чресчур самоуверенный и сумасбродный. Он дал мне понять, чтобы я дальше вопросов бухгалтерии нос не совал и не лез к нему со своими советами (дескать, он и сам с усам). Мне было трудно сдержаться, когда я видел, какую хрень там творят, но я таки старался не соваться. Хотя видел, что проблема там в изначально была в отсутствии внятной концепции в решении проблемы унификации НСИ перед сопряжением разнородных продуктов (1С и МойСклад там жксплуатировались несколько лет обособленно друг от друга). Более всего меня удивило, что "специалисты", предоставленные как со стороны 1С-франча, так и со стороны МойСклад, изначально не видели этих проблем и не предупредили руководство, не предложили пути решения. Я вынужден был смотреть скрепя сердце, как проект по интеграции сталкивается с очевидными (для меня) проблемами и как "корабль садится на мель". В итоге там все переругались - гендир заказчика, 1С-франчи и представители МойСклад.

Вскоре мы с этой фирмой расстались (о чем я ни капли не жалею), чем там в итоге все закончилось, точно не знаю.

О программе МойСклад могу сказать, что функционал там основной, есть. Но самый-самый простенький и самый базовый. Тех, у кого есть нюансы, устроить сможет наврядли. Представители МойСклад говорили, что готовы "допилить", но за отдельные весьма существенные деньги. По сути, пытались повесить на заказчика доработку явно сыроватого тогда (5 дет назад) продукта. Есть надежда, что сейчас они его доработали и персонал набрали чуточку пограмотнее...

После интеграции каждой номенклатуры появилось как минимум по две штуки (если не считать, что и в каждом продукте многие из них изначально были задвоены). Хорошо еще прислушались к моему совету поместить номенклатуру из МойСклад в отдельную папку справочника номенклатуры 1С. Также оказались задвоенными и даже затроенными и зачетверенными многие контрагенты. Сначала хотели настроить двустороннее взаимодействие, потом, когда увидели, что информация в одну сторону привязывается к одним экземплярам записей справочников, а в обратную сторону к другим, переругались между собой. Гендир стал гнуть линию как-то это все ПОСТЕПЕННО упорядочить, но на практике делать это никто не хотел, пытались работать так как привыкли прежде, и работали. Все вопросы, связанные с ИТ, он повесил на сетевого сисадмина, у которого не было опыта решения подобных задач, что такое репликация и конфликты репликации, я ему в кулуарах пытался объяснить. Гендир взял на себя функции руководителя проекта при том, что подобными проектами тоже никогда прежде не занимался, и даже слов таких как "репликация" или "нормализация данных" никогда прежде не слышал. Сисадмин, кстати, парень толковый и как человек нормальный. То, что удалось еще как-то по-человечески сделать, это реализовать некоторые мои предложения через сисадмина так, чтобы гендир не знал, что они исходят от меня. Сисадмин со своей стороны пытался объяснить гендиру, что это не совсем его сфера, но гендир уперся. Гендир вообще изначально смотрел на проект интеграции НЕ как на проект, а как на техническую операцию. Дескать, нужно только в настройках в правильную сторону тублеры перещелкнуть, и все сразу на автомате заработает. Когда я пытался оппонировать, говорил, что я всё слишком усложняю. Его вообще очень раздражал мой опыт и знания. Когда он видел человека, который чуточку побольше него разбирается в некоторых вопросах, у него внутри что-то там вскипало, какие-то комплексы, вместо того чтобы внять советам, он делал затыкал рот и "из принципа" делал всё наоборот. В допущенных в кадровой политике ошибках, от которых я пытался его уберечь, он в итоге меня же и обвинил, перевалив с больной головы на здоровую по принципу "я начальник - ты дурак". После того как он исправлял все-таки ошибки после того как терял существенные деньги, выполняя-таки ранее озвученные мною рекомендации, приписывал это в свои личные достижения. А поскольку в глубине души понимал, кто на самом деле виноват в его просчетах, и понимал, что я это понимаю, я его постоянно раздражал. В общем, в конечном итоге, нам пришлось расстаться. Но это всё лирика...

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

Дополнительные сложности создавала большая куча юрлиц на упрощенке, на которые был раздроблен бизнес, чтобы вписаться в требования по применению УСН. Товар же на складе был "в одной куче", а вот в учете нужно было генерить еще и дополнительные документы по перемещению товара от одного юрлица другому. Когда заказчик то и дело просил что-то исправить, в особенности, задним числом, это вызывало снежный ком проблем.

Очень просто. Один добавил наименование "Отвертка крестовая длина 120мм PH2", другой начал искать по первым символам наименования "Крестовая..." - не нашел, и добавил еще одну позицию с другим кодом номенклатуры "Крестовая отвертка L120/PH2". Как результат в справочнике номенклатуры появляется две одинаковые номенклатуры, наименование которых скомпоновано немного по-разному. Для того, чтобы этого не происходило, необходимо составить регламент правильного формирования наименований и передать его пользователям. В нем, в частности, прописать правила, что сначала должно следовать существительное "отвертка", характеризующее центральную суть позиции. Затем прилагательные, характеризующие данный предмет, выделяющие его из класса подобных предметов в более узкий подкласс - "крестовая", затем числовые и иные параметры, еще более сужающие подкласс: "L120" и "PH2". Также следует указать, чем они разделяются - пробелом, запятой, дробной чертой или еще чем. Далее нужно провести обучение пользователей, в процессе которого нужно продемонстрировать примеры правильного и непаравльного формирования наименования. А также правила поиска. Если позиция не находится по началу наименования, нужно поискать по включению в любую часть наименования, желательно несколькими способами. И только гарантировано убедившись в том, что аналогичной позиции нет, добавлять ее. Нужно регулярно вычищать справочник от неправильно введенных или задублированных наименований с перепривязкой информации. Нужно регулярно "давать по рукам" тем, кто не соблюдает регламент, для этого фиксировать, кем было добавлено кривое наименование. Нужно раздать права правильно, чтобы добавлять новые позиции в справочник или корректировать ранее введенные могли только те, кому это положено по характеру их деятельности, а не всем кому ни попадя...

Дополню. Это должно быть сделано не только для справочника номенклатуры - для вообще всех справочников. В частности, и для справочника контрагентов. Чтобы в нем не появлялись дубликаты в стиле "ООО Рога и Копыта", "Общество с ограниченной ответственностью Рога и Копыта" и "Рога и Копыта ООО"

Хорошо бы, да только в разных приложениях (1С:Бухгалтерия и МойСклад) разный функционал для реализации подобных вещей.

Кстати, в проекте интеграции приложений задвоение позиций справочников при их синхронизации - это не самая большая проблема. По крайней мере, такая проблема хотя бы потенциально устраняема скрупулезным и скаредным выявлением фактических задвоев и исправлением ссылок в одном из синхронизируемых приложений с удалением лишней позиции. Гораздо более существенная проблема в связях между справочниками один-ко-многим, многие-к-одному, а самую большую проблему создает многие-ко-многим. Приведу пример, чтобы было ясно, о чем речь. Например, в 1С все крестовые отвертки длины 120 мм и головкой PH2 - это одна позиция. А в МойСклад их 20 разных, потому что учитывается еще и производитель, материал и цвет ручки, и еще что-нибудь. И как из 1С данные, привязанные к одной позиции, передавать в МойСклад в привязке к 20 разным позициям? Никак. Потому что критерии рассортировки по 20 позициям утеряны в источнике, из которого происходит репликация. В этом случае, по крайней мере, возможна репликация со стороны "многие" в сторону "один", если в механизмах репликации прописаны четкие критерии, по которым 20 позиций в одном приложении могут преобразовываться в одну в другом.
Но когда в МойСклад 20 отверток, расклассифицированных по одним критериям, а в 1С 30 отверток, расклассифицированных совершенно по другим критериям, возникает связка "многие-ко-многим", в которой трансформация одной системы классификации в другую в принципе невозможна. И в этом случае корректная репликация невозможна ни в какую сторону.
Прежде чем запускать репликацию как таковую, необходимо проанализировать НСИ в разных системах на предмет подобных потенциальных проблем. И сначала наметить меры, по большей части ОРГАНИЗАЦИОННЫЕ , для приведения систем классификации в разных приложениях в унифицированный вид. Проблемы связей многие-ко-многии должны быть разрешены ДО ЗАПУСКА РЕПЛИКАЦИИ, а не после. После их разрешить, как правило, невозможно. Постремонт возникших проблем возможен скрупулезным ковырянием задвоений при связях один-к-одному.
К сожалению, некоторые руководители предпочитают не решать проблемы до того, пока с ними де-факто не столкнутся. А когда столкнутся, выясняется, что проблемы оказались трудно разрешимыми, либо неразрешимыми вовсе.