documentation/locale/uk/LC_MESSAGES/getting_started.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2015-TODAY, Odoo S.A.
# This file is distributed under the same license as the Odoo package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# 
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Odoo 11.0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-09-26 16:07+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Alina Lisnenko <alinasemeniuk1@gmail.com>, 2018\n"
"Language-Team: Ukrainian (https://www.transifex.com/odoo/teams/41243/uk/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: uk\n"
"Plural-Forms: nplurals=4; plural=(n % 1 == 0 && n % 10 == 1 && n % 100 != 11 ? 0 : n % 1 == 0 && n % 10 >= 2 && n % 10 <= 4 && (n % 100 < 12 || n % 100 > 14) ? 1 : n % 1 == 0 && (n % 10 ==0 || (n % 10 >=5 && n % 10 <=9) || (n % 100 >=11 && n % 100 <=14 )) ? 2: 3);\n"

#: ../../getting_started/documentation.rst:5
msgid "Basics of the QuickStart Methodology"
msgstr "Базова методологія швидкого старту"

#: ../../getting_started/documentation.rst:7
msgid ""
"This document summarizes Odoo Online's services, our Success Pack "
"implementation methodology, and best practices to get started with our "
"product."
msgstr ""
"Цей документ підсумовує послуги Odoo Online, методологію впровадження наших "
"Пакетів Послуг та найкращі практичні поради для початку роботи з нашим "
"продуктом."

#: ../../getting_started/documentation.rst:12
msgid "1. The SPoC (*Single Point of Contact*) and the Consultant"
msgstr "1. Єдина контактна особа та консультант"

#: ../../getting_started/documentation.rst:14
msgid ""
"Within the context of your project, it is highly recommended to designate "
"and maintain on both sides (your side and ours) **one and only single person"
" of contact** who will take charge and assume responsibilities regarding the"
" project. He also has to have **the authority** in terms of decision making."
msgstr ""
"В контексті вашого проекту настійно рекомендуємо призначати та підтримувати "
"з обох сторін (з вашої сторони та нашої) **єдину контактну особу**, яка "
"візьме на себе відповідальність за проект. Він також повинен мати "
"**повноваження** щодо прийняття рішень."

#: ../../getting_started/documentation.rst:20
msgid ""
"**The Odoo Consultant ensures the project implementation from A to Z**: From"
" the beginning to the end of the project, he ensures the overall consistency"
" of the implementation in Odoo and shares his expertise in terms of good "
"practices."
msgstr ""
"**Консультант Odoo забезпечує реалізацію проекту від А до Я**: від початку "
"до кінця проекту він забезпечує загальну послідовність впровадження Odoo та "
"ділиться своїм досвідом з точки зору належної практики."

#: ../../getting_started/documentation.rst:25
msgid ""
"**One and only decision maker on the client side (SPoC)**: He is responsible"
" for the business knowledge transmission (coordinate key users intervention "
"if necessary) and the consistency of the implementation from a business "
"point of view (decision making, change management, etc.)"
msgstr ""
"**Єдина контактна особа, яка приймає рішення зі сторони клієнта**: він "
"відповідає за передачу ділових знань (в разі потреби координує втручання "
"ключових користувачів) та узгоджує виконання з точки зору бізнесу (прийняття"
" рішень, управління змінами тощо). "

#: ../../getting_started/documentation.rst:31
msgid ""
"**Meetings optimization**: The Odoo consultant is not involved in the "
"process of decision making from a business point of view nor to precise "
"processes and company's internal procedures (unless a specific request or an"
" exception). Project meetings, who will take place once or twice a week, are"
" meant to align on the business needs (SPoC) and to define the way those "
"needs will be implemented in Odoo (Consultant)."
msgstr ""
"**Оптимізація зустрічей**: консультант Odoo не бере участі у процесі "
"прийняття рішень з точки зору бізнесу, а також не має чітких процесів та "
"внутрішніх процедур компанії (крім конкретного запиту чи винятку). Зустрічі "
"щодо проекту, які відбудуться раз або два на тижні, призначені для "
"узгодження бізнес-потреб (єдина контактна особа) та визначення способу "
"реалізації цих потреб в Odoo (консультант)."

#: ../../getting_started/documentation.rst:39
msgid ""
"**Train the Trainer approach**: The Odoo consultant provides functional "
"training to the SPoC so that he can pass on this knowledge to his "
"collaborators. In order for this approach to be successful, it is necessary "
"that the SPoC is also involved in its own rise in skills through self-"
"learning via the `Odoo documentation "
"<http://www.odoo.com/documentation/user/10.0/index.html>`__, `The elearning "
"platform <https://odoo.thinkific.com/courses/odoo-functional>`__ and the "
"testing of functionalities."
msgstr ""
"**Підготовка до навчання**: консультант Odoo надає функціональну підготовку "
"для єдиної контактної особи, щоб вона могла передавати ці знання своїм "
"співробітникам. Для того, щоби цей підхід був успішним, необхідно, щоби "
"контактна особа також брала участь у власному підвищенні навичок шляхом "
"самостійного навчання за допомогою `Документації Odoo "
"<http://www.odoo.com/documentation/user/10.0/index.html>`__, `The elearning "
"platform <https://odoo.thinkific.com/courses/odoo-functional>`__ та "
"тестування функціональних можливостей."

#: ../../getting_started/documentation.rst:47
msgid "2. Project Scope"
msgstr "2. Сфера застосування проекту"

#: ../../getting_started/documentation.rst:49
msgid ""
"To make sure all the stakeholders involved are always aligned, it is "
"necessary to define and to make the project scope evolve as long as the "
"project implementation is pursuing."
msgstr ""
"Аби переконатися, що всі зацікавлені сторони завжди узгоджують процеси між "
"собою, необхідно визначати та вносити зміст проекту поки реалізується "
"проект."

#: ../../getting_started/documentation.rst:53
msgid ""
"**A clear definition of the initial project scope**: A clear definition of "
"the initial needs is crucial to ensure the project is running smoothly. "
"Indeed, when all the stakeholders share the same vision, the evolution of "
"the needs and the resulting decision-making process are more simple and more"
" clear."
msgstr ""
"**Чітке визначення початкового обсягу проекту**: Чітке визначення початкових"
" потреб має вирішальне значення для забезпечення безперебійного виконання "
"проекту. Дійсно, коли всі зацікавлені сторони поділяють одне і те ж бачення,"
" еволюцію потреб та процес прийняття рішень є більш простими та "
"зрозумілішими."

#: ../../getting_started/documentation.rst:59
msgid ""
"**Phasing the project**: Favoring an implementation in several coherent "
"phases allowing regular production releases and an evolving takeover of Odoo"
" by the end users have demonstrated its effectiveness over time. This "
"approach also helps to identify gaps and apply corrective actions early in "
"the implementation."
msgstr ""
"**Поступова реалізація проекту**: Сприяння впровадженню на декількох "
"узгоджених етапах, що дозволяють регулярно впроваджувати продукцію, та "
"поступово охоплювати Odoo кінцевими споживачами, довели свою ефективність із"
" часом. Цей підхід також допомагає виявити прогалини та застосовувати "
"коригувальні дії на початку впровадження."

#: ../../getting_started/documentation.rst:66
msgid ""
"**Adopting standard features as a priority**: Odoo offers a great "
"environment to implement slight improvements (customizations) or more "
"important ones (developments). Nevertheless, adoption of the standard "
"solution will be preferred as often as possible in order to optimize project"
" delivery times and provide the user with a long-term stability and fluid "
"scalability of his new tool. Ideally, if an improvement of the software "
"should still be realized, its implementation will be carried out after an "
"experiment of the standard in production."
msgstr ""
"**Прийняття стандартних функцій в якості пріоритету**: Odoo пропонує чудове "
"середовище для здійснення незначних удосконалень (налаштувань) або більш "
"важливих (доробок). Тим не менше, прийняття стандартного рішення буде "
"віддавати перевагу якомога частіше, щоб оптимізувати час доставки проекту та"
" надавати користувачеві довгострокову стабільність та масштабність його "
"нового інструмента. В ідеалі, якщо поліпшення програмного забезпечення все-"
"таки має бути реалізоване, його впровадження буде здійснено після "
"експерименту зі стандартним впровадженням."

#: ../../getting_started/documentation.rst:80
msgid "3. Managing expectations"
msgstr "3. Управління очікуваннями"

#: ../../getting_started/documentation.rst:82
msgid ""
"The gap between the reality of an implementation and the expectations of "
"future users is a crucial factor. Three important aspects must be taken into"
" account from the beginning of the project:"
msgstr ""
"Розрив між реальним впровадження та майбутніми очікуваннями користувачів є "
"вирішальним чинником. З початку проекту необхідно враховувати три важливі "
"аспекти:"

#: ../../getting_started/documentation.rst:86
msgid ""
"**Align with the project approach**: Both a clear division of roles and "
"responsibilities and a clear description of the operating modes (validation,"
" problem-solving, etc.) are crucial to the success of an Odoo "
"implementation. It is therefore strongly advised to take the necessary time "
"at the beginning of the project to align with these topics and regularly "
"check that this is still the case."
msgstr ""
"**Співпрацювати з підходом до проекту**: Як чіткий розподіл ролей та "
"відповідальності, так і чіткий опис режимів роботи (перевірка, вирішення "
"проблем та ін.) мають вирішальне значення для успішного впровадження Odoo. "
"Тому настійно рекомендуємо вживати необхідний час на початку проекту, щоби "
"вирівнятися з цими темами, і регулярно перевіряти, чи усе ще так, як було "
"заплановано."

#: ../../getting_started/documentation.rst:94
msgid ""
"**Focus on the project success, not on the ideal solution**: The main goal "
"of the SPoC and the Consultant is to carry out the project entrusted to them"
" in order to provide the most effective solution to meet the needs "
"expressed. This goal can sometimes conflict with the end user's vision of an"
" ideal solution. In that case, the SPoC and the consultant will apply the "
"80-20 rule: focus on 80% of the expressed needs and take out the remaining "
"20% of the most disadvantageous objectives in terms of cost/benefit ratio "
"(those proportions can of course change over time). Therefore, it will be "
"considered acceptable to integrate a more time-consuming manipulation if a "
"global relief is noted. Changes in business processes may also be proposed "
"to pursue this same objective."
msgstr ""
"**Зосередьтеся на успіху проекту, а не на ідеальному рішенні**: Головною "
"метою єдиної контактної особи та консультанта є виконання завданого ними "
"проекту, щоби забезпечити найефективніше рішення для задоволення виражених "
"потреб. Ця мета іноді може суперечити баченню ідеального рішення клієнта. У "
"такому випадку контактна особа та консультант застосовуватимуть правило "
"80-20: зосередитись на 80% виражених потреб та вилучити решту 20% найбільш "
"невигідних цілей з точки зору співвідношення витрат і вигоди (ці відсотки, "
"звичайно, можуть бути зміненими з часом). Тому, якщо глобальне рішення буде "
"визначено, буде прийнято інтегрувати найбільш трудомістку маніпуляцію. Зміни"
" в бізнес-процесах також можуть бути запропоновані для досягнення цієї ж "
"мети."

#: ../../getting_started/documentation.rst:108
msgid ""
"**Specifications are always EXPLICIT**: Gaps between what is expected and "
"what is delivered are often a source of conflict in a project. In order to "
"avoid being in this delicate situation, we recommend using several types of "
"tools\\* :"
msgstr ""
"**Технічні характеристики завжди є ВИКЛЮЧНИМИ**: прогалини між тим, що "
"очікується і що доставляється, часто є джерелом конфлікту в проекті. Щоб "
"уникнути перебування в цій делікатній ситуації, ми рекомендуємо "
"використовувати кілька типів інструментів\\* :"

#: ../../getting_started/documentation.rst:113
msgid ""
"**The GAP Analysis**: The comparison of the request with the standard "
"features proposed by Odoo will make it possible to identify the gap to be "
"filled by developments/customizations or changes in business processes."
msgstr ""
"**GAP аналіз**: порівняння запиту клієнта зі стандартними функціями, "
"запропонованими компанією Odoo, дозволить визначити розрив, який повинен "
"бути заповнений розробками/налаштуваннями або змінами бізнес-процесів."

#: ../../getting_started/documentation.rst:118
msgid ""
"`The User Story <https://help.rallydev.com/writing-great-user-story>`__: "
"This technique clearly separates the responsibilities between the SPoC, "
"responsible for explaining the WHAT, the WHY and the WHO, and the Consultant"
" who will provide a response to the HOW."
msgstr ""
"`Історія користувача <https://help.rallydev.com/writing-great-user-"
"story>`__: Ця методика чітко розмежовує обов'язки між контактною особою, "
"відповідальним за роз'яснення ЩО, ЧОМУ та ХТО, та консультанта, який надасть"
" відповідь на ЯК."

#: ../../getting_started/documentation.rst:126
msgid ""
"`The Proof of Concept <https://en.wikipedia.org/wiki/Proof_of_concept>`__ A "
"simplified version, a prototype of what is expected to agree on the main "
"lines of expected changes."
msgstr ""
"`The Proof of Concept <https://en.wikipedia.org/wiki/Proof_of_concept>`__ "
"Cпрощена версія, прототип того, що очікується, узгоджується з основними "
"лініями очікуваних змін."

#: ../../getting_started/documentation.rst:130
msgid ""
"**The Mockup**: In the same idea as the Proof of Concept, it will align with"
" the changes related to the interface."
msgstr ""
"**Макет**: у тій же ідеї, що й PoC, який буде відповідати змінам, пов'язаним"
" з інтерфейсом."

#: ../../getting_started/documentation.rst:133
msgid ""
"To these tools will be added complete transparency on the possibilities and "
"limitations of the software and/or its environment so that all project "
"stakeholders have a clear idea of what can be expected/achieved in the "
"project. We will, therefore, avoid basing our work on hypotheses without "
"verifying its veracity beforehand."
msgstr ""
"До цих інструментів буде додано повну прозорість щодо можливостей та "
"обмежень програмного забезпечення та його оточення, щоб усі зацікавлені "
"сторони проекту могли чітко розуміти, що можна очікувати/досягти у проекті. "
"Тому ми не будемо базувати нашу роботу на гіпотезах, не перевіряючи "
"заздалегідь їх правдивість."

#: ../../getting_started/documentation.rst:139
msgid ""
"*This list can, of course, be completed by other tools that would more "
"adequately meet the realities and needs of your project*"
msgstr ""
"*Цей список, звичайно, можна доповнити іншими інструментами, які би більш "
"адекватно відповідали реаліям та потребам вашого проекту*"

#: ../../getting_started/documentation.rst:143
msgid "4. Communication Strategy"
msgstr "4. Комунікаційна стратегія"

#: ../../getting_started/documentation.rst:145
msgid ""
"The purpose of the QuickStart methodology is to ensure quick ownership of "
"the tool for end users. Effective communication is therefore crucial to the "
"success of this approach. Its optimization will, therefore, lead us to "
"follow those principles:"
msgstr ""
"Метою методології Швидкого старту є забезпечення швидкого володіння цим "
"інструментом для кінцевих користувачів. Тому ефективне спілкування має "
"вирішальне значення для успіху цього підходу. Тому його оптимізація приведе "
"нас до таких принципів:"

#: ../../getting_started/documentation.rst:150
msgid ""
"**Sharing the project management documentation**: The best way to ensure "
"that all stakeholders in a project have the same level of knowledge is to "
"provide direct access to the project's tracking document (Project "
"Organizer). This document will contain at least a list of tasks to be "
"performed as part of the implementation for which the priority level and the"
" manager are clearly defined."
msgstr ""
"**Спільне використання документації з управління проектами**: Найкращий "
"спосіб забезпечити усіх зацікавлених сторін проекту володінням однаковим "
"рівнем знань, забезпечити прямий доступ до документу відстеження проекту "
"(Організатор проекту). Цей документ міститиме, принаймні, список завдань, що"
" будуть виконуватися як частина реалізації, для чого чітко визначений рівень"
" пріоритету та менеджер. "

#: ../../getting_started/documentation.rst:158
msgid ""
"The Project Organizer is a shared project tracking tool that allows both "
"detailed tracking of ongoing tasks and the overall progress of the project."
msgstr ""
"Організатор проекту - це інструмент відстеження проектів, який дозволяє як "
"детальне відстеження поточних завдань, так і загальний прогрес проекту."

#: ../../getting_started/documentation.rst:162
msgid ""
"**Report essential information**: In order to minimize the documentation "
"time to the essentials, we will follow the following good practices:"
msgstr ""
"**Зверніть увагу на важливу інформацію**: щоб мінімізувати час документації "
"до найважливіших вимог, ми дотримуємось наступних правильних практик:"

#: ../../getting_started/documentation.rst:166
msgid "Meeting minutes will be limited to decisions and validations;"
msgstr "Протоколи зустрічі будуть обмежені лише рішеннями та перевірками;"

#: ../../getting_started/documentation.rst:168
msgid ""
"Project statuses will only be established when an important milestone is "
"reached;"
msgstr ""
"Статуси проекту визначаються лише тоді, коли досягнуто важливого етапу;"

#: ../../getting_started/documentation.rst:171
msgid ""
"Training sessions on the standard or customized solution will be organized."
msgstr ""
"Будуть організовані навчальні курси по стандартному або індивідуальному "
"рішенню."

#: ../../getting_started/documentation.rst:175
msgid "5. Customizations and Development"
msgstr "5. Налаштування та розробка"

#: ../../getting_started/documentation.rst:177
msgid ""
"Odoo is a software known for its flexibility and its important evolution "
"capacity. However, a significant amount of development contradicts a fast "
"and sustainable implementation. This is the reason why it is recommended to:"
msgstr ""
"Odoo - це програмне забезпечення, відоме своєю гнучкістю та важливою "
"здатністю до еволюції. Однак значна частина розвитку суперечить швидкій та "
"стабільній реалізації. Ось чому рекомендується:"

#: ../../getting_started/documentation.rst:182
msgid ""
"**Develop only for a good reason**: The decision to develop must always be "
"taken when the cost-benefit ratio is positive (saving time on a daily basis,"
" etc.). For example, it will be preferable to realize a significant "
"development in order to reduce the time of a daily operation, rather than an"
" operation to be performed only once a quarter. It is generally accepted "
"that the closer the solution is to the standard, the lighter and more fluid "
"the migration process, and the lower the maintenance costs for both parties."
" In addition, experience has shown us that 60% of initial development "
"requests are dropped after a few weeks of using standard Odoo (see "
"\"Adopting the standard as a priority\")."
msgstr ""
"**Розвиватися лише з вагомих причин**: рішення про розробку завжди повинно "
"бути прийняте, коли співвідношення витрат і вигод є позитивним (економія "
"часу на щоденній основі тощо). Наприклад, краще реалізувати значний "
"розвиток, щоб скоротити час щоденної експлуатації, а не виконувати операцію "
"лише один раз на квартал. Загальновизнано, що чим ближче рішення до "
"стандарту, тим легше і більш плавно відбувається процес міграції, і чим "
"нижчі витрати на обслуговування для обох сторін. Крім того, досвід показує "
"нам, що 60% первинних запитів на розробку знищуються через кілька тижнів "
"використання стандартного Odoo (див. \"Прийняття стандарту як пріоритет\")."

#: ../../getting_started/documentation.rst:194
msgid ""
"**Replace, without replicate**: There is a good reason for the decision to "
"change the management software has been made. In this context, the moment of"
" implementation is THE right moment to accept and even be a change initiator"
" both in terms of how the software will be used and at the level of the "
"business processes of the company."
msgstr ""
"**Заміна без реплікації**: є вагомі підстави для прийняття рішення про зміну"
" програмного забезпечення для управління. У цьому контексті момент "
"реалізації є правильним моментом прийняття і навіть є ініціатором зміни як з"
" точки зору використання програмного забезпечення, так і на рівні бізнес-"
"процесів компанії."

#: ../../getting_started/documentation.rst:202
msgid "6. Testing and Validation principles"
msgstr "6. Тестування та принципи перевірки"

#: ../../getting_started/documentation.rst:204
msgid ""
"Whether developments are made or not in the implementation, it is crucial to"
" test and validate the correspondence of the solution with the operational "
"needs of the company."
msgstr ""
"Незалежно від того, чи були розробки чи ні, важливо перевірити відповідність"
" рішення операційним потребам компанії."

#: ../../getting_started/documentation.rst:208
msgid ""
"**Role distribution**: In this context, the Consultant will be responsible "
"for delivering a solution corresponding to the defined specifications; the "
"SPoC will have to test and validate that the solution delivered meets the "
"requirements of the operational reality."
msgstr ""
"**Розподіл ролей**: у цьому контексті консультант буде відповідати за "
"надання рішення, що відповідає визначеним специфікаціям; контактна особа "
"повинна буде протестувати та підтвердити, що рішення, яке постачається, "
"відповідає вимогам операційної реальності."

#: ../../getting_started/documentation.rst:214
msgid ""
"**Change management**: When a change needs to be made to the solution, the "
"noted gap is caused by:"
msgstr ""
"**Управління змінами**: коли необхідно внести зміни до рішення, зазначений "
"розрив обумовлений:"

#: ../../getting_started/documentation.rst:218
msgid ""
"A difference between the specification and the delivered solution - This is "
"a correction for which the Consultant is responsible"
msgstr ""
"Різницею між специфікацією та доставленим рішенням - це виправлення, за яке "
"відповідає консультант."

#: ../../getting_started/documentation.rst:220
msgid "**or**"
msgstr "**або**"

#: ../../getting_started/documentation.rst:222
msgid ""
"A difference between the specification and the imperatives of operational "
"reality - This is a change that is the responsibility of SPoC."
msgstr ""
"Різницею між специфікацією та вимогами операційної реальності - це зміна, на"
" яку відповідає контактна особа."

#: ../../getting_started/documentation.rst:226
msgid "7. Data Imports"
msgstr "7. Імпорт даних"

#: ../../getting_started/documentation.rst:228
msgid ""
"Importing the history of transactional data is an important issue and must "
"be answered appropriately to allow the project running smoothly. Indeed, "
"this task can be time-consuming and, if its priority is not well defined, "
"prevent production from happening in time. To do this as soon as possible, "
"it will be decided :"
msgstr ""
"Імпорт історії транзакційних даних є важливою проблемою, і відповідним чином"
" потрібно відповісти на це, щоб забезпечити безперебійну роботу проекту. "
"Дійсно, це завдання може зайняти багато часу, і, якщо його пріоритет не є "
"чітко визначеним, запобігти впровадженню вчасно. Щоб зробити це якомога "
"швидше, буде вирішено:"

#: ../../getting_started/documentation.rst:234
msgid ""
"**Not to import anything**: It often happens that after reflection, "
"importing data history is not considered necessary, these data being, "
"moreover, kept outside Odoo and consolidated for later reporting."
msgstr ""
"**Не імпортувати нічого**: Часто буває, що після відображення імпортування "
"історії даних стає не необхідним, причому ці дані зберігаються поза межами "
"Odoo і консолідуються для подальшої звітності."

#: ../../getting_started/documentation.rst:239
msgid ""
"**To import a limited amount of data before going into production**: When "
"the data history relates to information being processed (purchase orders, "
"invoices, open projects, for example), the need to have this information "
"available from the first day of use in production is real. In this case, the"
" import will be made before the production launch."
msgstr ""
"**Щоб імпортувати обмежену кількість даних перед початком впровадження**: "
"коли історія даних стосується оброблюваної інформації (наприклад, замовлення"
" на купівлю, рахунки-фактури, відкриті проекти), необхідність мати цю "
"інформацію з першого дня використання у впровадженні - це реально. У цьому "
"випадку імпорт буде здійснюватися до початку запуску впровадження."

#: ../../getting_started/documentation.rst:246
msgid ""
"**To import after production launch**: When the data history needs to be "
"integrated with Odoo mainly for reporting purposes, it is clear that these "
"can be integrated into the software retrospectively. In this case, the "
"production launch of the solution will precede the required imports."
msgstr ""
"**Імпорт після запуску впровадження**: коли історія даних повинна бути "
"інтегрована з Odoo, в основному для цілей звітування, то очевидно, що вони "
"можуть бути інтегровані в програмне забезпечення ретроспективно. У цьому "
"випадку запуск впровадження буде передувати необхідному імпорту."