1. Problems by areas


1.1. Data transfer from cash server to upper-level servers

1.1.1.0. Common shifts

1.1.1.0.1. In case you have problem with missing shifts/ missing data for some shifts, while other shifts have no problem, you should make comparative table. You have to compare wrong shifts with correct shifts.

1.1.1.0.1.1. You may start from opening rk7man.exe "Service" -> "Common shift information" in table view mode and arrange by casual parameter.

1.1.1.0.2. Comparative table is an electronic document (like .XLSX file) with columns and rows, having information both about nearest existing (no problem) shifts, and those shifts you expect to be there (to be correct), as you want them to be, but not correct in fact.

1.1.1.0.3. You make columns in comparative table according to your case, most common are: shift number, shift logical date, shift filename, shift status, comment...

1.1.1.0.4. Common shifts in RK7 data exchange are UDB files with accumulative data, made from work.udb on cash server "common shift close".

1.1.1.0.5. Common shift UDB files should be accumulated in report server database (check.udb + MSSQL).

1.1.1.0.5.1. Besides accumulative data, RK7 report server SQL DB has references data and changes register data (references log).

1.1.1. No shifts coming (seen from manager)

1.1.1.1. Check report server license and Guardant key.
1.1.1.2. Check SQL server (external DB) connection.
1.1.1.3. Check that data gathering is set in your report server properties for all necesssary cash servers.

1.1.1.4. Check that data gathering enabled on this report server ([Basic] section property).

1.1.1.5. Check cash server license.

1.1.1.6. Follow http://support.ucs.ru/en/node/5578 manual to clarify data exchange process in RK7.

1.1.1.7. Normally you copy missing shifts (*.udb files) by datetime from [MIDBASE]\Archive\ folder of each cashier server to [BASE]\filesync\incoming\ folder or each report server. This is manual common shift load and reload procedure.

1.1.2. Some shifts not showing data

1.1.2.1. Check if some error written to report server log or report function feature server log (IR) on shift file manual gathering (put to \incoming\ folder) and fix them.

1.1.2.1.1. As for IR, also check in IR plugin (for rk7man) logs.

1.1.2.1.2. Also check shift2sql log (in case it was used).

1.1.2.1.3. Check shift information in "Common shift information" reference. Delete it from DB as written in 1.1.5.

1.1.2.2. Enable this shift reloading if it already exists in 'Common shift' list before manual gathering.

1.1.2.2.1. In case you used additional wipe (delete data from DB), you must allow reloading of those shifts only after recover procedure as below.

1.1.2.3. Check if causal shift has got 'deleted' status and recover that one before reloading.

1.1.2.3.1. Do recover operation manually. Recover shifts using context menu of rk7man window "Common shift information".

1.1.2.4. Check data of casual shift in external DB (use some client application like MS SQL management studio), try 1.1.1. measures.

1.1.2.5. Import shift file(s) as in 1.1.1.7.

1.1.2.6. Recalculate cubes and recalculate agregates (IR) after shift data import finished without errors (as you check in logs).

1.1.3. Corrupted shift file (udb)

1.1.3.1. If you found that some common shift DB cannot be pumped in report server accumulative DB (or directly to MSSQL DB using shift2sql.exe utility), you have to check report server log for "error 714": corrupted shift tables.

1.1.3.2. You have to try getting this shift non-corrupted from another location (Archive of cash server, another report server).

1.1.3.3. If you cannot find necessary shift in another location or that file is damaged also, you have to try closing this shift again and getting shift file from cash server workbase backup on common shift close operation (file shXXXXXX.udb in folder \MIDBASE\Backup\).

1.1.3.3.1. shXXXXXX.udb is the renamed work.udb file made on common shift close operation (containing all sales for this shift), where "XXXXXX"= common shift number.

1.1.3.4. Save current work.udb before making this special restore operations. You must put it back to its place before proceed with work (new sales) on this cash server stations.

1.1.3.4.1. Create full manual backup of cash server files and folders before replacement operations.

1.1.3.4.2. Move all shift and workbase backups (archives) from this cash server "midbase" to some other location. You should do this because newly closed old shift(s) will be in conflict with existing shift files.

1.1.3.4.2. Move all shift backups (archives) from report server(s) "base"(s) to some other location. You should do this because newly closed old shift(s) will be in conflict with existing shift files.

1.1.3.5. Put necessary shXXXXXX.udb to \MIDBASE\, having renamed that to "work.udb".

1.1.3.6. Start this cash server and some station (connected to it).

1.1.3.6.1. Do any changes in currenty loaded shift if necessary using doscash GUI.

1.1.3.6.2. In case you fix corruption in UDB file do not operate here like on working station - do not change data or execute other operations.

1.1.3.7. Do 'common shift close' operation (button in GUI main menu).

1.1.3.8. Mind that you may need changes in driver settings (rk7man): turn off fiscal printer, for example, enable or disable external system interfaces - if they are interacted in common shift close processes (TimeKeeper, for example), or common RK7 parametes (maximum shift duration, for example).

1.1.3.9. Get shift file from \MIDBASE\Archive\ folder and try pumping that to report server DB (or wait for automatic data send finished).

1.1.3.10. Restore original work.udb, test that cash server works good as before.

1.1.4. Wrong data in shift (user mistake)

1.1.4.1. You can edit data inside some shift using backup restore with cash server DB replacement as shown above.

1.1.4.2. You have to find backup of this shift before closing on corresponding cashier server, start cashier server with this DB, connect to it with cashier station (or XML interface) and make changes. After that close shift again and restore current working DB. See 1.1.3.

1.1.4.3. In case you got wrong date or time in your shift and any other wrong data, you have to clean up data in report server(s) DB(s)  before closing adjusted shift.

1.1.4.4. There is UCS dealer service (another way) for making some changes in closed shift (UDB) files https://92.39.135.227/

1.1.4.4.1. For example, you can change "order category" there.

1.1.4.4.2. If you use this UCS web service, you do not need to follow 1.1.4.1. way.

1.1.5. Delete wrong shift data from DB

1.1.5.1. In case you got faulty common shift, you need to delete it from DBs before import correct data file.

1.1.5.2. "delete" shifts from DB using rk7man interface (set status DELETED on shift object)

1.1.5.3. wipe deleted data from DB using button "Wipe database" in "Service"->"Common shifts information" window (rk7man).

1.1.5.4. Additionally, move away or delete defective shift files from all folders of RK7 system.

1.1.6. Shift file has no closed state

1.1.6.1. In case you have non-closed shifts thus cannot be accumulated by report server (error: process error: can not load data from working base) you can close them as in 1.1.3. or use shift2sql.exe utility for import.

1.1.6.2. In case you do not have working cashier server, you can pump in data to SQL DB using shift2sql.exe + SQL script.

1.1.6.2.1. Use command line or .bat file script for running shift2sql.exe as follows:

C:\UCS\RK7\bin\win\shift2sql.exe "Provider=SQLNCLI11.1;Persist Security Info=True;Initial Catalog=REFDB;Data Source=127.0.0.1\SQLEXPRESS;User ID=sa;Password=123" "C:\UCS\shifts\sh00201.udb" C:\UCS\RK7\base\chckconv.xml

1.1.6.2.2. Use MSSQLMS and script like:

UPDATE GLOBALSHIFTS SET CLOSED=1,SENDED=1,IMANAGER=9001 Where SHIFTNUM>200 and SHIFTNUM<300 and MIDSERVER=15015

1.1.7. Shift file has wrong duplicating number

1.1.7.1. Technical support has tools to change common shift numbers. Provide shift files with duplicating numbers to UCS technical support for renumbering.

1.1.7.2. Stop using faulty numbering cashier server.

1.1.7.2.1. After closing current common shift, disable cash server object, create new cash server with new ID in rk7man.exe.

1.1.7.2.2. Make new rkeeper.ini file and new empty "MIDBASE" folder for new cash server.

1.1.7.2.3. Move all cash stations from old faulty to new cash server in rk7man. Apply all necessary interfaces and settings on new cash server object, assign other reference objects usages as they used to be for old server.

1.1.8. Shift gets wrong logic date

1.1.8.1. In case report server time was ever set wrong (future more than past), your report server accumulative DB (UDB and SQL - both) will save wrong logic date for next shifts.

1.1.8.2. You have to restore accumulative DB (UDB) from backup on the date before time failure

1.1.8.3. You have to recreate external DB (SQL) and re-export all references and shifts.

1.1.8.3.1. It is also possible to restore SQL DB backup (if you have) on some date before time failed + re-export references before connecting report server to this SQL DB version.

1.1.8.4. You have to import fixed shift files into report server DB, starting from that date, which your restored backup belons to.

1.1.8.5. You have to re-calculate cubes and agregates (IR).

1.2. Report building issues

1.2.1. Data is outdated

1.2.1.2. Recalculate all cubes or one of them manually and check status in cube properties.

1.2.2. Data is empty in cube or/and report

1.2.2.1. Check cube or agregate recalculation status in rk7man. Fix errors specified.

1.2.2.2. In case no errors in status - check if you have data in MSSQL DB. For that, take SQL query from cube or agregate properties and execute this query using MS SQL management studio.

1.3. External database connection issues

1.3.1. Cannot save reference changes

1.3.1.1. Try to login to SQL DB with Management studio \ IBexpert ; if no success  - restart DBMS.


2. Problems by symptoms


2.1. No data in reports (report is empty)
2.2. No data in reports (for some period) or difference with printed on cash station
2.3. Data of the same type in different reports are different