0. General rules

0.1. Your environment should be prepared properly.

0.1.1. What is properly prepared software and hardware you may read from manuals on this site like

1. Troubleshooting-related points on RK7 manager station

1.1. Database backup function

1.1.1. You are able to make an archive of the main RK7 files (considerably less in size than these files in regular archive) by using backup function.
1.1.1.1. Go to service -> data backup :

1.1.1.2. Choose files to back up :

1.1.1.3. Wait until the process completed and take the archive .rk7bak created :

1.2. Parameter "Debug messages"

1.2.1.Enable special codes to get additional information to log files. These additional logging covers all RK7 applications.
 
1.2.2. To make the application add the additional information set to its main log file, restart it. Turning off Debug messages requires application restart also.
1.2.3. Debug code list.

1.3. Log settings

1.3.1. Printing

1.3.1.1. Set path to store logs in "Print log path" property of cash server.

1.3.1.2. Enable "Log all" in logical printer properties [Printing] section.

1.3.2. Interfaces

1.3.2.1. As many applications use RK7 interfaces (XML is the most popular one), as you have to take logs on "intermediate" data processors.
1.3.2.2. XML interface logging described in 4.2.

2. Troubleshooting-related settings in RK7 files

2.1. TestMessages parameter

2.1.2.1. Set "TestMessages=" parameter value to "1" in [NEtKern] section of faulty appplication .ini file to gain extended information.
2.1.2.2. By default, there is no parameter "TestMessages=" in RK7 .ini files, that operates the same as "TestMessages=0" (no additional messages).

2.1.2.3. Enables low level network debug messages (your log will be full of them, use in case of network connection/stability problems).

2.2. listKeys parameter

2.2.1. "/listKeys" parameter given to server on start (like /desktop parameter, etc.) will output Guardant key number to log file of that server.

2.2.2. This might help when determining licensing issues (like "Bad key number" error) or remote licensing.

3. Additional test, monitoring and auxiliary applications for RK7

3.1. I_Test.exe

3.1.1. This application tests export from RK7 to StoreHouse4. It shows you the data that go from RK7 report server to SH4 ImportRK.exe application.
3.1.2. Download this application from ftp://ftpint.ucs.ru/dealers/rk7/ForDealers/TOOLS/I_TEST/ .
3.1.3. The I_TEST.exe has its configuration file rk7tosh4.ini with the following format (the same as importer):

3.1.4. This application is simple and looks like below.

3.1.5. Mind using proper SHTR.DLL.

3.1.6. This utility may show you real data that comes from RK7 to importer software.

3.2. XMLtest

3.2.1. This application is designed to fulfil RK7 XML interfaces testing (send request and get result).

3.2.2. Description is in 4.1. of manual.

3.3. RemoteFM

3.3.1. This application can view and transfer files from cash station to any PC, which is on the same network with its cash server (both for DOS and Windows).

3.3.2. You could take this application files from RK7 distributive \BIN\RemoteFM\ folder.

3.3.3. remotefm.ini

3.3.3.1. File format

3.3.3.2. Settings description

3.3.3.2.1. "ROUTER=" is the cash server network name.

3.3.3.2.2. "NAME=" is the Remote file manager (self) network name.

3.3.4. To see and transfer file(s) from\to cash station you have to set proper cash server in remotefm.ini and start RemoteFM.exe.

3.3.5. To use this application in case of several cash servers, create separate copies of remotefm.ini settings. You are able connect only to those cash stations which has "Remote access->File manager path" parameter filled in its properties in RK7 manager station (put asterisk to make the whole filesystem available).

3.3.6. After pressing "File manager" you are able to operate in this application main form.

4. Technical support

4.1. Subjects

4.1.1. Follow "who is who" manual to ask proper persons proper questions.

4.1.2. Do not ask several people the same questions simultaneously. Save their time to help others.

4.1.3. If you are already sure that you have got technical problem because of an error in software (not settings), make a task on technical support site (http://tracker.ucs.ru/).

4.1.4. Before creating any new task you have to make a search on tracker site if similar task exists. In case there is at least one issue with the same general idea, do not create new task - add everything to the existing one.

4.1.5. If your issue substance devoted to some development ideas, uncertain matters (like: "something wrong - we don't know what"), reflection, questions "how to install" and so on (not exact errors in software) - do not open tracker issue! In such cases ask for assistance by means of e-mail, skype, telephone, forum, etc.

4.1.6. If you install some software for the first time and get some error, that is in most cases because of wrong configuration - follow 4.1.5. than.

4.1.7. Make a search of your issue not only on tracker, but on support site also. In many cases Support nodes give you a lot of ideas on how to solve trouble or on how to find the roots of trouble.

4.1.8. You have to confirm that your problem can be reproduced with newest available (from UCS file server) software versions before father tech support requests.

4.1.9. In case of hardware-related issues you should test with another hardware of the same type and with another drivers available, change port or other environment.

4.1.10. For questions and errors or settings of external (non-UCS made) software - get information from outside UCS! Our programs utilize many DBMS, other programs made by other companies - we are not going to spend time consulting on others software usage, except minimum found in our manuals necessary to install them.

4.2. Objects

4.2.1. Give the complete information about the problem you have got. Complete information includes: problem date and time; object names; object codes, consequense of actions to get error.
4.2.2. Point software versions you use. In case of several applications point the version of each one. In case of module-related issue - specify driver/module versions also.
4.2.3. Attach log files. This means both regular (automatic) and manual logs.
4.2.4. Attach INI and other settings files. We need both settings file where you've made changes and not, but which is being used by the applications involved. Especially if you expect us to follow your error, you must give all your settings to reproduce them absolutely the same.
4.2.5. Attach language files. In multilingual cases attach all languages. Provide another translated objects, if any, and environment (OS) language settings.
4.2.6. Attach databases. Usually we need only internal DBs, but if your problem depends on external DBs, attach them also then. To do that you must learn from installation manual(s) what database(s) being used by applications interacted.
4.2.7. Point DB credentials. This also means that we need all logins and passwords that you used to approach the error.
4.2.8. In case of such an applications as: MobileWaiter7, KDS, Rk-Order, Delivery, Webmonitoring - and others which overall files are less than 40 MB, attach full operational folders archives.

4.2.9. Full operational folders must contain: ini (settings), log, workdata, DB, dll, exe, xml and all the other files! Do not include what you like, include ALL files - we will decide which we need use.

4.2.10. Intermediate workdata files must be attached showing those operations which gave errors (for example, if you have got error on 1 order saving and no error on other one, you must give us both numbers, datetimes and content).

4.2.11. Attach all licenses that was used by you for all applications interacted in failure process.

4.2.12. If you don't know what to attach - put all that you have.

4.3. Tracker

4.3.0. Before creating your issue (new), search for solution in existing issues.

4.3.1. When creating an issue on tracker.ucs.ru guess and attach all necessary files without additional request.

4.3.2. If the issue evidently cannot be resolved without additional files (most cases), UCS tech support won't consider its resolution or even will close that without any comments.

4.3.3. Do not give external links to download any files, attach all necessary files directly to the task. If those files are huge, use multipart archives.

4.3.4. Point external links where to read specifical information concerning your language or local settings, but not to download files.

4.3.5. Your new issue name (summary) must contain the request reason unique description (that makes your task different from the others already exist), short exact and specific sentence that makes it possible to mark your task out of thousands by the main idea and case evidence. UCS tech support won't consider the task resolution if it's named like "problem with RK7".

4.3.6. You may send reminder using built-in "send reminder" option, by skype, e-mail, etc., but it is forbidden write meaningless (for the task essence) messages inside the issue itself (like 'up', 'when will you resolve', so on)!

4.3.7. As you tried those self-support methods from below before creating your new tracker issue, you need to specify in it what have you done and show reslts.

4.3.8. Your new issue must a priori answer the following questions:

4.3.8.1. What's wrong in current system behaviour (tie actions of user with faulty results)?

4.3.8.2. How system must behave correct  way, what you expect from software and hardware and why?

4.4. The way we help

4.4.1. You issue observation may take much time if you haven't provided all necessary information mentioned above. As full problem description given from the beginning - as fast solution you may expect.

4.4.2. In case of tutorial shortcoming detected during the problem analisys or your appeal had 'how to' nature - the "fix" will be put to 'Support' manual and you will be given a link to.

4.4.3. Do not ever expect get copy of that information already published to UCS web pages by e-mail or skype or tracker - you always get link to read that only.

4.4.4. If you were given link to read - you have to follow that. If you ask the same question, to which answer exist in given by link location, repeatedly, - do not expect somebody will reply you anything until you prove to read that and still cannot resolve the problem.

4.4.5. You must have skills in IT: Operational systems and networks on at least system administrator level - before you started to work with UCS software. We refuse answering general IT knowledge questions to you or train you computer basics because being software engineer is highly qualified professional field that you must already fit.

5. Remarks

5.1. Self-support

5.1.1. Try as many possible ways of solving the problem yourself as possible before asking for UCS-Moscow assistance.

5.1.2. Usually in your log files you may find understandable problem description. Eliminate errors then.

5.1.3. Use general method "change as many things as possible" until the problem is gone (make changes in settings, versions, environment, etc. until you find the smallest difference between working and erroneous configurations).

5.1.4. If you suffer from connection problem, check your network first. Also find out firewall rules, port translation, address and name singularity.

5.1.5. Use "compare with source" method to find changes in files and folders between two states, like different in time (for example, to find temporary files created or permanent files changed during program uptime, so on).

5.1.6. Use test software mentioned to examine working processes in details and find missed points. You have to understand how the software organized from installation manual.

5.1.7. If you have shortage of general IT skills (see 4.4.5) - fill in the gaps in one's knowledge outside UCS and before working with out software.

5.1.8. If you can find newer software version of faulty UCS software ̣̣(in UCS FTP), you should upgrade and test it (on copy of your faulty system, in the same environment). Update to newest version is the common method required by technical support.

5.1.9. In case your problem appeared at customer side, you should try to reproduce this situation in your dealer office showroom and make conclusion.

5.2. Need of complete information

5.2.1. Try to get as much information as possible to give to tech support.

5.3. No need to give redundant files and information

5.3.1. In most cases, if you are going to send some files according to 4.2., you should try to repeat an error with clear log and temp files in order not to give huge files with a great number of unnecessary information.

5.4. Must know things

5.4.1. All those information about UCS software that could be found in manuals on this site is obligatory to learn by those people who work with this software.

5.4.2. This paragraph also means that you must got this information from manuals if you managed to forget it.

5.4.3. You have to know the purpose of every file in application folders. This could be found from installation manual (if not - ask tech support by mail to add info).

5.4.4. Written above also means that you must know in which files application saves log inforamation for troubleshooting.

6. Useful third-party software

6.1. TCPview

6.1.1. In most cases modern applications work over TCP protocol. Often you need to check if some port is being listened by some application or free to use, or has been connected already from particular host.
6.1.2. If you are not sure about how some application uses its network functionality, see OS processes in TCPview.exe (utility by Microsoft Sysinternals, http://technet.microsoft.com/en-us/sysinternals).

6.1.3. In this utility it is advisable to turn off address and port resolution to names (to see only figures).

6.2. Process Monitor

6.2.1. This application gives you information about any software activity in given environment.

6.2.2. For example, you may find out which path was used to load additional modules.

7. Frequently made mistakes

7.1. Broken links

7.1.1. In many cases people set (or do not change to correct one preset) wrong settings of pathways, file links, folder links, filenames, etc. This configuration makes program cannot find corresponding files or folders, hence cannot run its functions.

7.1.1.1. For example, RK7 stations use preload.exe-related update mechanism and started using .bat (batch cmd script). But this script utilizes windows (normally preset) application usage (xcopy.exe). Some windows editions have got no xcopy application -> that's why .bat script will fail to do file copying, but successfully renamed old files - and your RK7 station will fail to start without necessary DLLs.

7.2. Wrong file format

7.2.1. In many cases when somebody edited some (settings) file, he made it wrong formatted (not correct tags, parameters, comments, etc.) and not valid to be read and used by the application.

7.2.2. One cannot make accidental changes in settings file format (.xml or .ini , so on) that brake its strict section and parameter structure - one must do changes carefully.

7.3. No valid license

7.3.1. There are several variants of this omission.

7.3.1.1. Not entered/saved license at all. Even not got that from UCS. Many installers forgot that almost no any UCS software could work without license.

7.3.1.2. Wrong license type/code/quantity/etc.  You must have valid license for the specific software operation conditions: number of stations, users, periods, so on.

7.3.1.3. Changed dependent hardware/software settings. In many cases you get license for specific Gurdant key, PC configuration, etc. You cannot use this license in other environment conditions - you have to get new one.

7.4. Network configuration changed

7.4.1. As it follows from installation guide, you must use static addressing for all our servers.

7.4.2. In many cases other people change network settings and UCS software stops working. 

7.4.3. In order to be able to prove somebodys fault you have to make full backup after have set working configuration by yourself - you will have compare source than.