Смаколики SAP S/4HANA. Бізнес партнери

Загальні дані

Це була одна з болючих тем – чому в SAP постачальник та клієнт не може бути одним об’єктом? В деяких компаніях одна і та ж особа, компанія мала різний номер як клієнт та як постачальник, і дані по цій особі, компанії необхідно було вести в різних транзакціях дублюючи загальну інформацію у таких записах. На відміну від SAP ERP, де ведення бізнес партнерів було за бажанням, в SAP S/4HANA це стало обов’язковим. Бізнес партнер це:

Але спочатку дуже хочеться поговорити на тему «кредитор» – «дебітор». Це ще одна болюча тема, яка опосередковано пов’язана з темою бізнес партнера, але несе в собі більш бухгалтерський ракурс.

Так от. Приходиш в компанію на проект, починаєш розмову про постачальників та клієнтів, які в україномовному та російськомовному варіанті SAP названі як «кредитор» (постачальник) та «дебітор» (клієнт, покупець). І зразу – негатив та нерозуміння. З одного боку, згодна, це недолугий переклад. Коли з перекладом порозумілись, вимальовується інший бік – принципове інше розуміння українських бухгалтерів поняття кредиторська та дебіторська заборгованість. В поняттях українського бухгалтера це заборгованість по кредиту (кредиторська) і заборгованість по дебету (дебіторська). В поняттях SAP – це заборгованість кредитора (постачальника) та дебітора (клієнта). І це дві великі різниці. Тому що, наприклад, аванс, сплачений постачальнику в поняттях українського бухгалтера це дебіторська заборгованість, в поняттях SAP – це … аванс виданий постачальнику і є майбутнім, зменшенням кредиторської заборгованості. Щодо обліку по рахунках та відображенням цих операцій в балансі, тут проблем немає – все відображається там де треба. Це питання лише порозуміння та різниці в термінології.  

В SAP ERP останніх версій ви вже могли користуватись цим функціоналом, але з версії SAP S/4HANA це стало обов’язковим. В SAP ERP для кожного контрагента, якщо він є і постачальником і покупцем, ви створюєте основний запис в окремих транзакціях. Для клієнтів – FD01, FD02, FD03, або загальне ведення клієнтів/дебіторів, транзакції XD01, XD02, XD03. Для постачальників – FK01, FK02, FK03, або загальне ведення постачальників/кредиторів XK01, XK02, XK03. Якщо у системі використовувалась внутрішня нумерація, то звісно номера контрагентів не співпадали. Далі, якщо контрагент одночасно створений як клієнт так і як постачальник, то в основних записах необхідно було робити посилання одне на одного (клієнта на постачальника), щоб потім в звітах побачити загальну картину по контрагенту. В основних даних для клієнта (також і для постачальника) необхідно прописати контрольний рахунок. А якщо цей контрагент виступає ще і в інших ролях, то про це в системі ніяк не можна вказати, наприклад контрагента необхідно також використовувати як фізичну особу.

У SAP S/4HANA бізнес-партнер є провідним об’єктом і єдиною точкою входу для підтримки основних даних клієнтів і постачальників. Бізнес партнер або діловий партнер – це партнер, з яким ваша компанія має ділові відносини. Ці відносини  можуть бути набагато ширшими ніж просто купівля – продаж. Мати інформацію по всім взаємовідносинам дуже важливо. 

• Бізнес-партнер це об’єкті який веде найменування, адреси, правові та юридичні аспекти, необхідні дані для платіжних операцій. Це все що належить цій особі та не залежить від операцій та діяльності які будуть з нею виконуватись. Це робить непотрібним створювати загальні дані для кожної ролі бізнес-партнера, оскільки базова або загальна інформація, яка підтримується для бізнес-партнера, автоматично поширюється на інші ролі бізнес-партнера в SAP S/4HANA.

• Бізнес-партнер дозволяє підтримувати кілька адрес із відповідним використанням адрес.

• На рівні основних даних партнера реалізована часова залежність для різних ролей суб’єктів, адреси, відносин, банківських даних тощо. Тепер зміна цих даних не вплине на аналіз минулих операцій, бо вступає в дію з певної дати.
• Не менш важливою є інформація про зв’язки між діловими партнерами. Наприклад, материнська та дочірні компанії, головна компанія та філіали. Цю інформацію можна вести в основних даних бізнес партнера і таким чином отримати повне досьє на контрагента. 
• Можна налаштувати так, щоб номер бізнес-партнера («шапка») = номер цього ж партнера в ролі постачальника = номер цього ж партнера в ролі клієнта. Зазвичай це так и роблять, тому що фізично такі об’єкти системи як дебітор та кредитор нікуди не поділись, але тепер ці об’єкти управляються та ведуться централізовано як залежні об’єкти, причому попередні транзакції ведення типу XD01, XD02  та інші вважаються застарілими, та за замовчуванням вони заблоковані у системі S/4.
• Загальні дані доступні для всіх ролей бізнес-партнерів, окремі дані зберігаються для кожної ролі.
• Якщо у вас використовується функціональність SAP CRM, то в ERP ви вели партнерів окремо, а в CRM ви вели їх як бізнес-партнерів. Тепер при переході на S/4HANA необхідно усунути такі дубляювання сутностей – бізнес-партнер це одна сутність тепер і для SAP S/4HANA і для CRM.
• Всі операції з ведення даних бізнес-партнера виконуються з одного екрана – в одній транзакції ведення бізнес партнерів.

Зв’язок між бізнес партнером та кредиторами і дебіторами у системі

Як було описано вище дебітори і кредитори нікуди не зникли, але їх ведення було перенесено на рівень за який відповідає тепер інтерфейс CVI – (C)ustomer (V)endor (I)ntegration. Цей інтерфейс автоматично переносить всі необхідні дані з бізнес партнера на рівень дебітора або кредитора. 

• Один контрагент може бути:
  • кредитором – в ракурсі для Балансової одиниці вказуємо контрольний рахунок для обліку операцій з ним
  • постачальником – в ракурсі закупівель вказуємо закупівельну організацію та керуючі дані для закупівель і тепер можна виконувати операції закупівлі у нього в модулі ММ

• дебітором – в ракурсі для Балансової одиниці вказуємо контрольний рахунок для обліку операцій з ним
  • клієнтом – в ракурсі збуту вказуємо збутову організацію та керуючі дані для продажів і тепер можна виконувати операції збуту для нього в модулі SD

Примітка: Нажаль вказати декілька різних ролей постачальника з різними контрольними рахунками для бізнес партнера, не можливо, тому що для головного запису бізнес партнера, можуть бути створені лише по одному пов’язаному запису кредитора та дебітора і відповідно можна вказати по одному контрольному рахунку. А якщо цей партнер виступає, наприклад, ще й в ролі орендодавця і нам необхідно відображати операції з цим партнером в модулі Управління нерухомістю на окремих рахунках, то ми додаємо цю роль для партнера, і вже згідно з цією роллю налаштовуються рахунки. Заради справедливості, треба сказати, що в більшості випадків це виключення, а ніж правило.

Технічні особливості реалізації

Більшість транзакцій по веденню дебіторів і кредиторів була вилучена із системи або заблокована. Але деякі транзакції залишились, наприклад транзакції масового ведення кредиторів і дебіторів. Їх використання необхідно лімітувати, тому що воно може призвести до розсинхронізації загальних даних з бізнес партнерами, наприклад, ви можете змінити найменування кредитора після чого деякі звіти почнуть показувати змінене найменування з даних кредитора, а деякі найменування з основних даних пов’язаного бізнес партнера. Тому без особливої необхідності не використовуйте прямі транзакції ведення кредиторів і дебіторів, що залишились у системі.

Хто виграє від цих змін?

• Відповідальні за ведення довідників контрагентів? Так, звичайно – одна транзакція ведення, немає необхідності дублювати загальні дані, всі дані розкладені по поличкам, легкий пошук для уникнення введення дублів
• Бухгалтери? Так, звичайно – один номер партнера для всіх ролей, часозалежні дані, які дозволяють вибирати дані з відповідною на той час загальною інформацією
• Фінансисти? Так, звичайно – нарешті в системі ведуться ознаки пов’язаних компаній, їх ієрархічна підлеглість, дані про філіали та головну компанію, частки в капіталі та інша важлива для фінансистів інформація
• Відповідальні за продажі та закупівлю? Так, звичайно – в системі доступна єдина інформація про всю історію взаємовідносин, контакти та важлива персональна інформація
• Відповідальні за комплаєнс та безпеку? Так, звичайно – можна вести відповідні дані з державних реєстрів (або налаштувати оновлення бізнес партнерів цими даними), щоб завжди мати актуальну інформацію та убезпечити свою компанію від небажаних контрактів
• Внутрішній аудит? Так, звичайно – однозначне визначення контрагента в системі для аналізу всіх операцій з ним