1. General requirements and delimitation
1.1 Project scope and implementation
In the course of the joint analysis workshops, project goals, non-goals 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 in 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 has to inform the client as soon as possible about potential effects with regard to cost and schedule planning.
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 supported 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 that are required for authentication purposes while setting up an interface
User with specifically 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 in the quotation calculation.
Unless explicitly stated in the offer, the cleansing of import data is not part of the scope of the project.
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 upon separately.
1.4 Message and document templates
Unless otherwise explicitly agreed upon and estimated, document templates and (e-mail) message templates are provided by SUPPLiot in the Odoo standard (including standard variants of header and footer, company data and logos are used as part of the basic setup).
You can see the (most commonly used) standard report layouts here:
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.5 Trainings and training materials
Training may include the following materials and activities:
Documentation of the Odoo standard functionality
Odoo default functionality can be found at
However, 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 during the course of the project according to demand and charged on a time and material basis.
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 client.
According to 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 Friday between 09.00 and 15.00 (CET). Unless explicitly agreed otherwise, support activities are carried out in German.
1.7 Hardware & infrastructure
Unless explicitly agreed otherwise, SUPPLiot shall not assume the role of supplier for purchasing hardware or other infrastructure services (Internet, e-mail accounts).
Required hardware for PoS (Point of Sale) processes: https://www.odoo.com/de_DE/app/point-of-sale-hardware
Examples of other required hardware: (android-) scanner for mapping warehouse processes, label printer, etc.
2. Client Obligations
On the client side, the role of the "key user" must be assigned.
The role of the "key user":
acts as the central technical contact on the client side
carries out the first-level support on the client side - during the project and beyond
performs the functional and acceptance tests.
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 client 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 client.
2.3 Replacement of the old system
Unless otherwise agreed, the client is responsible for the replacement of the old system. We recommend that the following points be clarified in a timely manner:
- License Termination Periods
- Notice periods for support or other ongoing expenses
- open implementation quotas
- Transitional periods (e.g. double access to old and new system)
- Archiving of legacy data and ensuring access for the relevant people
3. Odoo functions range
3.1 Odoo's role
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 client inquiries relating to licensing (extension offers, contract extension, invoicing, general Odoo errors, etc.).
The right to support services for the standard functionality of Odoo also arises from this contract. General support tickets may be submitted here: https://www.odoo.com/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/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 client's wishes.
3.3 Odoo as an e-mail-client
Odoo offers the possibility to send and receive e-mails via the system, with the following limitations being observed:
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 Odoo as a mobile app
The Enterprise version of Odoo allows users to log into the database using an app. It should be noted that the app only works if the mobile device has an active Internet connection. Offline use is not possible.
3.5 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.6 Minor and Major-Updates
For clients with Odoo.sh as the selected hosting option:
Minor updates: Minor updates contain bug fixes and security patches and are automatically applied to the system on a weekly basis (Mondays). 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 client 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 client, estimated in advance by SUPPLiot.
For clients with self-hosting as the selected hosting option:
- Both major and minor updates are imported into the clients' system at the clients' request according to effort.
3.7 Bugfixing in Odoo
SUPPLiot distinguishes between four different types of bugfixing:
Fixing errors that occur in the Odoo standard: Errors that occur in the Odoo standard:
can be registered to Odoo directly by the client through an existing license agreement between the client and 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 involved
If requested by the client, the problem can be reported to Odoo by SUPPLiot or rectified directly (hotfixing) - the effort incurred is calculated as support time
Fixing bugs that occur in a SUPPLiot standard module and for which the client has an active maintenance contract: free fixing of the bug by SUPPLiot
Fixing errors in modules developed individually for the client:
If the module is developed on the basis of a flat rate: Errors will be rectified within a guarantee period of 20 days after handover
When developing the module according to "Time & Material": Errors will be corrected at cost
Correction of errors in third-party modules purchased for the client (via Odoo App Store): Depending on the provider, different support guarantees are given for a module from the time of purchase. If an error is discovered within this period, SUPPLiot can forward it to the manufacturer. Errors outside the warranty period or errors caused by interactions between purchased modules are corrected by SUPPLiot and charged at cost.