Regulations for the Provision of Services

DEFINITIONS

1. the REGULATIONS – the document describing the rules for providing changes to the Software under the AGREEMENT.

2. CONTRACT – an agreement for service support of software developed by Petrosoft.pl. The agreement regulates the scope of support and the terms of the quality of service (SLA). Other terms and conditions for handling the support process for software changes are governed by these regulations.

3. SOFTWARE – an IT system produced by Petrosoft.pl or provided for maintenance by Petrosoft.pl

4. CRITICAL ERROR – a malfunction of the System resulting in a complete inability to use the System for all users or the inoperability of key areas of the Software.

5. NON-CRITICAL ERROR – a malfunction of the System causing a limitation of the use of the System while maintaining the Software’s fulfillment of its basic functions. An example of a Non-Critical Error is the unavailability of non-critical features of the Software that does not disable the availability of the Software for more than 25% of users.

6. TROUBLE – a malfunction of the System that does not cause a limitation of its use. Examples of a Fault include inaccessibility of the help system, language error in the interface, incorrect report.

7. HOTFIX – a technical fix or rapid engineering update used to resolve a problem in the Software.

8 CHANGE – a request for a change in the Software consisting of new functionalities, changes in forms, changes in reports, and any change in the Software at the request of the Ordering Party under the current Agreement.

9. SERVICE – service support service for the process of delivering software changes.

10. RAILSOFT PUBLICATION SCHEDULE – a schedule that establishes the cycle of production of new versions including periods of development, testing and publication. Petrosoft.pl undertakes to update the schedule no later than one month before the last publication date indicated in the schedule.

11. PUBLICATION DAY – the days set in the schedule (paragraph a. of this section) on which Petrosoft.pl undertakes to provide a stable version of the software. The exact day of publication in the Ordering Party’s test or production environment will be determined each time between the parties as part of a separate request for version publication.

a. Publication schedule for 2022: 03.01., 31.01., 28.02., 28.03., 04.05., 30.05., 27.06., 25.07., 22.08, 19.09., 17.10., 14.11., 12.12.

12. TECHNICAL TIME – a lump sum of time spent preparing the installation version of the software and/or installing a new version of the software in a test or production environment. Technical time will be billed according to the terms of the service contract.

13. SERVICE INCIDENT – a notification registered in the Petrosoft.pl HelpDesk system, which related to the operation of the Software.

14. SLA (Service Level Agreement) – parameters guaranteed by Petrosoft.pl that define the rules and deadlines for the removal of any incompatibility of the Software.

a. Critical Error – response time up to 6h working time, repair time up to 16h working time – unless otherwise regulated by the Agreement.

b. Non-Critical Error – response time up to 12h working time, repair time up to 32h working time – unless otherwise regulated by the Contract.

c. Fault – according to the provisions of §3 item. 3.

 

§ 1
GENERAL PROVISIONS

(1) The Terms and Conditions set out the rules for the provision of programming services for the maintenance support of the Software.

(2) The Rules and Regulations are an integral part of the Agreement concluded between Petrosoft.pl and the Ordering Party and set out the rules in the process of delivering changes to the Software.

3 The Regulations use the Definitions and Abbreviations specified in the Agreement.

4 The current version of the REGULATIONS is published on the website https://www.petrosoft.pl.

(5) The user is obliged to familiarize himself with the content of the Regulations before using the services.

 

§ 2 TERMS OF SERVICE

1 Petrosoft.co.uk undertakes to resolve reported Service Incidents regarding the Software.

(2) Petrosoft.pl agrees to implement changes to the Software in accordance with the parameters of the SLA regarding Critical Errors, Non-Critical Errors, Defects and other requests in accordance with the Terms and Conditions.

3 Required information to report a Service Incident:

a. Name of applicant

b. Contact phone, email address

c. Location (headquarters, office)

d. The area from which the request originates (e.g. Planning, Accounting, etc.),

e. A detailed description of the request, which is to include the complete information needed to verify the request or reproduce the error, i.e. scenario/list of steps to reach the error, screen(s), details of the error, place of origin of the error, description of the situation that occurred.

f. Choosing the service package from which the incident is to be carried out (in the case of service packages other than weekdays) – the Ordering Party decides (e.g., having a full package, you can report an incident on Sunday, but with the assumption that it can be carried out from the hours of the basic package, because it is not urgent).

(4) Each reported Service Incident will be automatically assigned a service request number, a registered requester, and its acceptance will be automatically confirmed by an information sent to the Ordering Party’s email account.

(5) The start and completion of service activities will be recorded using the HelpDesk system.

(6) The working time spent on the implementation of maintenance activities will be recorded in the HelpDesk system, and the records of this system will be the basis for the settlement of working time for the billing month.

7 The services referred to in §2 will be ordered and recorded using the HelpDesk system.

(8) The Submitter of a Service Incident may reopen its service request within 5 working days after the incident is closed in the absence of confirmation of the service provided.

(9) The support provided by the Contractor under the terms hereof shall be provided in Polish.

 

§ 3
RULES FOR HANDLING ERRORS, DEFECTS, SOFTWARE CHANGES

1. Critical Error Handling – changes will be immediately prepared as HotFix in accordance with the SLA regarding the Critical Error specified in the Regulations. If the Contract defines provisions for a Critical Error then the Contract shall prevail. Publication of changes requires the submission of an appropriate order for publication §3 item. 5.

2. Non-Critical Error Handling – changes will be immediately prepared as HotFix in accordance with the SLA regarding the Non-Critical Error specified in the Regulations. If provisions for Non-Critical Error are defined in the Contract then the Contract shall prevail. Publication of changes requires the submission of an appropriate order for publication §3 item. 5.

3. Fault Handling – Fault corrections will be prepared in an established publication cycle as detailed in the publication schedule (Appendix 1)

a. If the notification of a defect occurs more than two weeks before the scheduled publication date – the installation of a fix will be published in the current generation cycle.

b. If the notification of a defect occurs less than two weeks before the scheduled publication date – the installation of a fix will be published on the next generation cycle (the next 28 days) from the notification,

c. if the Ordering Party requires the preparation of the installation of a software change in a shorter period of time than the Publication Day indicated in the Regulations, an “additional fee” will be required, resulting from the time to be spent on the preparation of the additional version of the software.

i. Technical time for preparation of HotFix installation version – 3h

ii. Technical installation time of new software versions in case of publication:

1. in Petrosoft.pl environment – 3h

2. in the client’s environment – 6h

a. In case of exceeding technical times, the actual publication time in the service incident ordering the installation of a new version of the software , which will be based on the time reported by Petrosoft.pl employees, will be reported.

4. Support Changes related to software development.

a. A service request for software development is treated as an inquiry

b. A deadline of up to 7 working days is set for the preparation of a bid for the request for proposal.

c. Once the parameters of implementation (deadline and man-hours) are established, the application will be implemented within the timeframe agreed and accepted by both parties.

5. Version preparation

a. Version preparation time for warranty claims is not reported.

b. In the case of a service request Publication of version – before the publication of the version to the customer will be provided information about the readiness to implement the version. Based on this information, the customer interested in publishing should set up a separate service request for version publications.

i. Technical time to prepare the installation version – 4h

ii. Technical installation time of new software versions in case of publication:

1. in Petrosoft.pl environment – 3h

2. in the customer environment – 6h

(3) In the case of exceeding technical times, the actual publication time in the service incident ordering the installation of a new version of the software will be reported, which will be based on the time reported by Petrosoft.pl employees.

 

§ 4
FINAL PROVISIONS

1. petrosoft.pl reserves the right to amend these Terms and Conditions at any time without giving any reason by posting appropriate information on the website www.petrosoft.pl.

(2) Customer’s use of Petrosoft.pl service support services after the amendments to the Terms and Conditions is tantamount to their acceptance.

(3) The validity or effectiveness of the remaining provisions of these Regulations shall not be affected by the recognition of individual provisions of these Regulations as invalid or ineffective as provided by law. The invalid provision will be replaced by the rule that comes closest to the purposes of the invalid provision and these Regulations as a whole.

4 The Regulations are an integral part of the Agreement.

(5) These Regulations are effective as of 01.01.2022. and replaces earlier versions of the Regulations in their entirety.

DEFINITIONS

1. the TERMS and CONDITIONS – a document describing the rules for providing changes to the Software under the AGREEMENT

2. AGREEMENT – an agreement for service support of software developed by Petrosoft.pl. The agreement regulates the scope of support and the terms of the quality of service (SLA). Other terms and conditions for handling the support process for software changes are governed by these regulations.

3. SOFTWARE – an IT system produced by Petrosoft.pl or provided for maintenance by Petrosoft.pl

4. CRITICAL ERROR – a malfunction of the System resulting in a complete inability to use the System for all users or the inoperability of key areas of the Software.

5. NON-CRITICAL ERROR – a malfunction of the System that causes a limitation of the use of the System while maintaining the Software’s fulfillment of its basic functions. An example of a Non-Critical Error is the unavailability of non-critical features of the Software that does not disable the availability of the Software for more than 25% of users.

6. TROUBLE – a malfunction of the System that does not cause a limitation of its use. Examples of a Fault include inaccessibility of the help system, language error in the interface, incorrect report.

7. HOTFIX – a technical fix or rapid engineering update used to resolve a problem in the Software.

8 CHANGE – a request for a change in the Software consisting of new functionalities, changes in forms, changes in reports, and any change in the Software at the request of the Ordering Party under the current Agreement.

9. SERVICE – service support service for the process of delivering software changes

10. PUBLICATION DAY – a working day of the week, agreed between the parties, on which Petrosoft.pl publishes a change in the software on the Ordering Party’s production or test environment (e.g. Tuesday or Wednesday). The established day of publication may be changed by the approval of both parties via email by the persons designated in the Agreement to coordinate activities. The date of entry into force of these regulations is set for publication: Wednesday.

11. service incident – a notification registered in the Petrosoft.pl HelpDesk system, which related to the operation of the Software.

12. SLA (Service Level Agreement) – parameters guaranteed by Petrosoft.pl that define the rules and deadlines for removing any nonconformity of the Software
a. Critical Error – response time up to 6h working time, repair time up to 16h working time – unless otherwise regulated by the Agreement.
b. Non-Critical Error – response time up to 12h working time, repair time up to 32h working time – unless otherwise regulated by the Contract.
c. Fault – according to the provisions of §3 item. 3

 

§ 1

GENERAL PROVISIONS

(1) The Terms and Conditions set out the rules for the provision of programming services for the maintenance support of the Software.

(2) The Rules and Regulations are an integral part of the Agreement concluded between Petrosoft.pl and the Ordering Party and set out the rules in the process of delivering changes to the Software.

3 The Regulations use the Definitions and Abbreviations specified in the Agreement.

4 The current version of the REGULATIONS is published on the website https://www.petrosoft.pl.

(5) The user is obliged to familiarize himself with the content of the Regulations before using the services.

 

§ 2

TERMS AND CONDITIONS OF SERVICE

1 Petrosoft.co.uk undertakes to resolve reported Service Incidents regarding the Software.

(2) Petrosoft.pl agrees to implement changes to the Software in accordance with the parameters of the SLA regarding Critical Errors, Non-Critical Errors, Defects and other requests in accordance with the Terms and Conditions.

3 Required information to report a Service Incident:
a. Name of the submitter,
b. Contact phone, email address
c. Location (headquarters, office),
d. The area from which the request comes (e.g., Planning, Accounting, etc.).
e. The description of the request, which is to include the complete information needed to verify the request or reproduce the error, i.e. scenario/list of steps to reach the error, screen(s), details of the error, place of origin of the error, description of the situation that occurred.
f. Choosing the service package from which the incident is to be carried out (in the case of service packages other than weekdays) – the Ordering Party decides (e.g., having a full package, you can report an incident on Sunday, but with the assumption that it can be carried out from the hours of the basic package, because it is not urgent).

(4) Each reported Service Incident will be automatically assigned a service request number, a registered requester, and its acceptance will be automatically confirmed by an information sent to the Ordering Party’s email account.

(5) The start and completion of service activities will be recorded using the HelpDesk system.

(6) The working time spent on the implementation of maintenance activities will be recorded in the HelpDesk system, and the records of this system will be the basis for the settlement of working time for the billing month.

7 The services referred to in §2 will be ordered and recorded using the HelpDesk system.

(8) The Service Incident Submitter may reopen its service request in the absence of confirmation of the service performed.

(9) The support provided by the Contractor under the terms hereof shall be provided in Polish.

 

§ 3
RULES FOR HANDLING ERRORS, DEFECTS, SOFTWARE CHANGES

1. Critical Error Handling – changes will be immediately published through HotFix in accordance with the SLA regarding the Critical Error specified in the Rules. If the Contract defines provisions for a Critical Error then the Contract shall prevail.

2. Non-Critical Error Handling – changes will be promptly published through HotFix in accordance with the SLA regarding the Non-Critical Error specified in the Terms and Conditions. If provisions for Non-Critical Error are defined in the Contract then the Contract shall prevail.

3. Handling Fault – changes will be published on the established Publication Day
a. If the notification of the change will be a day before the established Publication Day by 4 pm – the installation of the change will be published on the next Publication Day (the following week) from the notification.
b. If the notification of a change is registered the day before the established Publication Day after 4 pm – the installation of the change will be published on the second consecutive Publication Day (the next 2 weeks) after the notification.
c. in the event of a requirement by the Ordering Party to publish the installation of a software change in a shorter period of time than the Publication Day indicated in the Terms and Conditions, an “additional fee” agreed upon by the Parties on a one-time basis will be required.

4. Shift Service related to software development.
a. A service request for software development is treated as an inquiry
b. A deadline of up to 7 working days is set for the preparation of a quotation for the request for quotation.

c. Once the parameters of implementation (deadline and man-hours) are established, the application will be implemented within the timeframe agreed and accepted by both parties.

 

§ 4
FINAL PROVISIONS

1. petrosoft.pl reserves the right to amend these Terms and Conditions at any time without giving any reason by posting appropriate information on the website www.petrosoft.pl.

(2) Customer’s use of Petrosoft.pl service support services after the amendments to the Terms and Conditions is tantamount to their acceptance.

(3) The validity or effectiveness of the remaining provisions of these Regulations shall not be affected by the recognition of individual provisions of these Regulations as invalid or ineffective as provided by law. The invalid provision will be replaced by the rule that comes closest to the purposes of the invalid provision and these Regulations as a whole.

(4) These Regulations are effective as of February 1, 2021.

(5) In matters not covered by the regulations, the generally applicable provisions of law shall apply, including the provisions of the Civil Code, the Act of July 18, 2002. on the provision of electronic services and the Telecommunications Law of July 16, 2004 (Journal of Laws of 2014, item 243, as amended).

(6) Any disputes arising from the application of these Regulations shall be settled by a court having jurisdiction over the Company’s registered office.