This document describes developing and bug fixing algorithms and contains common developing rules and ERP-system best practices.

Developing task

As part of software development, the developer must:

1. Preparation for development:

• Before working out the development, read the specification.
• Check if there is a completed test card in Story and whether its contents are enough to fully test the software being developed. If not enough, clarify this question from the consultant.
• Discuss the specification with the consultant and the architect who created it.
• Update the source code on your local machine from TFS.
• If the development affects (changes) already existing code, lock this code in TFS.
• Expand locally the last copy of HOMOLOG located on the internal server (WARNING! For each Story in JIRA there must be a local copy of HOMOLOG).
• If the development affects other changes that are not yet in the copy of HOMOLOG, you need to take them from the authors of these changes (consult the consultant).

2. Development:

• All changes to metadata must be done ONLY in ATUSX.
• Write the required code.
• In the course of development, it is essential to keep the consultant informed about the task (what part of the work has been done, what is to be done, what difficulties there are with implementation).
• If in the development process it turns out that there is a logical error in the specification, discuss it with the consultant. It is always necessary to write a comment in the JIRA task. The consultant should also write in the comments in the JIRA task, what exactly with this error in the specification must be done.
• If a functional error is detected during development, it is necessary to discuss it with the architect, also documenting everything in the comments.
• Before assembling the patch, you need to discuss the result of the development with the consultant and make sure that exactly what the consultant had in mind is written.
• Until testing by a consultant, the code in TFS is not released.

3. Testing:

• Primary testing should be performed on a local copy of HOMOLOG on the test card specified in the JIRA task.
• Based on the test card, write a test script for automated testing (code + csv) and test its operation.
• The developer tests the secondary testing on the Pretest server after installing the patch. In this run, you need to check that the patch includes all the necessary changes and also pass the entire test card.
• Perform a task test with a consultant on the Pretest server. In doing so, collect a maximum of information on the task that needs to be corrected.

4. Formulation of the task:

• After testing with the consultant and fixing all detected errors and shortcomings, you must perform a TFS Check-in of the modified and / or generated code.
• Specify the TFS Check-in in the JIRA task and close it.

Bug fixing

As part of the correction of the error, the developer must:

1. Bug fixing preparation:

• Update the source code on your local machine from TFS.
• If necessary, deploy locally the latest copy of HOMOLOG, located in the internal server.
• Before you start correcting an error, you need to make sure that it is reproduced. If not, discuss this with the author of the error.
• If the development affects (changes) already existing code, lock this code in TFS.

2. Bug fixing:

• All changes to metadata must be done ONLY in ATUSX.
• Write the required code.

3. Testing:

• Primary testing should be performed on a local copy of HOMOLOG on the test card specified in the JIRA task.
• The developer tests the secondary testing on the Pretest server after installing the patch. In this run, you need to check that the patch includes all the necessary changes and also pass the entire test card.
• Perform a task test with a consultant on the Pretest server. In doing so, collect a maximum of information on the task that needs to be corrected.

4. Formulation of the task:

• After testing with the consultant and fixing all detected errors and shortcomings, you must perform a TFS Check-in of the modified and / or generated code.
• Specify the TFS Check-in in the JIRA task and close it.

Common developing rules

1. If you need to change standard part of source code:

• Be sure that source code that must be changed exists in current Russian branch. If not, ask your team leader to add it.
• All changes in standard source code must be done only for Russia (cPaisLoc = “RUS”).
• When you change something in source code that includes .CH, be sure that this .CH files are included into patch. If not, try to change those files with no structural or functional damage (change something in comment).

2. Functionals:

• Always use xFilial() function to filter or position tables.
• Allow only one return call per routine at the end to avoid duplicates with closing areas, errors with committing or rolling back transactions, etc.
• Use i18n() function to work with texts.
• When you implement some algorithms always determine its speed. Think how much time it will take if there will be 1 million of records to do. Try to reach at least O(NlogN) speed. It can be made by avoiding inner loops (FOR inside FOR, etc.), recursive calls having full stack of parent attributes, etc.
• Avoid using EXIT in LOOPs.

3. Naming & variables:

• Follow TOTVS naming rules for files, routines and variables names. Especially if you add routines inside standard source code.
• If you create new file that belongs to Russia, create common one that will have template for Russian calls in case of sharing existing functionality.
• All declared variables must have defined types.
• Be sure that there’s no unused variables in routines.

4. DB:

• Do not use ChangeQuery() function for Russian part of code in case of SQL queries. It doesn’t work properly with PostgreSQL. Use FWPreparedStatement() class instead.
• To avoid possible errors every line of combined SQL query must start from space “ ”.
• Use RetSQLName() function to get proper table name instead of direct constants: RetSQLName(“F45”) instead of “F45T10”.
• Always try to minimize running time between beginning and committing transactions. Try to do all preparations before opening transaction.
• To avoid deadlocks always lock records in tables in the same order.
• If you need to write master-detail data, try to do it in one transaction to avoid deadlock.
• Always try to optimize queries. If you need to calculate aggregations do not make additional DB queries, use temporary tables or single query requests with options like ROLLUP, CUBE and similar SQL options (GROUPING if you need ONLY aggregations).
• Never use additional functionality provided by particular DB creators in queries instead of standard Transact-SQL to avoid migrating related errors.
• In case of performance never forget to put into query fields that are defined in the index you use.
• Always use xxx_branch in your queries otherwise indices will not work.
• Do not use direct changing commands (Insert, Update, Delete, Trim) for common tables. It is possible for temporary tables only.
• Create temporary tables only with FWTemporaryTable() function.
• If temporary table was created with FWTemporaryTable() function, do not forget to use CloseArea() function to eliminate it.
• Avoid to use CTE in queries cause data only growth with time and CTE properly working with small amount of data.
• When routine clear temporary tables be sure that it will clear only data that was added by current session of this routine. Be aware that same temporary tables can be used by more than one user, even if this temporary table was created in same routine (if it was created without FWTemporaryTable() function).
• Regarding previous tip try to avoid deleting temporary tables. Use creation only if table not exist yet.
• Do not forget to add to WHERE or ON d_e_l_e_t_ = “ ” condition.
• Use conditionals in ON section instead of WHERE when you use JOINs to optimize query running time. There’s a chance that built-in optimizer will be switched off on customer server.
• Try to avoid RIGHT or FULL JOINs.
• Look for more tips here.

5. MVC:

• Always separate MODEL / VIEW / CONTROL.
• Newer create validation that looks at VIEW.
• Never put business rules in MenuDef() functions.
• Always create BrowseDef() function.
• Do not make conditionals with descriptions like: If cName == “ENGINE”.
• Try to avoid loading many records at once. There is very small chance that user will update all of this.
• Do not forget that automated tests running without views, so always use Help() function instead of MsgDlg() or similar.

Best practices

1. In the browser, always add a list setting ("Show All", custom column settings) such as in the client directory.
2. If the table is Exclusive, then always display the branch on the screen.
3. In the browser (list), always display the branch and company in a concise manner, save space.
4. In the document browser, always display the internal and external number, the external date of the document (if any) or a different date, the total document amount (gross).
5. Always provide automatic numbering of the elements of directories and documents (if there are no special enumerators).
6. Numbering of documents (external), as a rule, should begin with 1 every year
7. When printing documents, delete leading zeros in the document number (external number).
8. In documents, there must always be an internal unique number (identifier). It is not allowed to build keys to external numbers.
9. In forms, combine fields that are close in meaning to groups so that they do not leave.
10. If there are a lot of fields in the title of the document, break them into bookmarks by meaning. The most necessary - on the first tab, technical, but visible - on the last one.
11. If there are a lot of columns in the table section, then break them into bookmarks in meaning.
12. In forms, hide fields that depend on the type of operation (from some parameters). For example, if we use a payment order for both banking and cash transactions, depending on the type of account (bank or cash desk), display and hide fields.
13. For all fields that contain data from another directory or document (usually code), by default add a magnifying glass so that you can go to the view (through the loop or through F3) of the data in this directory or document. The magnifying glass should be available not only in the editing or adding mode, but also in the playback mode.
14. In forms (in headers), display not only codes, but also the names of requisites. For example, the consignee in the invoice is good to see not only by code, but by name.
15. Under the number columns of the tablespaces, the default values are always added by default.
16. Always provide for the copying of a directory entry or an entire document.
17. Always display document statuses (legend).
18. In the document header, always display the branch to which this document belongs.
19. Display currency and contract explicitly (in logistics documents)
20. If the document has a quantity and price, provide for automatic calculation of the amount.
21. The number must be 3 decimal places by default.
22. Monetary indicators should always be with 2 decimal places.
23. Always calculate, store and display totals for lines (Gross) with VAT and for the document as a whole.
24. Always provide for copying rows of documents that are filled manually.
25. When autocomplete table parts of documents, always provide for the initial reasonable sorting of the rows.
26. To be able to save documents as drafts with their subsequent completion (for example, another user) and only after that the formation of movements and postings.
27. All processed (calculated) sum data in documents should be saved, and not always be calculated on the fly.
28. When designing tables, always think about the performance of future reports that will use this data. Do not inflate the number of lines unnecessarily.
29. If you have linked documents, you can switch to viewing from one document to another and back (for example, through the "Other Actions" menu).
30. Provide that the postings can be deleted (indicator of the presence or absence of transactions)
31. Provide for the re-generation of postings on the same document, so as not to delete the entire document and create new one, if something went wrong with the postings.
32. Always provide for the possibility of deleting a document and all its movements in the current period or reversal of the document in subsequent periods. Reversal means the formation of the same movements in the tables, but with the minus sign (and not the reverse, do not replace the proceeds with the minus when you reverse the sale from the supplier).
33. If there are related documents, always check the deletion logic or reversal. Most likely, you need to first delete the dependent documents, and only then - the document-basis. For example, first an invoice (VAT), and then - a commercial invoice.
34. After the subsequent documents have been deleted, the source document must be available for processing, as if there were never any subsequent documents. For example, after deleting a payment order, an application for payment can be included in another payment order.
35. Filters and search in lists should be user-friendly. Do not require users to fill out codes, indexes, and other technical information. Search should be on text fields, ideally - with a choice through a magnifying glass. For example, it is now impossible to select a branch in the list selections via F3
36. Do not ask users unnecessary questions. For example, when you open a list of invoices for review, do not ask how they are going to generate the transactions. In most cases, users will not add or modify anything, they just went to view the data.
37. Error messages should always be informative, what exactly is wrong
38. Translate all into Russian - menus, fields, parameters, help.
39. In report parameters, queries are always by default not "from ..." and "up to ...", but arbitrary selection (as selection of branches in reports with flags in random order).
40. In the report header, always display the data of the applied parameters (dates, branches, selections, etc.)
41. In reports, provide a column No. of the default.
42. In reports, calculate the width of columns for large data, provide for the transfer of text lines, and for monetary indicators - hundreds of millions of rubles.
43. Reports always include a reasonable sorting of the rows.
44. Date format in reports should be DD.MM.YYYY
45. The format of monetary indicators should be with 2 decimal places (always with zeros, even if the amount is without kopecks), press to the right margin of the field (the report cells).
46. For large reports, provide for printing the report header on the following pages
47. Waiting for the user to lock any table is completely unacceptable
48. For the time when the user is editing an object of the main data, the change to the object must be blocked. Another user should not be able to start changing the same object at the same time (a corresponding message should be issued with the name of the user blocking the object). In this case, you can open this object in the preview mode - it can without restrictions. The creation of a new object should also not interfere with the parallel creation of another such object.