Implementation Guidelines

Stand 25.01.2022

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

    

1.  General requirements and delimitation

1.1 Project scope and implementation

In the course of the joint analysis workshop, project objectives, non-objectives and acceptance criteria are defined based on the results of the GAP analysis. These clearly delimit the content of the project. A requirement document is created that contains all the requirements to be implemented. 

If additional requirements arise during the course of implementation, these must be evaluated accordingly. After evaluating the impact on the content, schedule and budget of the project, the decision to implement is made.

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 User count

In addition to the users required by the client, an additional user is set up for administration activities. This ensures that no role conflicts occur in the system during configuration work. The license costs for the admin user are borne by the client.

Under certain circumstances, additional users may be required in addition to those clearly assigned to individual employees. These must also be licensed with Odoo - these are, for example:

  • special service users needed for authentication for the provision of an interface

  • User with specially restricted rights, e.g. a user which is used for the "Attendance times" module to enable employees to clock in and out in "kiosk mode" at a central point


1.3 Data delivery and import

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.

A unique primary key is absolutely necessary for different data sources.

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.). 

The estimated import effort for the data import includes data records that are managed as "master data" (e.g. product data, customer data, payment terms, etc.). "Current data" (invoices, orders, quotations, etc.) are not taken over - unless agreed separately.


1.4 Message and document templates

Unless explicitly agreed otherwise and estimated, document templates and (e-mail) message templates are provided by SUPPLiot in Odoo standard (incl. standard variant of header and footer, company data and logos are used as part of the basic setup).

You can view the (most commonly used) standard report layouts here:

  • Offer: 

  • Order confirmation: 

  • Purchase request: 

  • Order: 

  • Invoice: 

If changes are agreed, a maximum of two correction loops are provided for embedding predefined texts or document layouts. Further adjustments will be charged according to time and effort. 


1.6 Trainings and training materials

Training may include the following materials and activities:

  • Documentation of Odoo standard functionality

  • Video/Screenshot documentation

  • User training 

The Odoo standard functionality is documented on www.odoo.comHowever, the general Odoo training documentation is only available in English.

Only individual developments by SUPPLiot can be documented via video in German.

The estimated training duration is based on experience values of past projects. The actual training effort required varies depending on the level of experience and affinity of the users. The training effort will be adjusted in the course of the project according to demand and charged on a time and material basis.


1.7 Support

Activities after completion of the implementation project fall within the scope of "Support". Since support activities are outside the scope of the project, they are charged on a time and material basis. Experience has shown that support costs can be greatly reduced by using a key user (see point 2.1 Key user).

Monthly support packages can also be booked. Booked support packages only include the effort offered in the package (plus 20% tolerance). If the effort exceeds the tolerance value, any additional effort will be charged. If the tolerance value is exceeded in several consecutive months, a change to a higher support package will be discussed with the customer. 

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.


1.7 Hardware & Infrastructure

Unless explicitly agreed otherwise, SUPPLiot shall not assume the role of supplier for hardware to be purchased or other infrastructure services (Internet, e-mail accounts).

  • Examples of other required hardware: (Android) scanner for mapping warehouse processes, label printer, etc.



2.  Cooperation obligations of the customer

2.1 Key User

On the client side, the role of the "key user" must be filled.

The role of the "key user":

  • 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


  • Perform functional and acceptance testing.


2.2 Acceptance testing

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. 



3.  Functionality Odoo

3.1 The role of Odoo

Odoo S.A. prepares the offers for required licenses and enters into a direct business relationship with the end users. Odoo remains the contact for all service matters and customer inquiries relating to licensing (extension offers, contract extension, invoicing, general Odoo errors, etc.). ​

From this contract also arises the right to support service for the standard functional scope of Odoo. General support tickets can be brought in here: ​https://www.odoo.com/de_DE/help.


3.2 Odoo as an ERP system

SUPPLiot is an implementation service provider for the Odoo system and is not directly responsible for the functional scope of the software. The standard functional scope can be seen in the Odoo documentation (https://www.odoo.com/de_DE/page/docs). 

Deviations from the "target" revealed during the analysis process are taken up by SUPPLiot and evaluated if necessary. Other additional requirements are either individually evaluated and developed by SUPPLiot or forwarded to Odoo as a "feature request" without obligation, depending on the customer's wishes.


3.3 Odoo as an e-mail client


Odoo offers the possibility to send and receive e-mails via the system, but the following restrictions have to be considered:

  • The e-mail dispatch set up by SUPPLiot works via Odoo.sh by default. By default, 200 e-mails per day can be sent via Odoo.sh. This limit can be gradually increased to approx. 1,000 e-mails per day. An adjustment has to be discussed with the Odoo support. If the number of emails sent per day is higher, you must switch to a different dispatch service provider.

  • Odoo is not a replacement for a classic e-mail client. Although it is possible to send and receive document-specific messages, another system is additionally required to handle the "other" e-mail traffic.


3.4 Translations in Odoo

If not defined separately in the offer, Odoo is set up in 2 languages by default: German and English. Here, the translation files provided by Odoo are used, which are maintained by the Odoo community. If the translation of an Odoo module is insufficient, SUPPLiot will adapt the translations according to effort.

Only work packages that have been explicitly assessed by SUPPLiot with "development effort" also require individualization through development work. Work packages that have been assessed with "Configuration" are implemented within the framework of the Odoo standard.


3.5 Minor and major updates

For customers with Odoo.sh as the selected hosting variant:

  • Minor updates: Minor updates contain bug fixes and security patches and are automatically applied to the system on a weekly basis (Monday). There is only a downtime of a few seconds during the update. Possible problems caused by minor updates will be fixed by SUPPLiot, the effort for this is usually covered by the time quota for support/month offered by SUPPLiot.

  • Major updates: Major updates are currently released by Odoo annually in Q4. An annual update to the latest version is not mandatory, but recommended. When a new major version is released, SUPPLiot checks it for possible relevant functions for the customer and indicates an update option. Old versions will continue to be supported by Odoo for 3 years. The update to a new major version will be charged according to effort and, if requested by the customer, estimated in advance by SUPPLiot.

For customers with self-hosting as the chosen hosting option:

Both major and minor updates are installed in the customer's system at the customer's request and at cost.


3.6 Bugfixing in Odoo

SUPPLiot distinguishes between four different types of bugfixing:

  • Fixing errors that occur in Odoo Standard: Errors that occur in the Odoo standard can be

    • by an existing license agreement between the customer and Odoo be registered directly by the customer to Odoo centrally at Odoo (communication language = English), see the Odoo Enterprise Guidelines, point 4.1 (https://www.odoo.com/documentation/15.0/odoo_enterprise_agreement.pdf) - there are no costs for this

    • be reported to Odoo by SUPPLiot on request of the customer or be fixed directly (hotfixing) - the resulting effort is counted as support time

  • Correction of errors that occur in a SUPPLiot standard module and for which the customer has an active maintenance contract: free correction of the error by SUPPLiot.

  • Troubleshooting in modules developed individually for the customer:

    • If the module is developed on the basis of a lump sum: errors are corrected within a warranty period of 20 days after delivery

    • If the module is developed according to "Time & Material": Errors are corrected according to expenditure

  • Fixing errors in third-party modules purchased for the customer (via Odoo App Store): Depending on the provider, individually different support guarantees are given for a module from the time of purchase. If an error is discovered within this period, it can be forwarded to the manufacturer by SUPPLiot. Errors outside the warranty period or errors caused by interactions between purchased modules will be fixed by SUPPLiot and charged according to time and effort.