Апофеоз интеграций - конструктор Лего. Деталь с «пупочкой» гарантированно сочленяется с «дырочкой» другой детали. Думаю, что я в числе тех родителей, которые однажды ссыпали все, ранее купленные наборы Лего, в одну корзинку, а потом с испуганным восторгом смотрели на невообразимые «фракталы», слепленные усердными и увлечёнными детишками, которые пустили в ход абсолютно всю номенклатуру, подобранную из «свалки» Лего. Абсолютная цель такой «интеграции» может быть выражена простой формулой - «каждая пупочка должна найти свою дырочку». При любой форме результата детского творчества это повод для радости, ибо всё, чего коснулись детские руки всегда будет вызывать приступ невероятной милоты и родительской гордости.
А потом детки выросли.... Небольшая проблема в том, что некоторые «выросшие» умудрились записаться в программисты. А навыки «интеграций» сохранили со времён детской комнаты с большой коробкой (ящиком, ведром) запчастей Лего. В чём это выражается? Примерно в этом лозунге "Если две программы (базы данных, конфигурации) можно соединить для обмена чем угодно, надо обязательно их соединить!". Безотносительно, имеет смысл такое сочленение или это противоречит методологии, логике, нормативной базе и прочее.
Не буду касаться интеграций учётной системы с внешними ИТ-миром. Тут у каждого свои вводные, условия и пожелания. Надо, так надо - приходится интегрироваться. Меня забавляют некие "интеграции" внутри самой учётной системы. Об этом сегменте мой текст.
Почти "типовая" комбинация программных средств, приобретённых хозяйствующим субъектом, в вакансиях описание «будущей работы» зачастую выглядит именно так. Пресловутое "ЕРП" и "БП". И между ними невообразимая «паутина" обменов и интеграций. Каждая "ниточка" вплеталась в эту общую ткань паутины по отдельной заявке какого-то очень ответственного менеджера, продажника, снабженца или бухгалтера. Обслуживание каждой такой ниточки становится отдельной задачей для программиста и аналитика. Собственно, наша профессиональная жизнь этим и заполнена в большинстве своём. И мы так заморочились в этой непрерывной суете, что некогда подумать - а такая конструкция родилась по результатам - чего? Напомню, в том же ЕРП (УХ) есть абсолютно дееспособная подсистема „регламентированный учёт“. Кто-то может внятно и убедительно рассказать - зачем из одной конфигурации, имеющей всё необходимое, надо что-то „выгрузить“ в абсолютно идентичную программу регламентированного учёта?
Я встречался с такими объяснениями: «В ЕРП (УХ, КА) ведётся учет продаж (производства), а в бухгалтерии надо готовить отчёты в ФНС». Если не задавать следующего вопроса «А кто такую конструкцию придумал?», то можно согласно махнуть гривой и произнести «Угу, ясненько-понятненько!». Я - вредный, я такой вопрос в стиле «А кто автор чертежей?» задаю всегда. Ответа не слышал ни разу, поэтому попытался искать сам.
Первый шаг на пути поиска ответов очень несложный и универсальный для всех видов деятельности - поиск аналогов. Чего проще - посмотреть вокруг и попытаться увидеть, делает ли кто-то ещё так, как предлагается делать мне. Сразу оговорюсь, под термином «где-то ещё» я подразумеваю другие территории в других юрисдикциях. Я не Бог весть какой знаток зарубежного ПО, выбор у меня совершенно неширокий. Я взял для сравнения известное очень многим ПО, по которому есть достаточно информации и есть опыт эксплуатации даже на нашей территории. Это САП.
Один из постулатов, безусловно поддерживающихся в этой учётной системе, можно озвучить примерно так «Один факт хозяйственной жизни (ФХЖ) порождает только один первичный документ. Данный документ вносится в учётную систему только один раз во всей полноте всех своих реквизитов». Допустим, (речь идёт о САП) в подсистеме учёта материальных запасов произведён приход материалов (сырья, товаров). Сотрудник, производящий регистрацию этого ФХЖ в своём складском интерфейсе никак не заботится о какой-либо дополнительной «интеграции». Сама подсистема складского учёта найдёт требуемую подсистему ведения взаиморасчётов и сделает в ней соответствующие записи об изменившемся состоянии взаиморасчётов с поставщиком. Назвать это «интеграцией» у меня язык не поворачивается. Используя классический метод «рассуждения от противного», сразу возникает однозначный вывод - «А иначе просто невозможно, нелогично и несуразно».
По моему представлению именно неудачное проектное решение впоследствии востребует огромного количество "верёвочных лестниц", хаотично соединяющих отдельно стоящие "острова" учёта. В очень многих случаях (в большинстве?) получается так себе.
Наглядный пример - документы Счетов-Фактур. Как я видел бы разумный вид организации учёта для любого плательщика НДС, исходя из своих представлений и полученных ранее знаний? А примерно так. Если организация является плательщиком НДС, то внутри такой учётной системы, независимо от количества используемых интерфейсов (конфигураций), должна существовать только одна подсистема (НДС), собирающая все данные, необходимые для ведения книги покупок и продаж. Как, увы, происходит зачастую "интеграция", посвящённая формированию документа СФ? В какой-то программе, посвящённой продажам (УТ), выдаётся счёт-фактура. При этом будет использован нумератор конфигурации УТ. Затем "слепок" этого документа надо внедрить в ту программу (БП?), где будет впоследствии формироваться декларация по НДС. Где-то настраивают типовые обмены между конфигурациями, где-то энтузиасты КД пишут свои инструментарии обменов, есть вообще авторские эксклюзивы. Сути это не меняет. Есть достаточно несуразное решение, которое сначала делает вивисекцию единого тела учёта, с последующим "сшиванием" получившихся фрагментов нитями всяких "интеграций". Эти интеграции получаются очень громоздкими, нелогичными и нуждающимися в постоянном надзоре. Почему так получается? Потому, что очень немногие воспринимают учёт, как нечто, изначально целое и замкнутое. Каждый раз решается локальная задача в стиле "Продажники должны выдавать эСэФ-ки! Надо их связать с бухгалтерией!" А продажники работают в УТ! Почему? А им так удобно. Привыкли... Бизнес-процессы, пАнимаЭшь!
Простейшая вводная регулярно "взбадривает" такие примитивные подходы в интеграциях. Кого-то сильно удивит, но есть и иные обстоятельства, требующие формирования документа СФ, кроме отделов продаж. Условный "начальник транспортного цеха" навёл порядок в гаражах и сдал 50 тонн металлолома в пункт приёма. Аналогичные действия сделал старший кладовщик, сдавший пару тонн старого картона в макулатуру. При таких операциях приходится формировать документ СФ, да ещё с особым порядком учёта. Затем начальник АХО сдал в аренду пару невостребованных складов и получил оплату сразу за весь год. И тоже сформировал свой документ СФ. Попутно организация оказала транспортные услуги соседней организации и по оказанным услугам тоже документ СФ надо формировать. А потом ещё пришли письма с претензиями от покупателей и потребовались формирования уже корректировочных Счетов-Фактур. Можно ещё навыдумывать примеров, но я пишу о том, что точно на виду и касалось очень многих. В такой конструкции учёта постоянным фоном стоит гул негодований бухгалтеров на корявое заполнение Книги продаж со скачущей нумерацией, необходимостью "резервировать номера СФ" для каких-то уникальных операций и т.д. И это ещё самые безобидные недостатки. Ой, сколько же "интеграций" в самых разных местах надо делать, да? А точно надо? Может, будет более лучшим решением «в консерватории подправить"? Что я имею ввиду? Примерно вот это.
На примере НДС (счетов-фактур). Если уж наличие целой гаммы конфигураций 1С, которые так уж необходимо использовать одновременно, так нравится в организации и другого выхода не предвидится, то счёл бы более суразным вот такой подход. Надо определить «главную конфигурацию подсистемы НДС" в том наборе конфигураций, которая сложилась в практике организации. Какую из веера конфигураций надо считать главной? Однозначный ответ - та, из которой формируется декларация, подаваемая в ФНС. И это без вариантов. Вся суть всех остальных "интеграций" с прочими конфигурациями сводится к процессу обращения к администрирующей (главной) подсистеме НДС (HTTP-сервис). Условно, уже не УТ будет напрямую формировать счет-фактуру через свой нумератор. УТ должна обратиться к администрирующей подсистеме, инициировать именно там создание требуемого документа, провести его именно там, где существует весь контекст учёта НДС (это принципиально важно!). И только потом получить уже в свою конфигурацию цифровой слепок вновь созданного документа. При таком подходе будет уверенность в том, что все выписанные счета фактуры учтены, логично пронумерованы, независимо от тех интерфейсов, в которых эти документы инициировались.
Конечно, это не САП, где грамотно проведённое проектирование при разработке программы сразу подразумевает разнесение учёта на подсистемы. Но это хотя бы слабое подобие того постулата, который я упоминал в начале текста, что «один документ вводится один раз и только в одном месте... бла-бла-бла...». А то, что мы зачастую мучительно «рожаем» под названием "интеграции", в САП является просто неотъемлемой частью проектного решения. Наверное, если бы мы тоже получше думали над учётными конструкциями, у нас тоже меньше было бы «интеграций».
Может быть хорошая квалификация в части интеграций как раз в том и состоит, чтобы, внимательно посмотрев на предложенную задачу, не быстро делать что-то "мощное и интеграционное", а спокойно объяснить, что вообще не должно быть такой «интеграции».