Implementation Guidelines

Stand 01.07.2021

The guidelines listed represent the basis for all implementation projects and are therefore part of the contract.

    

1. General requirements and delimitatio

1.1 Project scope and implementation

In the course of the analysis workshop, project goals, non-goals and acceptance criteria are defined on the basis of the gap analysis. These clearly limit the scope of the project.

If additional requirements arise in the course of implementation, these must be evaluated accordingly. After evaluating the effects on the project scope, timeframe and budget, further actions have to be decided.

The solutions proposed the requirements document are potential approaches that are based on the knowledge of the pre-project phase. Should it turn out in the course of the implementation that the complexity of individual requirements is significantly higher than expected, SUPPLiot hast to inform the client about potential effects with regard to cost and schedule planning as soon as possible.

1.2 Admin-User

Neben den vom Auftraggeber nominierten Usern wird ein zusätzlicher User für Admin-Tätigkeiten eingerichtet. Dies soll sicherstellen, dass im Zuge von Konfigurationsarbeiten keine Rollenkonflikte im System auftreten. Die Lizenzkosten für den Admin-User trägt der Auftraggeber

1.3 Translations

In the case that the system is to be available in multiple languages, Odoo's standard translation functionality will be used (unless explicitly specified in the project scope).

1.4 Data supplies and imports

When delimiting the project content, the number of necessary data imports must be defined in order to take them into account accordingly in the quotation calculation.

The cleaning of import data is not part of the project scope, unless explicitly stated in the offer. In case of several different data sources, a unique primary key is absolutely necessary.

If not explicitly specified otherwise in the requirements, a maximum of 20,000 data records per data type may be delivered. One file is to be transmitted per data type (customers, products, etc.). 

1.5 Corrections in content

A maximum of two correction loops are provided for embedding predefined texts or document layouts. The correction of text templates is not part of the project scope, unless explicitly stated in the offer.

1.6 Trainings and training materials

Training may include the following materials/activities:

  • Documentation of Odoo standard functionality


  • Video/Screenshot documentation


  • User training 

The Odoo standard functionality is documented on www.odoo.com. Those training documents are only available in English. Only individual developments can also be documented in German via video. The estimated training duration is based on experience from past projects. The actual amount of training required varies depending on the level of experience and affinity of the users. This will be adjusted as needed during the project.

1.7 Support

Activities after completion of the implementation project fall within the scope of support. Since support activities are not included in the scope of the commissioned project, they are charged on a time and material basis. Experience shows that support efforts can be greatly reduced by using a key user (see below).  Booked support packages only include the efforts offered in the package (plus 20% tolerance). If the expenses incurred exceed the tolerance value, any additional expenses will be charged subsequently.

In accordance with the guidelines defined at  www.suppliot.eu/support, support activities are only carried out on Austrian working days. Monday to Thursday between 09:00 and 17:00 (CET) and Fridays between 09:00 and 15:00 (CET). Unless explicitly agreed otherwise, support activities are only provided in German.

2. Cooperation obligations of the customer

2.1 Key User

On the customer side, the role of the "key user" must be assigned.

The "key user" role includes:

  • acting as a central technical contact on the customer side,


  • the execution of first-level support on the customer side during the project and beyond, and


  • the performance of the functional tests and the acceptance tests.

2.2 Acceptance tests

The prerequisite for performing acceptance tests is the creation of a test case catalog. The aim of the test case catalog is to define test cases for all requirements to be implemented in order to check the functionality of the implemented developments. The test case catalog, which is valid for the acceptance tests, must be accepted by the customer before the tests begin.

In the course of the acceptance test phase, the client has the opportunity to check if the requirements defined for the project have been implemented in accordance with the agreed functionalities. The results of the acceptance tests serve as a basis for any error corrections. Successfully completed acceptance tests require acceptance of the project results by the customer.