Да свържете SAP, без да го пипате: как да интегрирате магазина, банката и партньорите си, без да оставяте разработки, които пречат

За 1 минута

Свързването на нещо със SAP изисква две решения: през какъв механизъм се влиза и къде живее логиката на всеки канал. Прекият път — собствена програма, вързана за вътрешностите на SAP — изглежда по-бърз и се плаща при следващото обновяване. SAP го казва със свои думи: това, което стъпва на публикуваните му интерфейси, най-добре издържа на обновяване. Тази статия обяснява на езика на един управителен съвет кои врати има, кога е уместна всяка от тях и какво да попитате, преди да одобрите следващата интеграция.

Представете си средно голяма компания, която води счетоводството, складовите наличности и фактурирането си в SAP. Тя е измислена, но прилича на много други. Един ден до ИТ екипа почти едновременно стигат три искания:

• Търговският отдел иска онлайн магазинът да изпраща всяка поръчка в SAP и да проверява цената и наличността.
• Финансовият отдел иска банковото извлечение да се равнява с вземанията, които SAP води.
• Продажбите искат партньор дистрибутор да може да изпраща поръчките си от собствената си система.

И трите искания са разумни. И трите крият един и същ въпрос: къде ще живее връзката?

Бързият отговор обикновено е „в SAP, както може“: програма по поръчка, която чете файла на банката, нова таблица за поръчките на магазина, промяна в стандартен процес заради партньора. Работи и работи бързо. Цената не се появява в деня на предаването. Появява се в деня, в който SAP трябва да се обнови и някой открие, че всяка от тези разработки трябва да се прегледа, да се тества и понякога да се направи наново.

Тази статия е за онези, които ръководят ИТ, финансите или операциите в компания, която работи със SAP и трябва да свърже с него още неща; разсъждението важи и за други ERP системи на производители. Тя защитава една идея: връзката минава през вратите, които производителят поддържа, а това, което принадлежи на всеки канал, по правило живее извън ERP системата. Това не е само архитектурно предпочитание: SAP препоръчва да се отдели добавеното и да се стъпва на публикуваните му интерфейси, за да се намали техническият дълг и да се улеснят обновяванията [1][2].

Това не е статия за това дали връзката трябва да е онлайн, или асинхронна; за това е Онлайн или асинхронно?. Тук въпросът е друг: през коя врата се влиза в SAP и какво остава отвън.

Цената се плаща при следващото обновяване

SAP повтаря това на клиентите си от години и има име за него: чисто ядро (clean core). Идеята е да се отдели това, което всяка компания добавя, от това, което доставя SAP, така че обновяването да не чупи добавеното и добавеното да не чупи обновяването. Една публична презентация на консултанти на SAP го обобщава така: собствените разширения не бива да чупят обновяването, нито обновяванията — разширението, а за целта те се отделят чрез публикуваните интерфейси на SAP; и разширенията е добре да се избягват, когато е възможно (свободен превод) [2].

Обучителните материали на SAP са още по-ясни за стария път. Те описват традиционния начин за програмиране вътре в SAP като код, „тясно свързан със системата“, който „можеше да създаде проблеми при обновяване“ и затова се препоръчваше „като последна мярка“ (свободен превод) [1]. Днес за SAP S/4HANA SAP класифицира разширенията в четири нива, от A до D: ниво A използва публикувани интерфейси и точки за разширение и дава най-голяма стабилност при обновяване, независимо дали е извън SAP, или вътре в него с инструментите, които SAP допуска; а едно разширение се оценява по технологията от най-ниското ниво, която използва [1].

На езика на управителния съвет: всяка разработка, вързана за вътрешностите на SAP, е дълг, който се плаща с лихви при обновяванията. Не всички могат да се избегнат. Но всяка трябва да има записана причина. И дори когато всичко е наред, всяко обновяване се тества: променя се колко има за преглеждане.

Вратите, които SAP вече има

SAP не е затворен. Той има няколко механизма за интеграция — тук ги наричаме врати — и всеки служи за нещо различно. Управителният съвет не е нужно да знае как работят отвътре; полезно е да знае, че съществуват, и да попита през коя ще се влезе. Кои са налични и за какви операции зависи от продукта и версията на SAP, които използвате.

И една врата, която не е в списъка: директното записване в таблиците на SAP. Тя е изкушаваща, защото изглежда най-кратката, и пречи, защото може да заобиколи контролите, с които бизнес процесът на SAP пази собствената си информация.

Техническата страница на Hábil MDW го казва с едно изречение: при ERP системите даваме предимство на интерфейсите, които производителят поддържа — в SAP например JCo, OData, IDoc или REST —, за да не ви оставим разработки, които пречат при обновяването му.

Какво остава в SAP и какво остава отвън

Да влезете през правилната врата е половината от работата. Другата половина е да решите коя логика живее в SAP и коя — отвън. Едно полезно правило:

• В SAP остава това, което SAP прави добре, и това, което законът или одитът изискват от SAP: счетоводството, официалната наличност, фактурирането, клиентът и артикулът, както ги познава ERP системата.
• Отвън остава това, което принадлежи на всеки канал или на всеки партньор: файловият формат на всяка банка, правилата на онлайн магазина, преводът на това, което изпраща всеки дистрибутор, повторните опити, следата за това какво е изпратено и какво е отговорил SAP.

Тези повторни опити и тази следа са и онова, което удържа продажбата в деня, в който ERP системата не отговаря; за това е ERP системата падна в събота.

SAP има име за втората част: разширения едно до друго (side-by-side), които работят извън ERP системата и се свързват с нея [2]. Това не е единственият чист начин — SAP допуска и разширения вътре в ERP системата, когато случаят изисква такава обвързаност и те са изградени с публикуваните му инструменти [1] —, но за това, което принадлежи на всеки канал, обикновено е най-подходящият. Ползата за бизнеса е двойна. Вътре в ERP системата остава по-малко собствен код, така че при всяко обновяване има по-малко за преглеждане. И нов канал променя най-вече външния слой; в SAP — най- много основни данни или настройка.

Трите искания, решени през правилната врата

Да се върнем към измислената компания.

Онлайн магазинът. Всяка поръчка влиза в SAP през публикуван интерфейс, с уникален референтен номер, който се проверява, преди тя да се запише, за да не я дублира повторен опит: това не идва с интерфейса, а се проектира. Цената и наличността се проверяват по същия път, ако версията на SAP го предлага; ако магазинът ги проверява много пъти в минута, добре е външният слой да пази копие, с договорена честота на опресняване, за да не натоварва SAP с всяко посещение. Логиката на количката, отстъпките и известията към клиента остават в магазина или във външния слой, не в SAP.

Банката. Банката изпраща извлечението си като файл, в своя формат. Външният слой го взема, проверява го, превежда го и го равнява с вземанията в SAP. В SAP стига само това, което трябва да се запише, през официалната му врата. Ако утре се добави втора банка с друг формат, учи се външният слой; в SAP най-много се създава сметката.

Партньорът дистрибутор. Партньорът влиза през врата със собствена идентичност и собствени права, изпраща поръчките си в своя формат, а външният слой ги превежда в поръчката, която SAP познава. Ако партньорът смени системата си, се коригира преводът; SAP остава същият.

И в трите случая SAP прави онова, което прави най-добре. Когато дойде време за обновяване, трите връзки се тестват, но няма три собствени разработки, скрити вътре, които да се преглеждат една по една.

Когато нужната врата не съществува

Понякога няма публикуван интерфейс за това, което е нужно, особено в по-стари версии на SAP. Това не задължава да се влезе в SAP веднага. Самият SAP публикува ръководство за този случай: класическа функция — примерът му е BAPI, която създава заявки за покупка — се обвива в собствен интерфейс, малък и документиран, който се публикува, за да го използва новата разработка; функцията отдолу остава класическа и SAP я класифицира на ниво B [1][6]. Същата група уроци след това показва как тази обвивка се заменя с публикувания интерфейс, който SAP е пуснал за този процес [6]. Често задаваните въпроси на SAP добавят полезно предупреждение: събирането на много класически функции в една обвивка пречи тя да бъде премахната по-късно, когато SAP публикува интерфейса на някоя от тях, и смесва отговорностите (свободен превод) [7].

На езика на управителния съвет: ако трябва да се влезе през врата, която не е от първо ниво, това се прави съзнателно, на едно място, с име и отговорник, като при всяка версия се проверява дали SAP вече предлага публикувана алтернатива.

Рисковете, на езика на бизнеса

Пет въпроса за следващия ви управителен съвет

1. Колко собствени разработки има компанията ви вътре в SAP, за да свързва други системи, и кой ги познава? Ако никой не може да отговори със списък, това е първата находка.
2. При последното обновяване на SAP колко от тези разработки трябваше да се прегледат или да се направят наново и колко време отне това?
3. За следващата интеграция, която ще се одобрява, през коя врата на SAP ще влезе? Поискайте да бъде казано писмено: публикуван интерфейс, отдалечена функция, документ за обмен или файл — и кой процес на SAP го приема —, и защо.
4. Пише ли нещо директно в таблиците на SAP? Ако отговорът е „мисля, че не“, струва си да се провери.
5. Ако утре се добави нова банка или нов партньор, какво трябва да се промени в SAP? Основни данни или настройка са нормални. Ако отговорът е „нова програма“, логиката на всеки канал вероятно живее на грешното място.

Ако няколко отговора са „не знам“, приемете го като знак да направите инвентаризацията, преди да одобрите следващата интеграция.

Откъде да започнете тази седмица

Направете инвентаризация на връзките на SAP. Една таблица, по един ред за всяка връзка, с пет колони:

• Каква система се свързва: магазин, банка, партньор, друго?
• През коя врата влиза: публикуван интерфейс, отдалечена функция, документ за обмен, файл или директно в таблиците?
• Логиката на този канал живее ли вътре в SAP, или отвън?
• Кой я поддържа и документирана ли е?
• Счупи ли се, или трябваше ли да се преглежда, при последното обновяване?

Таблицата, която се получи, показва с факти кои връзки зависят от собствен код вътре в SAP и помага да се реши откъде е добре да започне изнасянето на логика. Работи с всеки инструмент или без никакъв.

Какво прави Hábil

В Hábil изграждаме по поръчка интеграцията между SAP — или ERP системата, която използвате — и това, което е около нея: магазина, банките, партньорите и каналите. Правим го, като влизаме през вратите, които производителят поддържа, и оставяме отвън това, което принадлежи на всеки канал.

Ако инвентаризацията ви покаже връзки, които зависят от собствени разработки вътре в SAP, предложението е Hábil MDW. Той се свързва с ERP системата ви и с каналите ви по пътищата, които всеки от тях вече има, превежда всичко, което пристига, на един общ език и оставя запис какво се е случило, кога и кой го е направил. При ERP системите даваме предимство на интерфейсите, които производителят поддържа, за да не ви оставим разработки, които пречат при обновяването му. Банки, магазини, агенти и дистрибутори се свързват със собствена идентичност и собствени права. Обхватът, използваните врати и редът, в който се изнася логика от SAP, се преглеждат спрямо вашия случай.

Разговорът може да започне с вашата инвентаризация, дори и наполовина готова: какво се свързва, през коя врата влиза и какво се е счупило при последното обновяване. С това заедно ще прегледаме откъде е добре да започнем. Пишете ни в WhatsApp; за да защитите информацията си, не споделяйте по този канал данни за системите или за клиентите си: в разговора ще се договорим за канала за конкретния случай.

Поискайте първия си разговор, безплатно.

Проверени на 12 ноември 2026 г. Всеки източник носи степента си на доверие: висока (прочетен първичен източник).