Договір приєднання до онлайн-платформи INBULK.COM — Єгипет

Локалізована редакція Договору приєднання INBULK.COM — Арабська Республіка Єгипет

INBULK.COM LLC, реєстраційний код компанії 46091188, створена та діюча за законодавством України, в особі директора Олександра Романіва, який діє на підставі Статуту та на законній підставі здійснює операційне управління онлайн-платформою INBULK.COM (далі — «Оператор Платформи»), з однієї сторони, та юридична особа, підприємець або інший суб’єкт господарювання, який діє виключно у зв’язку зі своєю господарською чи професійною діяльністю, не діє як споживач і прийняв цей Договір та приєднався до нього (далі — «Користувач-компанія»), з іншої сторони, разом — «Сторони», регулюються цим Рамковим договором про користування Платформою та приєднання (далі — «Договір»). Платформа призначена виключно для B2B-використання. Ця локалізована редакція застосовується до відносин між Оператором Платформи та Користувачами-компаніями в Арабській Республіці Єгипет.

1. Загальні положення, рамкові умови та приєднання

1.1. Цей Договір установлює стандартні рамкові B2B-умови доступу до Платформи та користування нею, електронної взаємодії Користувачів, створення й Акцепту Ордерів, укладення та виконання Угод / Business, формування та підписання Контрактів, формування Замовлень і використання інших фактично доступних сервісів. Вислів «Приєднання» описує договірний механізм, яким Користувач-компанія приймає цю заздалегідь установлену рамкову редакцію; сам по собі він не є визнанням того, що Договір є «договором приєднання» у спеціальному значенні статті 100 Цивільного кодексу Єгипту.

1.2. Користувач-компанія приймає цей Договір і приєднується до нього шляхом підписання Заяви про приєднання та прийняття, наведеної в Додатку 1, належно уповноваженим Підписантом. Користувач-компанія не зобов’язаний зустрічно підписувати повний текст цього рамкового Договору. Додаток 1 прямо ідентифікує редакцію Договору та контрольний ідентифікатор або хеш і є невід’ємною частиною договірного пакета. До Підписання Користувач-компанія має реальну можливість ознайомитися з повним текстом Договору та договірними документами, прямо включеними шляхом посилання, зберегти й відтворити їх. Для єгипетської Користувача-компанії Заява про приєднання та прийняття підписується Підписантом за допомогою цифрового підпису, що відповідає Закону Єгипту № 15 від 2004 року про електронний підпис, Виконавчому регламенту до нього та застосовним вимогам ITIDA, або — якщо Оператор Платформи прямо дозволяє альтернативний сценарій підписання і такий спосіб є юридично достатнім — власноручним підписом, підкріпленим посиленою перевіркою особи та корпоративних повноважень. Одноразовий код (OTP), позначка в полі, дія «клік для прийняття» чи інша подія автентифікації не можуть описуватися як єгипетський цифровий підпис, якщо вони фактично не відповідають застосовним юридичним і технічним вимогам.

1.3. Договір вважається укладеним у момент, коли належно підписана Заява про приєднання та прийняття отримана Оператором Платформи через погоджений електронний або документарний канал, стає доступною Оператору Платформи та фіксується як пов’язана з ідентифікованою рамковою редакцією Договору. Це договірне правило отримання має відображати загальне правило для договорів між відсутніми сторонами за статтею 97 Цивільного кодексу Єгипту з урахуванням будь-якої імперативної норми, застосовної до конкретного сценарію. Платформа фіксує Користувача-компанію, Підписанта, редакцію Договору, Підписну версію, дату й час, спосіб підписання, результат перевірки та доступні дані сертифіката чи провайдера. Після укладення Платформа надає Користувачу-компанії договірний пакет і підтвердження приєднання у формі, придатній для зберігання та відтворення. Кожна рамкова редакція цього Договору підписується або в інший спосіб затверджується Оператором Платформи один раз і не потребує повторного зустрічного підписання Оператором Платформи для кожної Користувача-компанії. Кожна рамкова редакція цього Договору підписується Оператором Платформи кваліфікованим електронним підписом (QES / КЕП) відповідно до законодавства України та оприлюднюється чи в інший спосіб робиться доступною на Платформі. Для доказових цілей, подання чи примусового виконання в Єгипті Оператор Платформи може додатково використати власноручний підпис або інший юридично достатній спосіб підписання, якщо це доречно. Український або інший іноземний електронний підпис не може подаватися як єгипетський цифровий підпис, що відповідає вимогам ITIDA, якщо він не визнається або не приймається за застосовним правом Єгипту та вимогами ITIDA.

1.4. До укладення Договору особі може надаватися обмежений доступ для реєстрації, заповнення профілю, завантаження документів, проходження Акредитації чи Верифікації, створення чернеток та ознайомлення з функціоналом. Такий доступ не надає Права на вчинення Юридично значущих дій.

1.5. Приєднання до цього Договору саме по собі не є Ордером, Зустрічним ордером, Угодою / Business, Заявкою на послугу, Замовленням, Номінацією, платіжною інструкцією або дорученням та не надає Оператору Платформи, Агенту чи будь-якій іншій особі повноважень щодо конкретної операції.

1.6. Підписант підтверджує, що має всі необхідні законні, корпоративні та представницькі повноваження для приєднання до Договору, а Користувач-компанія отримав усі необхідні внутрішні рішення й погодження.

1.7. До відповідного Підписання або іншої Юридично значущої дії Договір і будь-який договірний документ чи стандартні умови, які мають бути включені шляхом посилання, чітко ідентифікуються та надаються Користувачу у формі, що дозволяє ознайомитися з ними, зберегти та відтворити їх. Платформа надає розумний технічний засіб виявлення та виправлення помилок введення до остаточного надсилання оферти, Акцепту чи іншої Юридично значущої дії. Оператор Платформи зберігає застосовні редакції та пов’язані записи про акцепт, підписання й системні події так, щоб зміст, послідовність, час, цілісність і результат відповідних дій могли бути достовірно встановлені.

2. Терміни та правила тлумачення

2.1. Для цілей цього Договору терміни вживаються в такому значенні:

• «Оператор Платформи» (Platform Operator) — INBULK.COM LLC, реєстраційний код компанії 46091188, яка на підставі відповідної ліцензії та в межах прав, наданих Правовласником Платформи, здійснює її експлуатацію та адміністрування, визначає правила доступу, керує обліковими записами й забезпечує технічну та організаційну можливість електронної взаємодії Користувачів.

У межах конкретної операції Оператор Платформи може додатково виступати Агентом, організатором послуги, безпосереднім Виконавцем послуги або іншою стороною відповідних правовідносин лише тоді, коли така роль прямо визначена в остаточних умовах такої операції.

• «Платформа» / «Платформа INBULK.COM» (Platform / INBULK.COM Platform) — програмно-технічний комплекс, що включає вебсайт https://inbulk.com , вебзастосунок та облікові записи Користувачів, доступні за адресою https://app.inbulk.com , програмні модулі, бази даних, інтеграції, API, а також — у разі їх впровадження та фактичної доступності — мобільні застосунки та інші цифрові сервіси під брендом INBULK.COM.
• «Група INBULK» (INBULK Group) — Оператор Платформи та інші юридичні особи, які правомірно використовують бренд INBULK і прямо визначені в умовах конкретної операції або в іншій інформації, доступній Користувачу. Сам факт належності до Групи INBULK не створює солідарної відповідальності. У кожній Угоді / Business або Замовленні за участю юридичної особи Групи INBULK така особа, її роль, реквізити та обсяг відповідальності однозначно визначаються.
• «Правовласник Платформи» (Platform Rights Holder) — особа, яка володіє або в інший спосіб належним чином контролює майнові права інтелектуальної власності на програмне забезпечення Платформи та надала Оператору Платформи право на її експлуатацію.
• «Користувач-компанія» (Company User) — юридична особа, фізична особа-підприємець або інший суб’єкт господарювання, створений чи зареєстрований відповідно до законодавства відповідної держави та зареєстрований на Платформі, від імені якого діють ідентифіковані фізичні особи — Авторизовані користувачі, які можуть створювати, подавати, підтверджувати та погоджувати Заявки на послугу, Замовлення, Угоди / Business, документи, повідомлення та інші електронні дії на Платформі.
• «Обліковий запис Користувача-компанії» (Company Account) — створене на Платформі цифрове середовище Користувача, у якому зберігаються його відомості, документи, налаштування, ролі та права доступу Авторизованих користувачів і фіксуються вчинені ними дії та операції.
• «Робочий день» (Business Day) — день, інший ніж п’ятниця, субота або офіційне свято в Арабській Республіці Єгипет, щодо зобов’язань, які виникають безпосередньо між Оператором Платформи та Користувачем-компанією за цією локалізованою редакцією Договору, якщо відповідна Угода / Business, Контракт, Замовлення чи Спеціальні умови прямо не визначають інший календар для конкретного зобов’язання або операції.
• «Акредитація» (Accreditation) — процедура перевірки Користувача-компанії, його документів, повноважень представників та відповідності вимогам до доступу користувачів, установленим Правилами користування Платформою, за результатами якої Користувач-компанія отримує доступ до відповідних функцій і сервісів Платформи.
• «Верифікація» (Verification) — процедура підтвердження особи Авторизованого користувача, достовірності наданих ним даних та, за необхідності, його повноважень діяти від імені Користувача-компанії.
• «Статус акредитації» (Accreditation Status) — інформаційне позначення стану перевірки Користувача-компанії, його документів, даних або окремих характеристик, що відображається на Платформі за результатами проведеної Оператором Платформи перевірки.
• «Авторизований користувач» (Authorized User) — ідентифікована фізична особа, зокрема директор, Підписант, менеджер, трейдер, логіст, бухгалтер, диспетчер, інший працівник або представник, яку Користувач-компанія додав до свого Облікового запису Користувача-компанії та якій надано визначену роль, права доступу та Права на вчинення Юридично значущих дій.
• «Права на вчинення Юридично значущих дій» (Rights to Perform Legally Significant Actions) — обсяг прав, наданих Користувачем-компанією на Платформі Авторизованому користувачу для вчинення конкретних Юридично значущих дій від імені Користувача-компанії, у тому числі з обмеженнями за сумою, кількістю товару, видом операції, строком або з вимогою додаткового погодження іншою уповноваженою особою. Права на вчинення Юридично значущих дій можуть надаватися лише Авторизованому користувачу, який підтвердив, що ознайомився з цим Договором, Політикою конфіденційності та Правилами користування Платформою і зобов’язався їх дотримуватися.
• «Юридично значуща дія» (Legally Significant Action) — дія, вчинена Авторизованим користувачем від імені Користувача-компанії, яка створює, змінює або припиняє права чи обов’язки Користувача-компанії. До таких дій належать, зокрема: оприлюднення або пряме надсилання Ордера чи Зустрічного ордера, подання Заявки на послугу, Акцепт, запит і підтвердження зміни умов, підтвердження платежу, зміна банківських реквізитів або відомостей про компанію, надання прав іншим користувачам, підписання електронних документів, подання Ставки та активація Автоматичної ставки на Аукціоні.
• «Підписант» (Signer) — фізична особа, яка вчиняє дії, необхідні для накладення Електронного підпису, від власного імені або від імені Користувача-компанії в межах належно встановлених повноважень, підтверджених застосовним правом, установчими документами, відомостями з офіційного реєстру, рішенням чи протоколом уповноваженого органу управління, довіреністю або іншим належним документом.
• «Ордер» (Order) — структуроване повідомлення, створене Користувачем на Платформі, що виражає намір купити або продати товари чи послуги на визначених комерційних умовах протягом визначеного строку. Ордер може бути Індикативним або Безвідзивним. Оприлюднення або надсилання Ордера створює юридично обов’язкові наслідки лише тоді, коли Ордер має статус «Firm». Ордер може бути оприлюднений на Платформі або надісланий безпосередньо конкретному Користувачу як «Прямий ордер».
• «Зустрічний ордер» (Counter Order) — безвідзивна пропозиція Користувача укласти Угоду / Business на змінених умовах, надіслана у відповідь на Ордер або інший Зустрічний ордер.
• «Індикативний ордер» / «Soft» (Indicative Order / Soft) — статус Ордера, що застосовується, коли Ордер оприлюднюється або надсилається конкретному Користувачу для перевірки попиту чи пропозиції, отримання комерційних пропозицій і проведення переговорів. Індикативний ордер не створює юридично обов’язкових наслідків, може бути змінений або відкликаний до погодження сторонами остаточних умов і сам по собі не створює обов’язку укласти Угоду / Business.
• «Безвідзивний ордер» / «Firm» (Firm Order / Firm) — статус Ордера або Зустрічного ордера, який містить достатньо визначені умови пропонованої операції та підтверджує намір Користувача її виконати, якщо Ордер буде повністю та беззастережно Акцептований іншою стороною. Він є чинним протягом строку, визначеного Користувачем. Протягом цього строку Користувач не може змінити або відкликати Ордер.
• «Аукціон» (Auction) — електронна конкурентна процедура подання та оцінювання Ставок відповідно до правил відповідного Аукціону. До початку Аукціону всім учасникам показуються його тип, чи є Ставки обов’язковими, спосіб визначення переможця, будь-які права на відкликання, наслідки технічного збою та точний момент виникнення юридичних зобов’язань.
• «Ставка» (Bid) — електронна комерційна пропозиція, подана учасником Аукціону. Подання Ставки є Юридично значущою дією. Обов’язковість Ставки, строк її дії, можливість відкликання або втрати нею чинності та момент виникнення зобов’язань визначаються правилами відповідного Аукціону чи Тендера, умовами, відображеними учаснику до подання, та застосовним правом. Ставка є обов’язковою та безвідзивною лише в обсязі, передбаченому такими правилами та застосовним правом.
• «Автоматична ставка» (Auto-Bidding) — функція Аукціону, яка дозволяє Платформі автоматично підвищувати або знижувати ціну від імені Користувача без необхідності подавати кожну наступну Ставку вручну. До активації Користувач встановлює граничну ціну та крок ставки. Платформа автоматично подає Ставки в межах визначеного ліміту залежно від типу Аукціону та припиняє подавати Ставки після досягнення граничної ціни або завершення Аукціону.
• «Тендер» (Tender) — конкурентний запит, створений Користувачем на Платформі на купівлю чи продаж товарів або надання послуг, за яким інші Користувачі можуть подавати пропозиції на визначених умовах. Користувач, який створив Тендер, обирає переможця відповідно до визначених ним умов і критеріїв. Юридичні наслідки такого вибору визначаються умовами відповідного Тендера та показуються Користувачам до подання пропозицій.
• «Угода / Business» (Business) — операція між Користувачами, укладена за результатами Акцепту Безвідзивного ордера або Зустрічного ордера та сформована електронно на Платформі INBULK. Вона містить погоджені сторонами комерційні умови та створює для них юридичний обов’язок підписати відповідний Контракт на цих умовах і належно виконати Угоду / Business. Угода / Business вважається укладеною в момент фіксації Акцепту Платформою відповідно до п. 7.5.
• «Підтвердження Угоди» (Business Confirmation) — електронне повідомлення, сформоване Платформою, що підтверджує укладення Угоди / Business і фіксує її основні погоджені умови. Підтвердження Угоди відображається на Платформі та надсилається на адреси електронної пошти сторін Угоди / Business.
• «Контракт» (Contract) — договір, сформований на Платформі на підставі укладеної Угоди / Business і погоджених сторонами умов, який може ґрунтуватися на застосовних формах і правилах GAFTA, FOSFA чи іншому прямо визначеному стандарті та підписується сторонами з використанням Електронного підпису.
• «Incoterms» — правила Міжнародної торгової палати щодо умов постачання. За замовчуванням застосовуються Incoterms® 2020. Обраний термін, погоджене місце, порт чи інший конкретний пункт постачання та застосовна редакція правил зазначаються в остаточних умовах Угоди / Business.
• «Заявка на послугу» (Service Request) — структурований запит, створений і поданий Користувачем на Платформі на організацію або надання агентських, логістичних, сюрвейєрських, інспекційних, лабораторних, страхових, фумігаційних, митно-брокерських, інформаційних, фінансових чи інших послуг, доступних на Платформі. Подання Заявки на послугу є Юридично значущою дією, якою Користувач визначає параметри послуги, режим формування Замовлення, критерії або конкретного Виконавця послуги та, на власний вибір, чи потрібне остаточне підтвердження. Якщо Заявка на послугу не містить вказівки про необхідність остаточного підтвердження Користувачем, вона дозволяє сформувати Замовлення без повторного підтвердження Користувачем у межах параметрів, визначених у Заявці, після її прийняття Виконавцем послуги або автоматизованим сервісом. Зазначення конкретного Виконавця послуги підтверджує адресний і конкретний характер наміру Користувача; пряма вказівка про необхідність остаточного підтвердження має переважну силу.
• «Підтвердження прийняття Заявки на послугу» (Service Request Acceptance Confirmation) — електронний документ або системний запис, сформований Платформою, що фіксує прийняття Заявки на послугу Виконавцем послуги та формування Замовлення відповідно до обраного Користувачем режиму. Якщо Заявка на послугу не вимагала остаточного підтвердження Користувачем, Підтвердження фіксує вже сформоване Замовлення й не потребує подальшого Акцепту. Якщо остаточне підтвердження вимагалося, Підтвердження відображає остаточні умови Виконавця послуги, а Замовлення виникає лише після окремого Акцепту Користувачем.
• «Замовлення» (Service Order) — операція з надання конкретної агентської, логістичної, перевізної, транспортно-експедиторської, сюрвейєрської, лабораторної, фумігаційної, страхової, фінансової чи іншої послуги, сформована через Платформу: (1) без повторного підтвердження Користувачем після прийняття Виконавцем послуги Заявки на послугу в межах визначених у ній параметрів, якщо Заявка не вимагала остаточного підтвердження; (2) після Акцепту Користувачем остаточних умов, якщо таке підтвердження прямо вимагалося Заявкою на послугу або запропоновані умови виходять за її параметри; або (3) за іншим прямо відображеним сценарієм, погодженим Користувачем до вчинення відповідної Юридично значущої дії. Замовлення має визначати Виконавця послуги, предмет і обсяг послуги, ціну або спосіб її визначення, строки, порядок оплати, застосовні документи, умови зміни та скасування й інші істотні умови. Права та обов’язки за Замовленням виникають у момент фіксації Платформою події, яка відповідно до розділу 8 цього Договору формує Замовлення.
• «Спеціальні умови» (Special Terms) — правила, тарифи та інші умови конкретної послуги або виду послуг, що регулюють її надання, оплату, зміну, скасування, документування та відповідальність, доведені до Користувача до вчинення Юридично значущої дії, яка формує Замовлення, і визначені за назвою, номером, датою, редакцією, контрольним ідентифікатором або хешем.
• «Режим виконання послуги» (Service Performance Mode) — режим, обраний Користувачем у Заявці на послугу: (1) з додатковим забезпеченням виконання, коли Замовлення передбачає один або кілька доступних інструментів страхування, ескроу, Забезпечення виконання, документарних розрахунків чи інший погоджений інструмент; або (2) без додаткового забезпечення виконання. Будь-яке позначення першого режиму в інтерфейсі як «гарантованого» означає лише те, що обрано зазначені інструменти, і не є гарантією виконання з боку Оператора Платформи чи INBULK.
• «Акцепт» (Acceptance) — остаточна та беззастережна Юридично значуща дія, якою Авторизований користувач повністю приймає конкретний Безвідзивний ордер, Зустрічний ордер, остаточні умови Заявки на послугу, якщо потрібне окреме підтвердження, або запропоновану зміну умов Угоди / Business чи Замовлення. Після Акцепту та його фіксації Платформою відповідна Угода / Business або Замовлення вважаються укладеними та створюють права й обов’язки для їх сторін, а щодо Угоди / Business — з урахуванням п. 7.5. Замовлення також може бути сформоване без повторного Акцепту Користувачем у випадках і межах, прямо визначених у Заявці на послугу та розділі 8 цього Договору.
• «Номінація» (Nomination) — визначення Користувачем у межах Угоди / Business конкретного перевізника, експедитора, терміналу, елеватора, сюрвейєра, лабораторії, страховика чи іншого контрагента, з яким Користувач самостійно укладає окремий договір на виконання. Номінація не є Замовленням через Платформу INBULK і не робить Оператора Платформи стороною відносин між Користувачем і номінованим контрагентом.
• «Виконавець послуги» (Service Provider) — Оператор Платформи, інший Користувач або Сторонній постачальник, який зобов’язується надати замовлену послугу на умовах, визначених у Замовленні. Виконавець послуги має бути прямо визначений в остаточних умовах Замовлення.
• «Агент» (Agent) — Оператор Платформи або інша конкретна юридична особа Групи INBULK, прямо визначена в умовах відповідного Замовлення, яка — виключно в обсязі, дозволеному законом, і після виконання будь-якої необхідної реєстраційної, ліцензійної чи іншої регуляторної умови — вчиняє визначені фактичні та/або юридичні дії від імені та за рахунок Користувача. Щодо Єгипту жодне положення цього Договору саме по собі не уповноважує INBULK.COM LLC чи іншу особу INBULK здійснювати регульовану комерційну агентську діяльність, комерційне посередництво або інше регульоване посередництво за Законом Єгипту № 120 від 1982 року чи іншим застосовним правом. Будь-яка така регульована роль має бути окремо визначена, юридично доступна та задокументована до вчинення відповідної Юридично значущої дії.
• «ШІ-асистент / AI Assistant» (AI Assistant) — функціональний модуль Платформи, який використовує технології штучного інтелекту для формування інформаційних відповідей, пояснень та аналітичних матеріалів і для підготовки чернеток Ордерів, Заявок на послугу та інших документів чи дій на основі запитів Користувача. Матеріали, сформовані ШІ-асистентом, самі по собі не є Юридично значущими діями та набувають юридичного значення лише після окремої перевірки та підтвердження Користувачем.
• «Сервіси супроводження розрахунків» (Settlement Support Services) — Сервіс ескроу-розрахунків, Сервіс забезпечення виконання, Сервіс документарних розрахунків і Сервіс супроводження страхування.

Кожен Сервіс супроводження розрахунків є інформаційно-технологічним сервісом Платформи. Платформа не отримує, не зберігає та не переказує кошти Користувачів і не набуває права розпоряджатися ними; не є стороною договорів, укладених Користувачами з Ескроу-агентом, Емітентом Забезпечення, Банком-емітентом або Страховиком; не визначає, чи виконана або порушена Угода / Business; не подає вимоги, заяви чи комплекти документів від імені Користувачів; і не надає регульованих фінансових, платіжних або страхових послуг чи послуг фінансового або страхового посередництва без необхідного правового статусу та окремої договірної моделі. Це положення не обмежує звичайних агентських, організаційних, інформаційних чи технологічних послуг, прямо задокументованих у відповідному Замовленні.

Формування Платформою чернеток документів за шаблонами не є юридичними послугами, юридичною консультацією або підтвердженням обґрунтованості вимоги чи запиту. Використання будь-якого Сервісу супроводження розрахунків не є обов’язковою умовою укладення або виконання Угоди / Business.

• «Ескроу-агент» (Escrow Agent) — банк або інша особа, уповноважена за застосовним до неї правом відкривати та обслуговувати рахунки умовного зберігання («Рахунок ескроу») чи інший функціонально рівнозначний інструмент умовних розрахунків за договором зі Сторонами Угоди / Business («Договір ескроу»). Платформа не є стороною Договору ескроу.
• «Умови вивільнення» (Release Conditions) — погоджені Сторонами Угоди / Business і зафіксовані на Платформі підстави для переказу коштів із Рахунку ескроу вигодонабувачу разом із документами та підтвердженнями, що засвідчують настання таких підстав («Тригерні документи»), як-от коносамент, звіт сюрвейєра, акт приймання-передачі, митна декларація, підтвердження сторони або подібний документ. Умови вивільнення є обов’язковими для Ескроу-агента лише в обсязі, у якому вони включені до Договору ескроу.
• «Сервіс ескроу-розрахунків» (Escrow Settlement Service) — сервіс Платформи, що надає Сторонам Угоди / Business технічну можливість ініціювати відкриття Рахунку ескроу, погодити й зафіксувати Умови вивільнення, формувати та передавати Ескроу-агенту Тригерні документи й повідомлення та відстежувати статуси розрахунків. Платформа не є власником Рахунку ескроу, вигодонабувачем або Ескроу-агентом. Кошти переказує виключно Ескроу-агент; формування або передання Платформою документів і повідомлень не є інструкцією про розпорядження коштами та не зобов’язує Ескроу-агента здійснити переказ.
• «Забезпечення виконання» (Performance Security) — інструмент, наданий однією Стороною Угоди / Business на користь іншої Сторони для забезпечення виконання її зобов’язань за Угодою / Business, у формі, визначеній в Угоді / Business або Замовленні до Акцепту. Допустимі форми включають: Гарантію виконання Продавця, що забезпечує постачання товару, його кількість, якість і строки; Платіжну гарантію Покупця, що забезпечує оплату товару; Гарантію виконання Покупця, що забезпечує негрошові зобов’язання Покупця, у тому числі номінацію транспортного засобу, приймання товару та надання інструкцій; резервний акредитив (SBLC); кошти на Рахунку ескроу; гарантійний депозит; та інші форми, прямо погоджені Сторонами.
• «Гарантія виконання Продавця» (Seller’s Performance Bond) — Забезпечення виконання, надане Продавцем на користь Покупця, що забезпечує зобов’язання Продавця за Угодою / Business щодо постачання товару, його кількості, якості та строків.
• «Гарантія виконання Покупця» (Buyer’s Performance Bond) — Забезпечення виконання, надане Покупцем на користь Продавця, що забезпечує грошові та негрошові зобов’язання Покупця за Угодою / Business, у тому числі номінацію транспортного засобу, приймання товару та надання інструкцій.
• «Емітент Забезпечення» (Security Issuer) — банк, інша фінансова установа або страхова організація, яка видає Забезпечення виконання відповідно до застосовного до неї права. Щодо гарантійного депозиту Емітент Забезпечення не визначається, а щодо коштів на Рахунку ескроу відповідні функції виконує Ескроу-агент.
• «Умови Забезпечення» (Security Terms) — умови, погоджені Сторонами та зафіксовані в Безвідзивному ордері, Зустрічному ордері, Угоді / Business чи Замовленні до Акцепту відповідних умов, у тому числі: форма Забезпечення виконання, його сума або спосіб розрахунку, вимоги до Емітента Забезпечення, строк надання та строк дії, застосовні правила (у тому числі URDG 758, ISP98 та UCP 600), характер вимоги, чи допускаються часткові або повторні вимоги, порядок зменшення суми Забезпечення після часткового виконання та підстави припинення Забезпечення.
• «Вимога за Забезпеченням» (Demand under the Security) — вимога вигодонабувача до Емітента Забезпечення про виплату за Забезпеченням виконання, яку вигодонабувач подає самостійно відповідно до умов Забезпечення виконання та застосовних правил.
• «Сервіс забезпечення виконання» (Performance Security Service) — сервіс Платформи, що надає Сторонам Угоди / Business технічну можливість погодити й зафіксувати Умови Забезпечення, завантажувати та зберігати документи Забезпечення виконання, відстежувати строки його надання та дії, отримувати повідомлення й формувати чернетки документів за шаблонами Платформи для подання Емітенту Забезпечення. Платформа не є Емітентом Забезпечення, гарантом, поручителем, контргарантом, вигодонабувачем або стороною Забезпечення виконання; не видає та не підтверджує Забезпечення виконання; не перевіряє його дійсність або правоздатність Емітента Забезпечення; не зменшує та не припиняє Забезпечення; не визначає, якою мірою забезпечені зобов’язання виконані належним чином; і не оцінює обґрунтованість суми, заявленої у Вимозі за Забезпеченням.
• «Акредитив (LC)» (Letter of Credit (LC)) — безвідкличне зобов’язання банку, що відкриває Акредитив («Банк-емітент»), здійснити платіж на користь Сторони, на користь якої він відкритий («Бенефіціар»), проти подання документів, що відповідають Умовам акредитива, незалежно від правовідносин за Угодою / Business. Акредитив відкривається на прохання іншої Сторони Угоди / Business («Заявник») і може бути авізований, підтверджений або виконаний іншими банками відповідно до Умов акредитива та застосовних правил. Акредитив може бути: документарним («DLC») — як спосіб розрахунків за Угодою / Business, за якого платіж здійснюється проти документів, що підтверджують постачання товару, відповідно до UCP 600; або резервним («SBLC») — як форма Забезпечення виконання, за якої платіж здійснюється проти документів, що підтверджують невиконання забезпечених зобов’язань, відповідно до ISP98 або UCP 600.
• «Умови акредитива» (Letter of Credit Terms) — умови, погоджені Сторонами та зафіксовані в Безвідзивному ордері, Зустрічному ордері, Угоді / Business чи Замовленні до Акцепту відповідних умов, у тому числі: вид Акредитива, застосовні правила (UCP 600, eUCP, ISP98), сума, валюта, строк дії, місце подання, вимоги до Банку-емітента та потреба в підтвердженні, перелік і вимоги до документів, строки відвантаження та подання, чи допускаються часткові відвантаження й часткові вибірки, а також розподіл банківських комісій.
• «Презентація» (Presentation) — документи, подані Бенефіціаром відповідно до Умов акредитива з метою отримання платежу. Будь-яка невідповідність Презентації Умовам акредитива або застосовним правилам, визначена банком, що перевіряє документи, становить «Розбіжності».
• «Сервіс документарних розрахунків» (Documentary Settlement Service) — сервіс Платформи, що надає Сторонам Угоди / Business технічну можливість погодити й зафіксувати Умови акредитива, формувати чернетки заяв на відкриття Акредитива та пов’язаних документів, завантажувати й зберігати пов’язані документи, відстежувати строки відвантаження, подання та дії й отримувати повідомлення. Платформа не є Банком-емітентом, авізуючим, підтверджуючим або виконуючим банком; не відкриває, не авізує, не підтверджує та не виконує Акредитив; не подає Презентацію; не перевіряє документи на відповідність Умовам акредитива в розумінні застосовних правил; не визначає Розбіжності; і не приймає рішення про здійснення чи відмову в платежі.
• «Сервіс супроводження страхування» (Insurance Support Service) — сервіс Платформи, що надає Користувачу технічну можливість фіксувати Умови страхування щодо Угоди / Business чи Замовлення, завантажувати та зберігати договори страхування, поліси, сертифікати й пов’язані документи, відстежувати параметри покриття та строки повідомлення Страховика й подання Заяви про виплату, отримувати повідомлення та формувати чернетки документів за шаблонами Платформи для подання Страховику, перевізнику чи експедитору. Платформа не є Страховиком, страховим посередником, агентом, брокером або аварійним комісаром; не здійснює страхову діяльність; не укладає договорів страхування та не видає полісів чи сертифікатів; не оцінює страхові ризики; не визначає параметри покриття чи їх достатність; не визначає настання страхового випадку; не подає Заяву про виплату; не приймає рішення про страхове відшкодування; і не гарантує здійснення будь-якої страхової виплати.
• «Страховик» (Insurer) — страхова організація, експортно-кредитне агентство, товариство взаємного страхування або інший страховик, уповноважений здійснювати відповідний вид страхування за застосовним до нього правом.
• «Страхувальник» (Insured) — Користувач або інша особа, яка укладає договір страхування зі Страховиком щодо власного страхового інтересу, пов’язаного з Угодою / Business чи Замовленням. Право на отримання відшкодування може бути надане іншій особі, у тому числі банку або Фінансуючому партнеру, якому таке право відступлене («Вигодонабувач за полісом»). Звернення Страхувальника або Вигодонабувача за полісом до Страховика про виплату страхового відшкодування («Заява про виплату») подається такою особою самостійно відповідно до договору страхування.
• «Умови страхування» (Insurance Terms) — умови, погоджені Сторонами та зафіксовані в Безвідзивному ордері, Зустрічному ордері, Угоді / Business чи Замовленні до Акцепту відповідних умов, у тому числі: вид страхування, особа, відповідальна за його оформлення, вимоги до Страховика, обсяг покриття та застраховані ризики, франшиза, Вигодонабувач за полісом, строки повідомлення Страховика та подання Заяви про виплату, а також обмеження та винятки з покриття. Залежно від виду страхування Умови страхування можуть також визначати кредитний ліміт, відсоток відшкодування, період очікування, Страхову суму та Період покриття.
• «Страхування кредитних ризиків» (Trade Credit Insurance) — страхування майнового інтересу Страхувальника від ризику невиконання його контрагентом грошових зобов’язань за Угодою / Business.
• «Страхування вантажу» (Cargo Insurance) — страхування майнового інтересу Страхувальника від ризику втрати, нестачі або пошкодження товару під час перевезення, перевалки, зберігання та інших операцій у межах Періоду покриття за договором страхування, полісом або сертифікатом («Поліс страхування вантажу»). Обсяг покриття визначається застосовними застереженнями, у тому числі Institute Cargo Clauses (A), (B) або (C), Institute War Clauses та Institute Strikes Clauses. Якщо Умовами страхування не визначено інше, Страховою сумою є вартість товару за Угодою / Business плюс фрахт, інші витрати та погоджений Сторонами відсоток.
• «Страхування відповідальності перевізника або експедитора» (Carrier or Freight Forwarder Liability Insurance) — страхування майнового інтересу перевізника, експедитора чи іншого надавача логістичних послуг щодо його відповідальності перед замовником або третіми особами. Таке страхування діє в межах відповідальності відповідної особи та обмежень, установлених договором перевезення й правилами, застосовними до відповідного виду транспорту (у тому числі Конвенцією КДПВ, Гаазько-Вісбійськими правилами, Монреальською конвенцією, правилами УМВС/ЦІМ та законодавством про перевезення внутрішніми водними шляхами), і не є Страхуванням вантажу.
• «Загальна аварія» (General Average) — надзвичайні витрати або пожертвування, навмисно та розумно понесені заради спільної безпеки судна, вантажу і фрахту та розподілені між учасниками морського підприємства відповідно до застосовних правил, у тому числі Йорк-Антверпенських правил. Внески із загальної аварії покриваються страхуванням лише в обсязі, передбаченому Умовами страхування.
• «Регрес Страховика» (Subrogation) — право Страховика, який здійснив виплату відшкодування, вимагати відшкодування від особи, відповідальної за страховий випадок, у межах виплаченої суми. Користувачі повинні утримуватися від дій, що завдають шкоди такому праву, у тому числі від відмови від вимог до перевізника без згоди Страховика.
• «Електронний документ» (Electronic Document) — документ, інформація в якому зафіксована в електронній формі разом з обов’язковими реквізитами, у тому числі Електронним підписом, якщо він потрібен для відповідного виду документа.
• «Електронний підпис» (Electronic Signature) — електронні дані, які додаються до Електронного документа або логічно з ним пов’язані та використовуються Підписантом для підписання. Доступні рівні, технічна реалізація та правила використання визначені Політикою електронного підпису.
• «Автентифікація» (Authentication) — підтвердження засобами Платформи того, що особа є тією, за кого себе видає.
• «Підписання» (Signing) — послідовність дій на Платформі, що включає: надання Підписанту остаточної редакції Електронного документа для ознайомлення, Автентифікацію, підтвердження Підписантом наміру бути зв’язаним умовами документа та накладення Електронного підпису. Часом Підписання є час фіксації Платформою завершення цієї процедури за серверним часом (UTC).
• «Доказова база підписання» (Signing Evidence) — дані, сформовані та збережені Платформою щодо кожного Підписання, у тому числі: криптографічний відбиток (хеш) документа, ідентифікатори Підписанта й Користувача, спосіб Автентифікації, дослівний текст підтвердження наміру, IP-адреса та відомості про пристрій доступу, дата й час системних подій (UTC), електронна позначка часу, якщо вона застосовувалася, та ідентифікатори системних подій. На підставі таких даних Платформа формує Протокол підписання, доступний Користувачу для завантаження.
• «Оператор підписання» (Signing Operator) — Оператор Платформи або залучений ним Сторонній постачальник, який організовує технічний процес Підписання та формування Доказової бази підписання. Відповідні дії вчиняються через Платформу та/або інтегрований сервіс.
• «Провайдер електронного підпису» (Electronic Signature Provider) — особа, залучена Оператором Платформи для супроводження Підписання, яка надає послуги створення, накладення або перевірки Електронного підпису, електронної ідентифікації Підписанта, надання електронних позначок часу, роботи із сертифікатами та інші пов’язані послуги. Послуги, які за застосовним правом вимагають спеціального статусу надавача довірчих послуг, надаються виключно особою, яка має такий статус. Оператор Платформи може виконувати технічні функції, що не потребують такого статусу, але не має права називати себе надавачем кваліфікованої довірчої послуги без належної правової підстави.
• «Політика електронного підпису» (Electronic Signature Policy) — документ, оприлюднений на Платформі, що визначає рівні Електронного підпису, вимоги до Автентифікації, застосування рівнів до видів документів і дій, залучених Провайдерів, склад і строки зберігання Доказової бази підписання та особливості окремих юрисдикцій.

2.2. У цьому Договорі термін «Користувач» у визначеннях, назвах функцій та операційних положеннях означає Користувача-компанію, якщо контекст чітко не вимагає іншого. «Сторони» без додаткового уточнення означають Оператора Платформи та Користувача-компанію; «Сторони Угоди» означають Користувачів, між якими укладено відповідну Угоду / Business. Однина включає множину і навпаки, якщо це узгоджується з контекстом. Скорочені форми мають те саме значення, що й відповідні повні визначені терміни.

2.3. Заголовки, переклади та мовні відповідники використовуються для зручності. Юридично переважним текстом для відповідної Користувача-компанії є Підписна версія, зазначена в Заяві про приєднання та прийняття відповідно до п. 15.9. Будь-який переклад іншою мовою має суто інформаційний характер, якщо він прямо не визначений як Підписна версія. Законодавчі терміни та посилання мають значення, надане їм застосовним правом.

3. Предмет Договору, статус Платформи та правова підстава її використання

3.1. Оператор Платформи надає Користувачу-компанії доступ до Платформи та можливість використовувати фактично доступні функції відповідно до цього Договору, застосовних Правил, Статусу акредитації, Прав на вчинення Юридично значущих дій, тарифів і прийнятих умов відповідної операції.

3.2. Функціонал може включати створення та обробку Ордерів, Зустрічних ордерів, Аукціонів, Тендерів, Угод / Business, Контрактів, Заявок на послугу, Замовлень, Номінацій, електронних документів, Сервісів супроводження розрахунків, сервісів пошуку, організації та супроводження фінансування, аналітичних сервісів та інших сервісів, доступних на Платформі.

3.3. Згадка функції або визначення в цьому Договорі не означає, що функція вже запущена в регіоні Користувача. Відповідні положення застосовуються лише після того, як функція або сервіс фактично стають доступними, застосовні умови відображені Користувачу, а Користувач вчинив необхідну Юридично значущу дію.

3.4. Платформа є програмно-технічним комплексом і не є юридичною особою. Стороною Договору, Угоди / Business, Контракту, Замовлення чи інших правовідносин може бути лише конкретна особа, прямо визначена у відповідному документі.

3.5. Оператор Платформи не стає покупцем, продавцем, Виконавцем послуги, комерційним агентом, комерційним посередником, експедитором, страховиком, банком, надавачем платіжних послуг чи іншою стороною лише внаслідок надання технічного функціоналу. Будь-яка додаткова роль потребує окремого визначення та, за застосовності, виконання реєстраційних, ліцензійних, дозвільних чи інших регуляторних вимог, чинних у Єгипті.

3.6. Оператор Платформи здійснює експлуатацію Платформи на підставі чинного ліцензійного договору та/або інших належних прав, наданих Правовласником Платформи. Номер і дата такого ліцензійного договору не є істотними умовами цього Договору та в ньому не наводяться; підтвердження правової підстави зберігається Оператором у корпоративних документах і документах щодо прав інтелектуальної власності та може бути надане у зв’язку з обґрунтованим запитом на перевірку з дотриманням конфіденційності.

3.7. Оператор Платформи вживає розумних організаційних і технічних заходів для роботи Платформи, але не гарантує абсолютної безперервності, безперебійної доступності або відсутності технічного обслуговування, оновлень чи збоїв Сторонніх постачальників.

3.8. Доступ до Платформи є обмеженим договірним правом користуватися доступним програмним функціоналом і не є переданням технології, технічного ноу-хау, вихідного коду, виробничого процесу, методу виробництва чи інших технічних знань Користувачу-компанії в розумінні статей 72–87 Комерційного кодексу Єгипту (Закон № 17 від 1999 року). Якщо окрема домовленість фактично становить договір про передання технології за імперативними нормами права Єгипту, вона оформлюється окремо, і переважну силу мають імперативні норми, застосовні до такого договору, у тому числі будь-які обов’язкові вимоги щодо застосування права Єгипту та місця розгляду в Єгипті.

4. Договірні документи, застосовні Правила та порядок пріоритетності

4.1. Відносини між Оператором Платформи та Користувачем-компанією регулюються цим Договором, Заявою про приєднання та прийняття, застосовними Правилами користування Платформою, тарифами, прийнятими умовами конкретних сервісів та Операційними політиками, зазначеними в п. 4.4, у межах визначеної ними сфери дії.

Чинні редакції документів, що регулюють користування Платформою, доступні за такими адресами:

Правила користування Платформою INBULK.COM — https://help.inbulk.com/terms ;

Політики Платформи — https://help.inbulk.com/policies 

Редакція відповідного документа, застосовна до конкретного Користувача або операції, визначається за її редакцією, датою, контрольним ідентифікатором чи іншими відомостями, зафіксованими Платформою до вчинення відповідної Юридично значущої дії.

4.2. Правила користування Платформою регулюють операційні, процедурні, технічні та організаційні аспекти користування Платформою, а також інші питання, прямо віднесені до них цим Договором. Вони застосовуються в обсязі, що не суперечить цьому Договору, імперативним нормам права або прийнятим умовам відповідної операції. У разі будь-якої суперечності, у тому числі розбіжності у визначеннях, у моменті чи юридичних наслідках дії, у ролях, правах, обов’язках або відповідальності, у відносинах між Оператором Платформи та Користувачем-компанією переважну силу має цей Договір.

4.3. Якщо будь-яке положення Правил користування Платформою суперечить цьому Договору або встановлює інший режим для тих самих відносин, застосовуються положення цього Договору.

Зокрема, Правила користування Платформою не застосовуються в обсязі, у якому вони встановлюють інший порядок приєднання до цього Договору, прийняття нової редакції, укладення, зміни чи припинення Угоди / Business або Замовлення, або інші права, обов’язки чи відповідальність сторін.

4.4. Операційні політики, на які прямо посилаються цей Договір, Правила користування Платформою, застосовні Спеціальні умови або інтерфейс до вчинення відповідної Юридично значущої дії, застосовуються лише в межах визначеної ними сфери дії та на рівні, підпорядкованому цьому Договору й прийнятим умовам відповідної операції. Такі Операційні політики можуть регулювати процедури, технічні вимоги, доказову базу, Акредитацію, Верифікацію, Електронне підписання, інформаційну безпеку, використання ШІ-функцій та інші операційні питання, але самі по собі не можуть змінювати цей Договір або вже укладені Угоду / Business, Контракт чи Замовлення. Політика конфіденційності, Політика cookie та інші повідомлення про приватність чи прозорість є окремими інформаційними повідомленнями. Ознайомлення з такими повідомленнями, їх отримання або підтвердження саме по собі не є згодою, якщо застосовне право вимагає окремої правової підстави або окремої згоди.

4.5. Документи конкретної Угоди / Business або Замовлення регулюють права та обов’язки лише тих осіб, які прямо визначені в них як сторони або учасники. Формування, підписання чи зберігання документа на Платформі саме по собі не робить Оператора Платформи стороною операції.

4.6. До конкретної торгової операції застосовується такий порядок пріоритетності: (1) пізніша двостороння зміна, що прямо визначає умову, яка змінюється; (2) Контракт — в обсязі, у якому він підписаний усіма сторонами та прямо містить зміну чи доповнення, погоджені після укладення Угоди / Business; (3) Акцептований Безвідзивний ордер або Зустрічний ордер разом із Підтвердженням Угоди; (4) прямо включені стандартні правила; (5) правила відповідного Аукціону чи Тендера; (6) цей Договір; та (7) Правила користування Платформою. Контракт, який лише відтворює Угоду / Business, не має переваги над Акцептованим Ордером у разі технічної або текстової розбіжності. Будь-яка зміна комерційної умови в Контракті має бути прямо погоджена обома сторонами як зміна Угоди / Business.

4.7. До Замовлення застосовується такий порядок пріоритетності: (1) пізніша двостороння зміна; (2) остаточні умови Замовлення, сформовані відповідно до режиму Заявки на послугу або Акцептовані Користувачем; (3) прийняті Спеціальні умови відповідної послуги; (4) цей Договір; та (5) Правила користування Платформою.

4.8. Документ нижчого рівня не змінює документ вищого рівня, якщо відповідні сторони прямо не погодили таку зміну. Нова вебредакція документа не змінює операцію, сформовану за раніше зафіксованою редакцією.

4.9. Правило користування Платформою, Спеціальна умова, правило Аукціону чи Тендера, умова Стороннього постачальника або інше стандартне договірне положення включається до конкретних правовідносин лише тоді, коли воно було чітко ідентифіковане та надане відповідному Користувачу до вчинення Юридично значущої дії, якою такий Користувач має його прийняти або стати ним зв’язаним. Платформа фіксує застосовну редакцію, дату, контрольний ідентифікатор або хеш. Умови конкретної операції, які за правом Єгипту потребують певної форми, підпису, реєстрації, державного погодження чи іншої обов’язкової формальності, не набирають чинності до виконання такої вимоги.

5. Акредитація, Верифікація, Обліковий запис Користувача-компанії та права Авторизованих користувачів

5.1. Акредитація проводиться щодо Користувача-компанії, його документів, представників і відповідності вимогам доступу. Верифікація проводиться щодо конкретного Авторизованого користувача. Ці процедури мають окремі статуси й не замінюють одна одну.

5.2. Оператор може перевіряти реєстраційну, корпоративну, санкційну, репутаційну та іншу інформацію, запитувати додаткові документи й повторювати Акредитацію чи Верифікацію в разі зміни відомостей або виникнення ризику.

5.3. Статус акредитації відображає лише результат обсягу перевірок, проведених станом на відповідну дату. Він не є гарантією платоспроможності, добросовісності, наявності товару, якості послуг або майбутнього виконання.

5.4. Кожен Користувач самостійно перевіряє свого контрагента, Виконавця послуги та Фінансуючого партнера, комерційну доцільність операції й оцінює правові, кредитні, санкційні, податкові, валютні, логістичні та інші ризики. Статус акредитації, рейтинг, скоринг, результат верифікації, вибір Режиму виконання послуги або використання додаткового забезпечення не звільняють Користувача від власної перевірки та не є гарантією виконання.

5.5. До завершення Акредитації, Верифікації або розгляду додатково запитаних документів Оператор може тимчасово обмежити ті функції або Юридично значущі дії, ризик яких неможливо належно оцінити до завершення відповідної перевірки.

5.6. Користувач-компанія надає повну, достовірну та актуальну інформацію й повідомляє про будь-яку зміну без невиправданої затримки та в будь-якому разі не пізніше ніж протягом трьох Робочих днів, якщо інший строк не встановлений законом або умовами операції.

5.7. Діяти від імені Користувача-компанії можуть лише Авторизовані користувачі, додані до його Облікового запису Користувача-компанії.

5.8. Технічна роль або право переглядати, створювати чи редагувати дані не надає Права на вчинення Юридично значущих дій. Такі Права надаються окремо й можуть бути обмежені за видом дії, сумою, кількістю, контрагентом, строком і вимогою додаткового погодження.

5.9. Користувач-компанія самостійно перевіряє корпоративні, посадові, установчі, делеговані та інші повноваження особи, отримує внутрішні погодження, правильно налаштовує Права та своєчасно їх скасовує.

5.10. Юридично значуща дія може бути вчинена лише за наявності необхідного Права, з дотриманням застосовного ліміту, після отримання будь-якого необхідного додаткового погодження та після завершення необхідної Автентифікації чи Підписання.

5.11. Дії Авторизованого користувача, вчинені в межах Прав, відображених на Платформі, вважаються діями Користувача-компанії. Внутрішні обмеження, не відображені на Платформі та не доведені до іншої сторони до вчинення дії, не можуть протиставлятися добросовісній стороні, крім випадків, передбачених законом.

5.12. Кожен Авторизований користувач використовує лише власні засоби доступу, засоби Автентифікації та Електронний підпис. Передання логіна, пароля, одноразового коду (OTP), приватного ключа чи іншого засобу доступу заборонено.

5.13. У разі припинення повноважень, звільнення Авторизованого користувача від Користувача-компанії або втрати чи компрометації засобів доступу Користувач-компанія негайно скасовує відповідні Права та повідомляє Оператора. Після повідомлення Оператор може тимчасово обмежити доступ і пов’язані дії до з’ясування обставин.

5.14. До фактичного скасування Прав або до отримання Оператором належного повідомлення про втрату чи компрометацію засобів доступу дії, вчинені з використанням дійсних засобів Автентифікації та в межах відображених Прав, вважаються діями Користувача-компанії, якщо Оператор не знав і за обставинами не мав знати про неправомірний доступ. Це не звільняє Оператора від відповідальності за власне винне зволікання із застосуванням доступного блокування після отримання належного повідомлення та спливу об’єктивно необхідного часу для вжиття відповідних заходів.

6. Електронні документи, Підписання та Юридично значущі дії

6.1. Електронна форма є основною формою взаємодії на Платформі. Електронний документ, підписаний належним способом, має юридичну силу та є оригіналом у випадках, передбачених законом.

6.2. Юридично значуща дія має бути окремою та однозначною й може бути вчинена лише після відображення остаточних умов, Користувача-компанії, від імені якого діє особа, застосовних документів і конкретних юридичних наслідків.

6.3. Перегляд сторінки, навігація, створення чернетки, завантаження файлу, отримання системного сповіщення чи інша технічна дія не є Акцептом, Підписанням, укладенням Угоди / Business або формуванням Замовлення, якщо протилежне прямо та однозначно не зазначено до вчинення такої дії. Подання Заявки на послугу є Юридично значущою дією в обсязі наслідків, прямо визначених у розділі 8 та відображених Користувачу до подання.

6.4. Для Заяви про приєднання та прийняття, а також для інших документів і Юридично значущих дій Платформа застосовує рівень Електронного підпису, Автентифікації чи підтвердження, дозволений застосовним правом і відповідний документу, юридичним наслідкам і ризику. Для Користувачів-компаній у Єгипті цифровий підпис, який має мати доказову силу власноручного підпису за правом Єгипту, повинен відповідати Закону № 15 від 2004 року про електронний підпис, Виконавчому регламенту, затвердженому Наказом міністра № 109 від 2005 року, технічним правилам і вимогам, виданим або контрольованим ITIDA, та будь-яким застосовним правилам визнання іноземних надавачів послуг сертифікації. ITIDA розрізняє цифровий підпис фізичної особи та електронну печатку юридичної особи; електронна печатка може доповнювати, але сама по собі не замінює перевірку повноважень і наміру Підписанта — фізичної особи, якщо така перевірка вимагається. Для операційних дій можуть використовуватися Автентифікація облікового запису, MFA, одноразовий код (OTP) чи інші способи, якщо обов’язкова форма підпису не застосовується, а застосовні Правила користування Платформою або Політика електронного підпису надають такій дії юридичне значення. Платформа точно описує фактично застосований спосіб і не подає просту електронну дію як цифровий підпис, що відповідає вимогам ITIDA, якщо він не відповідає застосовним юридичним і технічним вимогам.

6.5. Цей Договір не визначає конкретного Провайдера електронного підпису. Підписання здійснюється через провайдера або сервіс, доступний на Платформі для відповідного сценарію та дозволений застосовним правом. Платформа не може називатися надавачем кваліфікованої довірчої послуги лише через технічну інтеграцію, якщо вона не має статусу, якого вимагає застосовне право.

6.6. Електронний підпис підтверджує волевиявлення Підписанта та його зв’язок із документом у межах застосованого способу підпису, але сам по собі не встановлює корпоративних повноважень, відсутності внутрішніх обмежень, права розпоряджатися товаром чи коштами або належності банківського рахунку.

6.7. Платформа формує Доказову базу підписання та системні записи в обсязі, передбаченому для відповідного сценарію, у тому числі відомості про редакцію документа, Підписанта, Користувача-компанію, спосіб Автентифікації, дату й час, результат операції та ідентифікатор події. Системні журнали, записи про Права, редакції документів і пов’язані електронні докази можуть використовуватися у спорі разом з іншими допустимими доказами для встановлення особи, змісту, часу та результату дії.

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

6.9. Додавання або зміна банківських реквізитів є Юридично значущою дією підвищеного ризику й потребує окремого Права, посиленої Автентифікації та — якщо цього вимагає застосовне право, умови операції чи налаштування Користувача — Електронного підпису відповідного рівня або погодження другою уповноваженою особою. Платформа зберігає історію змін банківських реквізитів і пов’язаних перевірок та погоджень, а за наявності відповідного функціоналу повідомляє адміністраторів, визначених Користувачем. Зміна профілю не змінює банківських реквізитів раніше укладеної операції.

6.10. Операційний статус, дані GPS, фотографія, повідомлення водія, введені вручну відомості про вагу, завантажений файл, скан чи інший допоміжний запис самі по собі не встановлюють остаточного виконання зобов’язання, кількості чи якості товару, переходу права власності або ризику, чи строку платежу, крім випадків, коли дані надходять з автоматизованого складу, від сюрвейєра, лабораторії або іншого джерела, інтегрованого з Платформою INBULK у повністю автоматичному режимі, і відповідна Угода / Business, Контракт, Замовлення чи застосовні Спеціальні умови прямо надають такому джерелу або події визначальне значення. Документ або подія, що є визначальними для відповідної обставини, прямо зазначаються в Угоді / Business, Контракті, Замовленні або застосовних Спеціальних умовах.

6.11. Документ, автоматично сформований Платформою, має статус чернетки до його належного заповнення та Підписання, якщо інше прямо не передбачено законом або умовами операції. Фотографія, скан чи інша електронна копія паперового документа не замінює його оригінал або належно оформлений Електронний документ, якщо інше прямо не передбачено законом або погодженими умовами.

6.12. Будь-яка зміна Електронного документа після Підписання має бути виявною. Кожна нова редакція документа має окремий ідентифікатор і посилання на попередню редакцію; заміна чи виправлення не видаляють раніше сформований або підписаний документ і пов’язану Доказову базу підписання.

6.13. Електронні оригінали, контрольні хеші, записи про Підписання, Акцепт, подання Заявок на послугу та формування Замовлень, системні журнали й попередні редакції документів зберігаються протягом строків, установлених законом, Політикою конфіденційності, Політикою електронного підпису, відповідною операцією або обґрунтованою потребою захисту прав. У разі спору, розслідування чи законного запиту видалення зупиняється до остаточного завершення відповідної процедури та спливу застосовного строку зберігання. Закриття Облікового запису Користувача-компанії або запит на видалення не припиняють такого зберігання.

6.14. Якщо закон вимагає нотаріального посвідчення, державної реєстрації, спеціальної форми чи іншої процедури, сторони дотримуються таких вимог незалежно від функціоналу Платформи.

7. Ордери, Аукціони, Угода / Business та Контракт

7.1. Ордер може бути Індикативним або Безвідзивним і може бути оприлюднений або надісланий конкретному Користувачу як Прямий ордер. Статус прямого ордера визначає адресата, але не змінює того, чи є Ордер Soft або Firm.

7.2. Індикативний ордер не створює обов’язку укласти Угоду / Business, може бути змінений або відкликаний і використовується для перевірки попиту, отримання пропозицій і проведення переговорів.

7.3. Безвідзивний ордер і Зустрічний ордер є юридично обов’язковими протягом зазначеного строку. Для цілей правовідносин за правом Єгипту Безвідзивний ордер має діяти як достатньо визначена обов’язкова оферта (ijab), а Зустрічний ордер — як зустрічна оферта, у кожному випадку з урахуванням умов, відображених до подання. Вони не можуть бути змінені чи відкликані протягом зазначеного строку їх дії, крім випадків, передбачених законом або прямо передбачених такими умовами.

7.4. Кожна оприлюднена або передана редакція Ордера має окремий ідентифікатор. Зміна ціни, кількості, якості, умови постачання, місця, строків, порядку оплати чи іншої істотної умови створює нову редакцію. Попередня неакцептована редакція не може бути Акцептована.

7.5. Повний і беззастережний Акцепт Безвідзивного ордера або Зустрічного ордера належно уповноваженим Авторизованим користувачем разом із фіксацією такого Акцепту Платформою створює Угоду / Business. Для операції, що регулюється правом Єгипту, Угода / Business вважається укладеною в момент, коли Акцепт стає доступним через погоджений канал Платформи Користувачу, який передав акцептований Безвідзивний ордер або Зустрічний ордер, якщо інше правило не вимагається імперативними нормами права або прямо не погоджене для конкретної операції. Запис Платформи, Підтвердження Угоди, позначка часу, ідентифікатор події та пов’язані докази можуть використовуватися для встановлення моменту, коли Акцепт став доступним оференту. З цього моменту Угода / Business є остаточною обов’язковою операцією, а її сторони зобов’язані виконати погоджені умови з урахуванням будь-якої обов’язкової формальності, застосовної до такого виду операції.

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

7.7. На підставі укладеної Угоди / Business Платформа формує або надає сторонам Контракт, який фіксує та закріплює вже укладену Угоду / Business. Якщо імперативні норми права або прийняті умови операції прямо не передбачають, що окремо підписаний формальний договір є умовою дійсності чи початку виконання, наступний Контракт не є лише обіцянкою укласти майбутній договір і не є відкладальною умовою виникнення Угоди / Business. Сторони підписують сформований Контракт протягом трьох Робочих днів після укладення Угоди / Business або, якщо технічно коректний Контракт стає доступним пізніше, протягом трьох Робочих днів після того, як він став доступним.

7.8. Контракт відтворює умови Угоди / Business і може включати погоджені Incoterms® 2020, форми та правила GAFTA, FOSFA або інший прямо визначений стандарт. Назва, номер, редакція та дата застосовної стандартної форми чи правил зазначаються в Контракті або Підтвердженні Угоди. Контракт не може використовуватися для відновлення переговорів або односторонньої зміни вже Акцептованих умов.

Чинний перелік контрактів, змін, шаблонів, стандартних форм і правил, доступних для використання на Платформі, оприлюднений у розділі «Контракти» за адресою:

https://help.inbulk.com/contracts 

7.9. Сторона, яка виявила технічну або текстову невідповідність між Контрактом і умовами Угоди / Business, повідомляє про це іншу сторону без невиправданої затримки. Будь-яке виправлення обмежується приведенням Контракту у відповідність до Акцептованого ордера й не відновлює права на перегляд комерційних умов.

7.10. Якщо Угода / Business уже стала обов’язковою за п. 7.5, необґрунтована відмова, ухилення або затримка підписання Контракту, що її закріплює, більш ніж на три Робочі дні є істотним порушенням Угоди / Business, але сама по собі не скасовує Угоду / Business і не звільняє сторону, яка відмовляється, від погоджених зобов’язань. Цей пункт не скасовує жодної імперативної норми права Єгипту, яка вимагає певної форми для дійсності конкретного виду договору. Інша сторона може скористатися засобами правового захисту, доступними за Угодою / Business, Контрактом і застосовним правом. Оператор може зафіксувати порушення й тимчасово обмежити створення нових юридично обов’язкових Ордерів до усунення порушення, не вирішуючи спір по суті.

7.11. Після укладення Угоди / Business її істотні умови можуть бути змінені лише шляхом Акцепту структурованого запиту на зміну або підписання двостороннього документа. Мовчання, сплив таймера чи продовження користування не є Акцептом зміни.

7.12. Застосування заздалегідь погодженої формули автоматичного перерахунку ціни або кількості за результатом визначеної лабораторії, параметрами якості, шкалою знижок чи премій, допусками та правилами округлення не є зміною Угоди / Business і не потребує нового Акцепту, якщо формула, джерело даних і правила розрахунку були визначені до Акцепту. Будь-яке інше відхилення від погоджених умов потребує окремого Акцепту.

7.13. Після укладення Угоди / Business Оператор Платформи, якщо він не є її стороною та не має окремих повноважень, не може в односторонньому порядку змінити або припинити її. Оператор може зафіксувати спір, зберегти й надати доступні системні докази, обмежити створення нових операцій або виконати законну вимогу компетентного органу; такі заходи самі по собі не припиняють зобов’язань сторін.

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

7.15. Юридичні наслідки Ставки залежать від типу та правової кваліфікації відповідного Аукціону чи Тендера й відображаються учасникам до подання Ставки. Якщо електронна процедура є аукціоном, що регулюється статтею 99 Цивільного кодексу Єгипту, відповідний договір укладається лише в момент остаточного присудження, а попередня Ставка втрачає чинність у разі подання вищої Ставки у спосіб, передбачений цією статтею. В інших Аукціонах чи Тендерах правила, відображені до участі, визначають, чи є Ставка обов’язковою офертою, чи визначення переможця автоматично формує Угоду / Business, чи результат використовується для створення Безвідзивного ордера або Зустрічного ордера, що потребує Акцепту.

7.16. Активуючи Автоматичну ставку, Користувач визначає граничну ціну, крок ставки та тривалість. Ставки, автоматично подані Платформою в межах цих параметрів, відносяться до Користувача й мають юридичні наслідки, надані Ставкам правилами відповідного Аукціону та застосовним правом. У процедурі, що регулюється статтею 99 Цивільного кодексу Єгипту, Автоматична ставка не змінює законодавчих наслідків вищої Ставки та вимоги про остаточне присудження. Зміна параметрів Автоматичної ставки не змінює ретроспективно вже поданих Ставок.

7.17. Істотні умови не можуть змінюватися після початку Аукціону. Якщо їх потрібно змінити, поточний Аукціон припиняється, створюється нова редакція, а попередні Ставки не переносяться без окремого підтвердження.

7.18. Шаблон Контракту, стандартна форма, автоматичне формування документа чи технічна перевірка його заповнення не є індивідуалізованою юридичною, податковою чи іншою професійною консультацією. Сторони самостійно оцінюють, чи є обрана форма, правила та умови належними для відповідної операції, і за необхідності залучають професійних консультантів.

7.19. Угода / Business, Контракт, Аукціон чи Тендер щодо сільськогосподарської або харчової продукції, імпорту чи експорту, митних, карантинних питань, безпечності харчових продуктів, реєстрації продукції, контролю якості або інших регульованих товарних питань у Єгипті залишаються предметом усіх імперативних галузевих законів, підзаконних актів, дозволів, реєстрацій і рішень Єгипту, застосовних до такої операції. Платформа не вважається такою, що підтверджує регуляторну допустимість, лише через те, що технічно дозволяє створити Ордер чи Угоду / Business. Сторони самостійно залишаються відповідальними за отримання ліцензій, реєстрацій, погоджень, сертифікатів та інших документів, необхідних для їхньої операції, якщо конкретне Замовлення прямо не покладає визначене комплаєнс-завдання на Виконавця послуги, який має на це законне право. Імперативні норми мають переважну силу над механікою Платформи в частині будь-якої суперечності.

8. Заявки на послугу, Замовлення, Номінації та ролі INBULK

8.1. Користувач може створювати Заявки на послугу щодо логістичних, перевізних, транспортно-експедиторських, сюрвейєрських, лабораторних, фумігаційних, інформаційних послуг, послуг із пошуку та супроводження фінансування й інших фактично доступних на Платформі послуг. Агентські послуги, комерційне посередництво, страхове посередництво чи інша регульована послуга можуть бути доступні в Єгипті лише тоді, коли конкретний Виконавець послуги має законне право, реєстрацію або ліцензію для виконання такої ролі й виконані відповідні регуляторні умови.

8.2. Подання Заявки на послугу є Юридично значущою дією. До подання Платформа відображає Користувачу юридичні наслідки обраного режиму. Подання дозволяє обробку Заявки на послугу, передання необхідних даних потенційним або визначеним Виконавцям послуги, пошук чи добір за визначеними параметрами та — якщо Заявка на послугу не вимагає остаточного підтвердження Користувачем — формування Замовлення без повторного підтвердження в межах таких параметрів.

8.3. Заявка на послугу має містити або дозволяти однозначно визначити: вид, предмет, обсяг і результат послуги; місце й строки; конкретного Виконавця послуги або критерії та порядок його визначення; фіксовану, максимальну чи орієнтовну ціну; валюту, Платника та отримувача платежу; необхідні документи; строк дії Заявки на послугу; чи допускається часткове виконання та максимальну кількість або обсяг Замовлень; застосовні Спеціальні умови; Режим виконання послуги; а також чи потребують Виконавець послуги або сформоване Замовлення остаточного підтвердження Користувачем.

8.4. Якщо Заявка на послугу не містить вказівки про необхідність остаточного підтвердження Користувачем, Замовлення формується без повторного підтвердження Користувачем у момент, коли відповідна подія формування зафіксована Платформою, а відповідне Підтвердження прийняття Заявки на послугу стає доступним Користувачу-заявнику через погоджений канал Платформи. Такою подією формування може бути: (1) прийняття Заявки на послугу визначеним або дібраним Виконавцем послуги без відхилення від її параметрів; (2) прийняття Заявки на послугу автоматизованим сервісом на заздалегідь відображених умовах; або (3) інша подія, прямо визначена до подання Заявки на послугу. Запис Платформи, позначка часу, ідентифікатор події та пов’язані докази можуть використовуватися для встановлення моменту, коли підтвердження стало доступним Користувачу-заявнику. Зазначення конкретного Виконавця послуги підтверджує адресний і конкретний характер наміру Користувача; проте пряма вказівка про необхідність остаточного підтвердження має переважну силу.

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

8.6. Якщо Заявка на послугу передбачає, що Виконавець послуги або остаточні умови потребують підтвердження Користувачем, відповідь Виконавця послуги на Заявку або її прийняття мають суто переговорний характер і не формують Замовлення до окремого Акцепту Користувачем. Це застосовується й тоді, коли визначено конкретного Виконавця послуги.

8.7. Користувач, який бажає оприлюднити або надіслати повідомлення про потребу в послугах без юридичних наслідків, створює Ордер на послуги зі статусом «Індикативний» / Soft. Такий Ордер може бути оприлюднений загально або надісланий конкретному Користувачу, не дозволяє автоматичного формування Замовлення й використовується для отримання пропозицій і проведення переговорів. Для формування Замовлення Користувач подає Заявку на послугу або окремо Акцептує остаточні умови.

8.8. До формування Замовлення Користувач може відкликати або змінити Заявку на послугу, якщо вона прямо не визначена як безвідклична. Відкликання або зміна набирають чинності в момент їх фіксації Платформою й не припиняють Замовлення, сформованого раніше на підставі такої Заявки на послугу.

8.9. У Заявці на послугу Користувач обирає Режим виконання послуги: з додатковим забезпеченням виконання або без нього. У режимі з додатковим забезпеченням виконання Користувач може прямо вимагати страхування, ескроу, Забезпечення виконання, документарних розрахунків, перевірки документів, моніторингу чи іншої фактично доступної послуги. У режимі без додаткового забезпечення виконання Користувач погоджується, що Замовлення може бути сформоване й виконане без таких додаткових інструментів.

8.10. Якщо додаткове забезпечення визначене в Заявці на послугу як обов’язкова умова, Замовлення не формується або його виконання не розпочинається до належного оформлення чи підтвердження відповідного інструмента, якщо Користувач прямо не погодив інше. Недоступність обраної послуги не переводить Заявку на послугу автоматично в режим без додаткового забезпечення. Позначення режиму як «гарантованого» не є гарантією виконання з боку Оператора Платформи чи INBULK; обсяг захисту визначається відповідним договором, полісом, гарантією, ескроу-домовленістю або іншим конкретним інструментом.

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

8.12. До вчинення Юридично значущої дії, яка формує Замовлення, чітко визначаються конкретна юридична особа та її точна роль. У Єгипті INBULK.COM LLC за замовчуванням діє виключно як Оператор Платформи та постачальник технології. Особа Групи INBULK може діяти як безпосередній Виконавець послуги або організатор послуги лише тоді, коли така роль є юридично доступною та прямо зазначена. Вона може діяти як комерційний агент, комерційний посередник, представник чи інший регульований посередник лише після виконання застосовних вимог Закону Єгипту № 120 від 1982 року та інших імперативних норм права Єгипту, у тому числі будь-якої необхідної реєстрації в GOEIC, ліцензування, відповідності кваліфікаційним вимогам чи документального оформлення. Роль, обсяг повноважень, винагорода, Платник, отримувач платежу та відповідальність визначаються окремо. Приєднання до цього Договору саме по собі не надає представницьких повноважень і не встановлює відносин комерційного агентування чи комерційного посередництва.

8.13. Якщо конкретно визначена особа INBULK є безпосереднім Виконавцем послуги, вона відповідає за послугу, яку прямо взяла на себе. Якщо вона правомірно діє в агентській, посередницькій, транспортно-експедиторській, представницькій чи іншій регульованій ролі, її повноваження, винагорода, відповідальність і регуляторний статус регулюються відповідним Замовленням, будь-яким окремим необхідним договором та імперативними нормами права Єгипту. До виконання цих умов добір, пошук, ранжування, обмін документами, координація комунікацій і подібний функціонал Платформи залишаються технічними або організаційними послугами й не можуть тлумачитися як регульоване комерційне агентування чи посередництво.

8.14. Повноваження INBULK підписувати документи, погоджувати ціни, зобов’язувати Користувача, розпоряджатися товаром, товаророзпорядчими документами чи коштами, подавати регуляторну звітність або в інший спосіб представляти Користувача виникають лише тоді, коли вони прямо надані в конкретному законному Замовленні, довіреності чи окремому договорі та коли виконано будь-яку застосовну в Єгипті формальність щодо реєстрації, нотаріального посвідчення, легалізації, ліцензування чи іншу. Пошук, ранжування, добір або автоматичне передання за параметрами Користувача самі по собі не створюють представницьких повноважень і не є гарантією виконання.

8.15. Після формування Замовлення його істотні умови можуть бути змінені лише за взаємною згодою. Скасування не звільняє сторону від оплати фактично наданих послуг, погодженої винагороди та задокументованих витрат.

8.16. Виконавець послуги або конкретно визначена юридична особа INBULK може відмовитися прийняти Заявку на послугу чи Замовлення або зупинити виконання, якщо Користувач не надав необхідних документів, даних, повноважень чи погодженої оплати; інструкції є неповними, суперечливими або незаконними; виник санкційний, шахрайський чи інший істотний ризик; або виконання стало неможливим. Про такий захід Користувача повідомляють, якщо повідомлення не заборонене законом. Припинення або зупинення не скасовує оплати фактично наданих послуг, погодженої винагороди чи підтверджених витрат.

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

8.18. Номінація — це визначення Користувачем Виконавця послуги, обраного Користувачем самостійно. Вона не є Замовленням INBULK, не створює агентських відносин, не робить Оператора стороною договору з номінованим Виконавцем послуги й не вважається прийнятою мовчанням.

8.19. Платформа може передавати Номінацію, документи та статуси, але Користувач самостійно відповідає за вибір номінованого Виконавця послуги, укладення з ним договору та достовірність даних.

9. Сервіси супроводження розрахунків, плата та платежі

9.1. Користувач може використовувати Сервіси супроводження розрахунків, сервіси пошуку та супроводження фінансування й інші фактично доступні на Платформі сервіси. Конкретний перелік не закріплений цим Договором і визначається доступним функціоналом, умовами операції та документами відповідних Сторонніх постачальників.

9.2. Сервіси супроводження розрахунків і сервіси супроводження фінансування є, за загальним правилом, інформаційно-технологічними та організаційними послугами. Оператор не отримує, не зберігає, не резервує та не переказує кошти Користувачів, не відкриває рахунків, не здійснює банківської чи страхової діяльності, не видає гарантій, не відкриває та не виконує Акредитива, не надає кредиту, позики, факторингу чи іншого фінансування й не приймає рішень про фінансування або платежі, якщо відповідна роль конкретної юридичної особи не оформлена прямо через окрему законну структуру, договір і регуляторний статус, якого вимагає право Єгипту.

9.3. Регульовану платіжну, банківську, страхову, фінансову та іншу фінансову діяльність щодо Єгипту здійснюють виключно відповідний банк, Ескроу-агент, Емітент Забезпечення, Страховик, фінансуюча установа чи інший належно уповноважений постачальник. Жодна позначка в інтерфейсі, статус, робочий процес чи шаблон не може тлумачитися як твердження про те, що INBULK.COM LLC має ліцензію Центрального банку Єгипту, Управління фінансового регулювання чи іншого єгипетського регулятора, якщо такий статус прямо не зазначений і не підтверджений для відповідної юридичної особи та послуги.

9.4. До подання Заявки на послугу, що дозволяє автоматичне формування платного Замовлення, або до окремого Акцепту Користувачу показуються дані та роль постачальника, повна ціна або спосіб її визначення, винагорода Агента, витрати третіх осіб, податки, Платник, отримувач, валюта, строк і порядок оплати, а також умови зміни, скасування та повернення коштів.

9.5. Оператор може запроваджувати та змінювати тарифи за доступ і власні послуги, попередньо повідомивши Користувача. Нові або змінені тарифи застосовуються лише до послуг, Заявок на послугу чи операцій, ініційованих після набрання ними чинності, і не змінюють ціни вже укладеної Угоди / Business чи вже сформованого Замовлення без окремого Акцепту відповідними сторонами.

9.6. Рахунок, розрахунковий документ чи платіжна інструкція не змінюють погоджених умов і самі по собі не є підтвердженням оплати. Грошове зобов’язання вважається виконаним у момент зарахування коштів належному отримувачу, якщо сторони дійсно не погодили інше або імперативні норми права не встановлюють іншого правила. Будь-які договірні проценти, штраф за прострочення, сума стягнення чи заздалегідь погоджена компенсація підпорядковуються імперативним нормам права Єгипту. Якщо до простроченого комерційного боргу застосовується стаття 64 Комерційного кодексу Єгипту (Закон № 17 від 1999 року), нарахування та розмір процентів і будь-яке застосовне законодавче обмеження загальної суми процентів, що підлягають стягненню, визначаються відповідно до цієї статті та інших імперативних застосовних норм. Якщо компенсація визначена заздалегідь, імперативні повноваження суду чи арбітражу, застосовні за статтею 224 Цивільного кодексу Єгипту, залишаються чинними. Якщо вимагається повідомлення про прострочення, застосовуються відповідні правила повідомлення та будь-яка дійсна домовленість про автоматичне прострочення відповідно до пп. 15.1 і 15.2.

9.7. Статус «Оплачено», «Платіж відправлено» чи подібний не є остаточним доказом виконання грошового зобов’язання, якщо він не ґрунтується на підтвердженні банку або належно уповноваженого надавача платіжних послуг. Рахунок може відображати санкцію чи іншу суму, розраховану за умовами, погодженими до порушення, або таку, що виникає безпосередньо із застосовного права, але сам по собі не може встановлювати нової неустойки, процентів, плати за скасування чи іншої санкції.

9.8. Платіж Оператору, Агенту чи іншій особі INBULK погашає зобов’язання перед третьою особою лише тоді, коли така особа прямо визначена як кредитор або уповноважений отримувач.

9.9. Зміна банківських реквізитів автоматично не змінює банківських реквізитів у вже укладених Угоді / Business, Контракті, Замовленні, виставленому рахунку чи платіжній інструкції.

9.10. Сама лише наявність у розділі 2 визначень щодо ескроу, Забезпечення виконання, Акредитивів, страхування чи фінансування не означає, що відповідний сервіс запущено. Такий сервіс застосовується лише тоді, коли він фактично доступний у відповідному регіоні, Сторонній постачальник або конкретна юридична особа INBULK та її роль розкриті, Спеціальні умови надані, а Користувач вчинив необхідну Юридично значущу дію.

9.11. До вчинення Юридично значущої дії щодо відповідного сервісу Користувачу показуються сторони та їх ролі, сума, валюта, тарифи, комісії, строки, документи, умови відкриття, видачі, використання, вивільнення коштів або платежу, порядок повернення коштів, забезпечення, порядок дій у разі невиконання та оскарження, відповідальність, застосовне право, порядок вирішення спорів, наслідки неплатоспроможності залученої особи та правила обробки даних.

9.11.1. Сервіс ескроу-розрахунків

Платформа може забезпечувати ініціювання відкриття Рахунку ескроу, погодження та фіксацію Умов вивільнення, формування й передання Тригерних документів, обмін повідомленнями та відображення статусів. Рішення про відкриття рахунку, прийнятність документів і переказ коштів приймає виключно Ескроу-агент. INBULK не є власником Рахунку ескроу, вигодонабувачем або особою, уповноваженою розпоряджатися коштами, якщо інше не встановлено через окрему законну структуру.

9.11.2. Сервіс забезпечення виконання

Платформа може забезпечувати погодження Умов Забезпечення, завантаження документів, відстеження строків і підготовку чернеток вимог. Емітент Забезпечення самостійно видає, підтверджує, змінює та припиняє Забезпечення й приймає рішення щодо будь-якої Вимоги. INBULK не підтверджує дійсність Забезпечення, платоспроможність чи повноваження Емітента Забезпечення без окремо замовленої перевірки та не гарантує виплати.

9.11.3. Сервіс документарних розрахунків

Платформа може забезпечувати погодження та фіксацію Умов акредитива, формування чернеток документів, обмін документами, відстеження строків і отримання повідомлень. Банк-емітент та інші залучені банки самостійно відкривають, авізують, підтверджують і виконують Акредитив, перевіряють Презентацію, визначають Розбіжності та приймають рішення про здійснення чи відмову в платежі. INBULK не здійснює банківської перевірки документів у розумінні UCP, eUCP чи ISP98.

9.11.4. Сервіс супроводження страхування

Платформа може забезпечувати фіксацію Умов страхування, зберігання полісів і сертифікатів, відстеження строків повідомлення та подання Заяви про виплату й формування чернеток документів. Страховик самостійно оцінює ризик, визначає покриття, видає страховий документ, визначає настання страхового випадку та приймає рішення про виплату. Користувач або Вигодонабувач за полісом самостійно подає Заяву про виплату, якщо інше прямо не передбачено окремими агентськими повноваженнями; INBULK не гарантує страхової виплати.

9.11.5. Сервіс пошуку, організації та супроводження фінансування

Для цілей цього розділу «Фінансуючий партнер» означає банк, фінансову установу, фонд, інвестиційну чи торгову компанію, покупця, продавця, компанію спеціального призначення або іншу особу, яка за застосовним правом має право надавати відповідну форму фінансування.

Платформа або конкретно визначена юридична особа INBULK може забезпечувати підготовку Запиту на фінансування, збір і структурування документів, пошук і добір для Користувача потенційних Фінансуючих партнерів, передання Запиту на фінансування й документів за дозволом Користувача, координацію комунікацій, відображення індикативних пропозицій, документообіг і відстеження статусів. Такий сервіс сам по собі не є фінансовою консультацією, схваленням фінансування, гарантією отримання фінансування або обов’язком будь-якої особи надати кошти.

Фінансуючий партнер самостійно проводить KYC/KYB, кредитний, юридичний і фінансовий аналіз, визначає допустиму структуру, суму, валюту, строк, ціну, забезпечення та інші умови й може відмовити у фінансуванні або змінити індикативні умови до укладення окремого договору. Будь-який рейтинг, скоринг, прогноз чи рекомендація Платформи мають суто інформаційний характер і не гарантують рішення Фінансуючого партнера.

Безпосереднє надання фінансування конкретною юридичною особою INBULK або Стороннім постачальником допускається лише після того, як таку особу прямо визначено як кредитора, сторону фінансування чи іншого належного учасника, встановлено її право здійснювати відповідну діяльність і укладено окремий договір фінансування. До надання коштів такий договір має визначати суму, валюту, строк, мету, проценти, дисконт, комісії та іншу сукупну вартість, умови вибірки й повернення, дострокове повернення, забезпечення, випадки невиконання, податки, застосовне право та порядок вирішення спорів.

Кошти фінансування переказуються безпосередньо Фінансуючим партнером Користувачу, продавцю, постачальнику, Виконавцю послуги чи іншому прямо визначеному отримувачу через належні банківські або платіжні канали. Оператор Платформи не отримує, не зберігає та не переказує такі кошти, якщо для цього не створено окрему законну структуру з необхідним статусом і договірною базою.

10. Сторонні постачальники, зовнішні дані та безперервність

10.1. Оператор може інтегрувати сервіси банків, надавачів платіжних послуг, страховиків, перевізників, лабораторій, реєстрів, провайдерів KYC/KYB, провайдерів електронного підпису, провайдерів зв’язку, постачальників хмарної інфраструктури та інших Сторонніх постачальників, доступних на Платформі.

10.2. Умови Стороннього постачальника застосовуються, якщо вони надані до вчинення відповідної Юридично значущої дії та вимагається окреме прийняття таких умов. Інтеграція не означає, що Оператор контролює постачальника або гарантує його рішення.

10.3. Дані із зовнішніх реєстрів і сервісів відображаються в доступному обсязі й не замінюють офіційного документа або самостійної перевірки. Оператор не гарантує абсолютної повноти чи актуальності даних із незалежного джерела, але залишається відповідальним за власне винне спотворення або неправильне передання таких даних.

10.4. Якщо зовнішній сервіс недоступний, незавершена операція не може відображатися як успішна. За технічної можливості Платформа повідомляє Користувача про недоступність, зберігає статус і час спроби та надає можливість повторити спробу або скористатися доступним альтернативним способом. Повторна спроба не створює дубльованого юридичного чи платіжного наслідку.

10.5. Дані передаються Сторонньому постачальнику лише в обсязі, необхідному для відповідної послуги, операції, безпеки, комплаєнсу чи виконання юридичних обов’язків, відповідно до Політики конфіденційності та, за необхідності, договору про обробку персональних даних (DPA).

11. Права, обов’язки та заходи реагування

11.1. Користувач має право користуватися фактично доступним функціоналом, отримувати документи та інформацію, керувати своїми Авторизованими користувачами, створювати й Акцептувати Ордери, укладати Угоди / Business, підписувати Контракти, формувати Замовлення та користуватися іншими доступними сервісами.

11.2. Користувач зобов’язаний:

дотримуватися застосовного права, цього Договору, застосовних Правил і прийнятих умов конкретних операцій;

надавати достовірну та актуальну інформацію й забезпечувати її законне отримання;

забезпечувати наявність належних повноважень в Авторизованих користувачів і Підписантів;

не створювати фіктивних Ордерів, Заявок на послугу, Номінацій, облікових записів чи іншої інформації, що вводить в оману;

не використовувати Платформу для шахрайства, обходу санкцій, відмивання коштів, порушення прав третіх осіб чи іншої незаконної діяльності;

належно виконувати Угоди / Business, Контракти та Замовлення;

самостійно виконувати податкові, митні, валютні, санкційні, ліцензійні та інші обов’язки;

захищати засоби доступу та своєчасно скасовувати Права.

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

11.4. Оператор може запитувати документи, змінювати й розвивати функціонал, проводити технічне обслуговування, обмежувати окремі дії, зупиняти або блокувати Обліковий запис Користувача-компанії, приховувати незаконний контент, змінювати Статус акредитації та виконувати законні вимоги компетентних органів.

11.5. Заходи мають бути пропорційними ризику. Якщо це не заборонено законом або міркуваннями безпеки, Користувача повідомляють про підстави та доступний порядок оскарження чи заперечення.

11.6. Блокування не припиняє вже укладених Угод / Business, Контрактів чи Замовлень. Користувач зберігає доступ до документів, розрахунків, претензій і дій, необхідних для завершення відкритих операцій, якщо законом не встановлено інше.

12. Персональні дані, конфіденційність, інтелектуальна власність та ШІ

12.1. Політика конфіденційності є окремим повідомленням про прозорість. У обсязі, застосовному до обробки, пов’язаної з Користувачами-компаніями, Авторизованими користувачами, представниками, водіями чи іншими фізичними особами в Єгипті, застосовуються Закон Єгипту про захист персональних даних № 151 від 2020 року, Виконавчий регламент до нього № 816 від 2025 року, рішення та роз’яснення Єгипетського центру захисту персональних даних (PDPC) та інше застосовне законодавство Єгипту про захист даних. Користувач-компанія забезпечує наявність правової підстави для надання персональних даних Платформі та надає необхідні повідомлення своєму персоналу й іншим суб’єктам даних.

12.2. Сторони визначають свої ролі контролера, оператора обробки, володільця даних та інші ролі щодо кожної операції обробки відповідно до фактичних цілей і засобів обробки та застосовного права Єгипту. Якщо INBULK обробляє персональні дані за задокументованими інструкціями Користувача-компанії, застосовуються необхідні умови обробки даних. Якщо відповідна особа INBULK визначає цілі безпеки, Акредитації, Верифікації, санкційних/комплаєнс-перевірок, запобігання шахрайству, збереження доказів, захисту прав або виконання юридичних обов’язків, вона може діяти як самостійний контролер. Кожна Сторона дотримується застосовних вимог щодо призначення/реєстрації відповідальної особи із захисту даних (DPO), ліцензій чи дозволів, місцевого представництва, якщо воно вимагається, заходів безпеки, прав суб’єктів даних, строків зберігання та транскордонного передання. Персональні дані не передаються за межі Єгипту, доки не встановлені правова підстава, місце призначення, гарантії та будь-яка необхідна ліцензія чи дозвіл PDPC. Єгипетське повідомлення Платформи про приватність надається арабською мовою як основною, якщо цього вимагають роз’яснення PDPC, з версіями іншими мовами за потреби.

12.3. Сторони використовують Конфіденційну інформацію лише для цілей цього Договору та відповідних операцій, розкривають її лише особам, яким вона необхідна, і застосовують розумні заходи захисту. Обов’язок конфіденційності діє протягом строку дії Договору та три роки після його припинення, а щодо комерційної таємниці та інформації, яка підлягає спеціальному режиму охорони, — доти, доки така охорона діє.

12.4. Обов’язок конфіденційності не поширюється на інформацію, яка правомірно стала загальнодоступною; правомірно перебувала у володінні одержувача до розкриття; правомірно отримана від третьої особи без обов’язку конфіденційності; розроблена самостійно без використання розкритої інформації; або підлягає розкриттю за законом, рішенням суду чи законною вимогою компетентного органу. Якщо розкриття є обов’язковим, одержувач, якщо це не заборонено, завчасно повідомляє відповідну сторону й обмежує розкриття мінімально необхідним обсягом.

12.5. Оператор має права, достатні для експлуатації Платформи. Користувачу надається обмежене, невиключне й непередаване право використовувати її для власної господарської діяльності. Права на програмне забезпечення, бренд, дизайн, бази даних чи документацію не передаються.

12.6. Користувач зберігає права на свої документи та дані й надає Оператору право технічно обробляти, зберігати та передавати їх в обсязі, необхідному для роботи Платформи, операцій, безпеки, комплаєнсу та виконання юридичних обов’язків.

12.7. ШІ-асистент формує інформацію та чернетки, але не може самостійно створити Юридично значущу дію. Його результат набуває юридичного значення лише після окремої перевірки та підтвердження належно уповноваженим Авторизованим користувачем.

12.8. Провайдери ШІ, правила використання даних, строки зберігання, заборонені категорії інформації, вимоги щодо людського контролю та інші обмеження, застосовні до ШІ-функцій, регулюються Правилами користування Платформою, застосовною Політикою використання ШІ, Політикою конфіденційності та, за релевантності, умовами конкретного ШІ-сервісу чи провайдера, наданими до використання. Користувач не повинен вводити дані, розкриття яких не дозволене або не є необхідним для відповідної функції.

13. Відповідальність і форс-мажор

13.1. Кожна Сторона відповідає за власні винні дії та за неналежне виконання зобов’язань, прямо взятих нею за цим Договором. Відповідальність конкретної юридичної особи INBULK, яка діє в іншій ролі, регулюється відповідною Угодою / Business, Контрактом, Замовленням, Спеціальними умовами та імперативними нормами права.

13.2. Користувач відповідає за своїх Авторизованих користувачів, надані їм Права, засоби доступу, достовірність даних, законність інструкцій, законність товару й коштів і своєчасне припинення доступу.

13.3. Якщо Оператор діє виключно як оператор цифрового середовища, він не відповідає за виконання контрагентом, якість товару, результат незалежного Виконавця послуги, рішення банку, Ескроу-агента, Емітента Забезпечення, Страховика, реєстру чи іншого Стороннього постачальника, а також за комерційну доцільність операції. Вибір Користувачем режиму з додатковим забезпеченням або без нього не змінює такого розподілу відповідальності; права за конкретним інструментом визначаються умовами цього інструмента.

13.4. Оператор відповідає за власне винне невиконання, неправомірну зміну або втрату даних, некоректну інтеграцію чи передання інструкцій, перевищення своїх повноважень, а також за порушення конфіденційності, інформаційної безпеки чи захисту персональних даних у межах застосовного права.

13.5. З урахуванням п. 13.7 та імперативних норм застосовного права відшкодуванню підлягають лише прямі задокументовані збитки, що мають прямий причинний зв’язок із порушенням. Оператор не відповідає за упущену вигоду, ринкові коливання, втрату фінансування, втрату комерційної можливості чи інші непрямі збитки, якщо таке виключення дозволене застосовним правом.

13.6. З урахуванням п. 13.7 та імперативних норм застосовного права сукупна відповідальність Оператора Платформи, коли він діє виключно як оператор Платформи, за вимогами одного Користувача протягом будь-якого дванадцятимісячного періоду не перевищує суми плати, фактично сплаченої таким Користувачем Оператору за безпосередньо пов’язану послугу за попередні дванадцять місяців. Щодо безоплатного функціоналу сукупна відповідальність не перевищує 100 000 (сто тисяч) гривень або еквівалент у євро, розрахований за офіційним курсом Національного банку України на дату настання події, що стала підставою відповідної вимоги. Окремий ліміт відповідальності для іншої ролі INBULK може бути встановлений у прийнятих умовах відповідної послуги.

13.7. Виключення та обмеження відповідальності, встановлені цим Договором, не застосовуються в обсязі, забороненому імперативними нормами права Єгипту, у тому числі щодо відповідальності, яка виникає з власного шахрайства або грубої необережності Сторони, чи відповідальності за неправомірні дії, коли договірне виключення є недійсним, а також щодо будь-якої іншої відповідальності, яку не можна законно виключити або обмежити. Ніщо в цьому Договорі не обмежує імперативних повноважень суду чи арбітражу коригувати компенсацію, якщо цього вимагає застосовне право.

13.8. Сторона звільняється від відповідальності в обсязі, у якому доведе, що невиконання було безпосередньо спричинене зовнішньою причиною поза її контролем, у тому числі форс-мажорною обставиною, якої не можна було розумно уникнути і яка об’єктивно унеможливила виконання, з урахуванням статей 165, 215 та інших застосовних положень Цивільного кодексу Єгипту й умов конкретної операції. Саме лише зростання витрат, погіршення ринкової кон’юнктури чи економічні труднощі не є неможливістю, без шкоди для режиму надмірної обтяжливості, передбаченого п. 13.11.

13.9. Обставина, яка існувала й була відома або за розумних обставин мала бути відома Стороні на момент прийняття нею зобов’язання, сама по собі не є Форс-мажором. Нові та непередбачувані наслідки загальновідомої ситуації можуть бути Форс-мажором лише тоді, коли вони виникли після прийняття зобов’язання, не могли бути розумно враховані й безпосередньо унеможливили виконання.

13.10. Сторона повідомляє іншу Сторону про Форс-мажор без невиправданої затримки, надає доступні докази та вживає заходів для зменшення наслідків. Форс-мажор автоматично не припиняє зобов’язань і не звільняє Сторону від платіжних зобов’язань, строк виконання яких настав до його виникнення.

13.11. Виняткові обставини / надмірна обтяжливість. Ніщо в цьому Договорі не виключає та не обмежує імперативної дії статті 147(2) Цивільного кодексу Єгипту. Якщо після прийняття зобов’язання виникають виняткові та непередбачувані події загального характеру, які, не роблячи виконання неможливим, роблять його надмірно обтяжливим настільки, що загрожують боржнику надмірними втратами, засоби правового захисту та повноваження, передбачені цією статтею, залишаються чинними. Сторони, коли це практично можливо, спершу добросовісно намагаються обговорити розумне коригування, без шкоди для повноважень компетентного суду чи арбітражу застосувати імперативні норми права Єгипту.

13.12. Погоджена компенсація. Будь-які заздалегідь визначені Сторонами збитки, неустойка, сума за скасування чи інша компенсація підпорядковуються імперативним нормам права Єгипту, у тому числі статті 224 Цивільного кодексу Єгипту. Зокрема, боржник зберігає будь-яке імперативне право довести, що шкоди не завдано, що погоджена сума є надмірно завищеною або що основне зобов’язання виконано частково, а будь-які імперативні повноваження компетентного суду чи арбітражу зменшити погоджену суму або відмовити в її стягненні залишаються чинними.

14. Строк дії, зміни, припинення та закриття Облікового запису Користувача-компанії

14.1. Договір набирає чинності в момент, визначений п. 1.3, і укладається на невизначений строк.

14.2. Користувач може ініціювати припинення через доступний функціонал або перевірений канал. Оператор перевіряє повноваження заявника та повідомляє Користувача про відкриті Угоди / Business, Контракти, Замовлення, платежі та претензії.

14.3. Після підтвердження запиту Обліковому запису Користувача-компанії може бути надано статус «Закривається». У цьому статусі створення нових операцій може бути заблоковане, але Користувач зберігає доступ до документів, розрахунків, претензій і дій, необхідних для завершення, припинення чи належного передання відкритих зобов’язань, і може отримати та експортувати доступні документи й дані.

14.4. Остаточне закриття Облікового запису Користувача-компанії відбувається після завершення, припинення або належного передання відкритих операцій і врегулювання непогашених зобов’язань, якщо інше не вимагається законом, санкційними обмеженнями чи заходами безпеки.

14.5. Оператор може припинити Договір за відсутності порушення з боку Користувача, повідомивши про це не менш ніж за 30 календарних днів, якщо застосовне право не встановлює іншого обов’язкового строку повідомлення. Негайне обмеження або припинення допускається у разі істотного порушення, шахрайства, санкційного ризику, компрометації засобів доступу, загрози безпеці чи вимоги закону.

14.6. Припинення, блокування чи закриття не скасовує вже чинних Угод / Business, Контрактів, Замовлень, домовленостей про фінансове забезпечення, розрахунків, обов’язків конфіденційності, положень про відповідальність або положень про вирішення спорів.

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

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

14.9. До прийняття нової редакції Оператор може обмежити створення нових операцій, зберігаючи доступ до відкритих зобов’язань. Нова редакція не змінює раніше укладених операцій без згоди їх сторін або імперативної вимоги закону.

14.10. Істотні зміни до Правил застосовуються на майбутнє до нових операцій після оприлюднення, будь-якого повідомлення, якого вимагають цей Договір або застосовне право, і, за необхідності, прямого прийняття. Технічні, редакційні та організаційні зміни можуть застосовуватися після оприлюднення та будь-якого повідомлення, якого вимагають цей Договір або застосовне право. Правила не змінюють раніше укладених операцій.

15. Повідомлення, застосовне право, спори та реквізити

15.1. Звичайні операційні та договірні повідомлення можуть надсилатися через Обліковий запис Користувача-компанії, перевірену адресу електронної пошти чи інший погоджений електронний канал, а Платформа може зберігати системні докази передання та доступності. Якщо право Єгипту, характер зобов’язання або відповідна операція вимагають формального повідомлення, вимоги чи попередження, Сторона, яка на нього посилається, використовує юридично достатній спосіб, який може включати офіційне попередження, рекомендований лист із повідомленням про вручення, кур’єрську доставку чи інший спосіб, дозволений застосовним правом Єгипту. У невідкладних комерційних питаннях може також використовуватися будь-який швидкий спосіб зв’язку, дозволений законом. Сповіщення Платформи не замінює обов’язкового формального повідомлення, якщо застосовне право та домовленість Сторін не допускають такого наслідку.

15.2. Щодо зобов’язань, для яких право Єгипту дозволяє Сторонам домовитися, що боржник вважається таким, що прострочив, автоматично зі спливом строку виконання, остаточні умови відповідної Угоди / Business, Контракту чи Замовлення можуть прямо передбачати, що прострочення настає зі спливом строку без додаткових формальностей. За відсутності такої дійсної домовленості будь-яке повідомлення, необхідне для стягнення збитків, припинення чи примусового виконання, надається юридично достатнім способом. Повідомлення про компрометацію засобів доступу, зміну банківських реквізитів, розпорядження коштами або припинення Договору можуть додатково потребувати посиленої перевірки особи та повноважень.

15.3. Якщо умовами конкретної операції не визначено інше, строки за цією локалізованою редакцією Договору обчислюються за місцевим часом Єгипту (Africa/Cairo). Системні події фіксуються за UTC і можуть додатково відображатися за місцевим часом.

15.4. Цей Договір між Оператором Платформи та Користувачем-компанією регулюється правом Арабської Республіки Єгипет. Такий вибір не впливає на імперативні положення, які застосовуються незалежно від обраного права. Створення, правовий статус, правоздатність, внутрішня організація та корпоративні повноваження кожної Сторони й надалі регулюються правом, застосовним до такої Сторони. Цей пункт не визначає права, що регулює окрему Угоду / Business, Контракт чи Замовлення між Користувачами або з іншою особою Групи INBULK: застосовне право та механізм вирішення спорів щодо такої операції визначаються остаточними умовами, прийнятими для цієї операції, а за відсутності дійсного вибору — застосовними колізійними нормами й імперативними нормами права. Для міжнародної купівлі-продажу товарів остаточні умови операції мають прямо зазначати, чи застосовується Конвенція Організації Об’єднаних Націй про договори міжнародної купівлі-продажу товарів (CISG), чи вона виключається в разі, коли Конвенція інакше підлягала б застосуванню.

15.5. Будь-який спір, розбіжність або вимога, що виникають з цього Договору між Оператором Платформи та Користувачем-компанією або пов’язані з ним, у тому числі щодо його тлумачення, виконання, порушення, припинення, дійсності чи дійсності арбітражної угоди, в обсязі, у якому їх предмет може бути законно врегульований арбітражем за правом Єгипту, спершу врегульовуються шляхом письмової або електронної претензії. Якщо їх не врегульовано протягом 15 (п’ятнадцяти) Робочих днів після отримання претензії, вони остаточно вирішуються арбітражем відповідно до Арбітражного регламенту Каїрського регіонального центру міжнародного комерційного арбітражу (CRCICA), чинного на дату початку арбітражу. Місцем (юридичним місцем) арбітражу є Каїр, Арабська Республіка Єгипет. Склад арбітражу — один арбітр, якщо Сторони згодом не домовляться про інше або застосовний Регламент CRCICA не вимагає іншого складу. Мова арбітражу — англійська, без шкоди для повноважень складу арбітражу вимагати переклади арабською, якщо це необхідно. Матеріальним правом, що регулює цей Договір, є право Єгипту відповідно до п. 15.4. Арбітражна угода в цьому пункті має задовольняти вимогу письмової форми, встановлену статтею 12 Закону Єгипту про арбітраж № 27 від 1994 року, і прямо приймається письмово Користувачем-компанією в Заяві про приєднання та прийняття; підписання цього рамкового Договору Оператором і підписана Користувачем-компанією Заява про приєднання та прийняття разом становлять письмову арбітражну угоду. Ніщо в цьому пункті не перешкоджає компетентному суду вживати забезпечувальних або запобіжних заходів, якщо це дозволено застосовним правом.

15.6. Спори між Користувачами вирішуються відповідно до Угоди / Business, Контракту чи Замовлення. Оператор не є стороною такого спору лише через те, що використовувалася Платформа, але може надати доступні системні записи в обсязі, дозволеному законом.

15.7. Недійсність будь-якого положення не впливає на решту Договору. Нездійснення права не є відмовою від нього. Заголовки наведені виключно для зручності.

15.8. Посилання в цьому Договорі на законодавство або нормативний акт означає редакцію, застосовну до відповідних правовідносин, у тому числі зміни та акти, що їх замінюють.

Посилання на Incoterms, GAFTA, FOSFA чи іншу стандартну форму, правила або галузевий стандарт означає лише конкретну редакцію, назву, номер і, за застосовності, дату, прямо визначені в остаточних умовах відповідної Угоди / Business, Контракту чи Замовлення. Подальша зміна такого стандарту або правил не змінює вже укладеної операції без окремої згоди її сторін.

15.9. Цей Договір може бути укладений англійською або арабською мовою. Мовна версія, прямо визначена в Заяві про приєднання та прийняття як «Підписна версія», є переважною договірною версією для відповідної Користувача-компанії з урахуванням імперативних норм права Єгипту. Якщо для цілей подання, регуляторних процедур, суду чи примусового виконання в Єгипті вимагається арабська версія або засвідчений переклад арабською, Сторони надають або використовують таку версію чи переклад відповідно до вимог. Будь-який переклад для зручності, не визначений як Підписна версія, має суто інформаційний характер.

15.10. Ідентифікаційні та контактні дані Оператора Платформи наведені в розділі 16 цього Договору. Чинні платіжні реквізити зазначаються виключно в належно сформованому рахунку, Замовленні або платіжній інструкції.

15.11. Ідентифікаційні дані Користувача-компанії й Підписанта та спосіб приєднання зазначаються в Заяві про приєднання та прийняття й Обліковому записі Користувача-компанії. Подальша зміна профілю сама по собі не змінює цього Договору, раніше укладених Угоди / Business, Контракту чи Замовлення або зафіксованих у них реквізитів. Належно перевірена зміна контактних даних застосовується до майбутніх повідомлень з моменту її перевірки Платформою.

16. Реквізити Сторін

Додаток 1. Заява про приєднання та прийняття

до Рамкового договору про користування Платформою та приєднання до онлайн-платформи INBULK.COM № INBULK-AGR-EG-01 від 4 вересня 2026 року

Поля Заяви заповнюються електронно в момент підписання. Її склад, визначений Договором, відтворено нижче.

1. Відомості про Користувача-компанію

• Повне юридичне найменування
• Організаційно-правова форма
• Країна, номер комерційної реєстрації та податковий номер / номер платника ПДВ (за наявності)
• Місцезнаходження
• Підписант
• Посада / статус
• Підстава повноважень
• Перевірена адреса електронної пошти / електронна адреса для повідомлень

2. Ідентифікація редакції

Редакція Договору: INBULK-AGR-EG-01 від 4 вересня 2026 року

Підписна версія / мова: англійська

• Контрольний ідентифікатор / хеш

Перелік і редакції застосовних договірних та операційних документів разом із повідомленнями про приватність і прозорість, наданими Користувачу-компанії, фіксуються Платформою в момент Підписання. Фіксація або підтвердження інформаційного повідомлення не є згодою, якщо застосовне право вимагає окремої правової підстави або окремої згоди.

3. Прийняття Договору та приєднання до нього

Користувач-компанія підтверджує, що до Підписання йому було надано реальну можливість ознайомитися з повним текстом Договору та договірними документами, прямо включеними шляхом посилання, і що він міг зберегти й відтворити їх. Підписант, діючи від імені Користувача-компанії, підтверджує наявність належних повноважень і прямо приймає Договір у редакції та з контрольним ідентифікатором або хешем, зазначеними вище, та приєднується до нього. Користувач-компанія прямо підтверджує, що Безвідзивний ордер, Зустрічний ордер, Акцепт, Угода / Business, Заявка на послугу, Замовлення, Аукціон, Тендер та інші дії на Платформі можуть мати юридичні наслідки, надані їм Договором і застосовними Правилами. Користувач-компанія також прямо приймає письмово арбітражну угоду, що міститься в п. 15.5, у тому числі арбітраж за Арбітражним регламентом CRCICA, місце арбітражу — Каїр, Єгипет, та англійську як мову арбітражу, для цілей статті 12 Закону Єгипту про арбітраж № 27 від 1994 року, в обсязі, у якому відповідний спір може бути законно врегульований арбітражем за правом Єгипту.

Спосіб підписання: [єгипетський цифровий підпис за Законом № 15/2004 / власноручний підпис / інший юридично достатній спосіб, затверджений для цього сценарію]

• Постачальник цифрового сертифіката / ідентифікатор сертифіката (за застосовності)
• Ідентифікатор цифрового або власноручного підписання Підписанта
• Дата й час

4. Основна Доказова база підписання

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

Щодо єгипетського цифрового підпису Підписання підтверджують дані підпису, сертифікат і запис про перевірку; зображення підпису рукописного вигляду не вимагається. У разі власноручного підписання основними доказами є власноручний підпис і збережені докази особи та повноважень. Електронна печатка компанії є допоміжною і сама по собі не встановлює повноважень Підписанта — фізичної особи.