SytelineMaster

There is no simple way for reports to be cancelled from the client in Syteline 7 and 8. The Cancel button for Print Previews only kills the client part of a Preview. The background task continues to run on the TaskMan machine (The TaskMan machine is typically the Utility Server where the TaskMan process is running.)

There is only one way to kill an individual report. When TaskMan starts a report or an EXE it fills in the Process ID field on the Background Task History form with the Windows Process ID. Log on to the TaskMan machine with the same account TaskMan runs under (or an Administrative account). Bring up the Windows Task Manager. On the Processes tab, select the PID. The Image Name will be RunReport (RunReport.exe) for all reports. Click the End Process button.

If the report is running a stored procedure, simply killing the RunReport process on the Utility Server will not kill the SQL process running within SQL Server. However, identifying this process is more complex. There are generally two main approaches.

1) The simple approach is to stop and re-start the MSSQLSERVER service under Administrative Tools on the SQL Server Box. Or simply re-boot the SQL Server box. However, these approaches will stop all databases and would disrupt business. So they are only appropriate after normal business hours or on a test system. Additionally, once the databases are running again, you would need to re-boot the Utility Server in order for it to properly re-connnect.

2) The more specific, less disruptive approach is most complex. You would need to go into Enterprise Manager, expand the Management folder, expand Current Activity and select Process Info. You would then sort the processes by database so you can reduce the number of processes to examine. You would then right-click on each process in that group, look at the properties and attempt to identify the stored procedure associated with the cancelled report. Most likely, you would only be able to make an educated guess as to what that stored procedure might be based on parts of its name sounding related to the type of report that was killed or cancelled. Once you have identified the process, you can then right-click on it and select Kill Process.

3) The following recommendations may assist with getting the information required to kill the SQL server process associated with the ‘bad’ report.

Firstly, log into Syteline and open the Background Task History form and review recent tasks that are currently in a Running status. For each running task, review the parameter detail information searching for the report or utility that was submitted with no Starting and/or Ending data parameters. Parameters are not labeled, so you may need to look at the Report screen to see what options are available and compare them to the parameters listed in the Background Task History form.

Once you know the Syteline report which is suspected of consuming SQL server resources, open Query Analyzer on your SQL Server, select the App database from which the report was submitted, and run the following query:

SELECT scn.ContextName, scn.ProcessID, ci.UserName
FROM SessionContextNames scn (readuncommitted)
LEFT OUTER JOIN ConnectionInformation ci (readuncommitted)
ON scn.SessionID = ci.ConnectionID
WHERE ci.ConnectionID IS NOT NULL

The above query will return a list of SQL server processes and the associated Syteline information. The column ContextName should return the Syteline form that initiated the process. Search the list of displayed ContextName records for the report which you identified from the Background Task History form. Identify the specific process associated with the desired form and User, and note that ProcessID.

You can then kill the process by running the following in Query Analyzer:

kill spid

where spid would be substituted with the ProcessID value returned in the query you ran. For example, ‘kill 109’.

Please note that killing the process will rollback the transaction so if it has been running for some time, it may take some time for SQL to rollback the transaction and for SQL server resources to return to normal usage levels.

The purpose of the Lead Time Processor (LTP) utility is to calculate an item’s fixed and variable lead times using the operations that make up its current routing. The fixed lead time is expressed in days. The variable in hours and is the run time for 1 piece.
Basic Algorithm
If you answer "No" to the "Use WC Calendar" and "Use Offset Hours" options, the LTP totals the run time for each operation in the routing and posts the result into the item master variable lead time field. If the work center is machine or machine and crew scheduled, the machine hours are accumulated. If it is purely crew scheduled, the labor hours are used.
If you leave the Shift ID blank it totals the move, queue, setup and finish hours for each operation, divides the total by the default shop calendar average hours per day and posts the resulting number of days into the item master fixed lead time field.  If you enter a Shift ID, the move, queue and finish hours are divided by the average number of hours per day from that shift rather than the default shop calendar.  The Shift ID field was added for the fix to APAR 107859 in the SQL versions (SL7 and higher).     
The variable time is adjusted by the operation efficiency (lead time / oper eff / 100) and work center utilization (lead time / wc util / 100).
If an operation has a value in the "Fixed Sched Hrs" field, that figure is added to the fixed lead in place of using the setup and run time.
Item master lead times are used by a number of functions in the system. One of the most important is the MRP module’s passing of planned orders from parent to component. The date assigned to the material requirement is calculated as:
PLN due date – (((PLN qty * var lead) / default shop cal hrs per day) + fixed lead)
The "Use WC Calendar" and "Use Offset Hrs" options exist so that the system’s lead time calculations will be more accurate if your are using operation overlapping and multiple shop calendars with varying hours per day. The following explains the how using those two options will affect the calculations.
Use WC Calendar
The "Use WC Calendars" option was designed to handle the situation where the various operations in an item’s routing use work centers that are tied to different shop calendars that have a varying number of hours per day. If you do not use this option, the LTP uses the hours per day from the default calendar when converting the fixed hours to days.
If some of the operations in the item’s standard routing had more (or less) hours per day than the default calendar, the date MRP arrives at when passing planned orders will often be different than the date at which scheduling would arrive since scheduling considers the extra (or less) time available in those work centers.
If you answer yes to the option, the LTP factors in the variable length calendars by calculating a "calendar factor" for each operation that does not use the default calendar. This factor is calculated as:
(avg hrs per day from default cal / avg hrs per day from oper’s calendar)
The resulting figure is then multiplied by the fixed and variable times for the operation in an attempt to compensate for the extra hours available per day. e.g. if an operation that uses a 10 hour/day work center has 1 hour per piece of run and the default calendar has 8 hours, there will per .8 hours added to the cumulative variable lead time for the item than 1.
Use Offset Hrs
The "Use Offset Hrs" option gives you the ability to factor the operation offset hours into the lead time calculations. If you answer "No" to the option, the LTP simply accumulates the setup and run for each operation as described above. This assumes each operation starts when the previous finishes and gives no consideration to operation overlapping which MAPICS handles with the Offset hours field.
When you answer "Yes" to "Use Offset Hrs", the algorithm changes dramatically in an attempt to compensate for the overlap. When the LTP encounters an operation with offset hours it will deduct the previous operation’s fixed and variable times from the running totals and add in the current operation’s offset to the fixed running total.
Basically, this means that the system will assume that the current operation’s offset is the duration of the previous operation. It will NOT change the actual values in the move, queue, setup and run hours fields of the previous operation.
For example, suppose you have an item with a typical lot size of 100 with 3 operations, each with 1 hour per piece of run time. Operations 20 and 30 have offset hours of 10 which means the begin 10 hours after the start of the previous operation.
If you elect not to have the LTP consider offset, it calculates fixed hours of 0 days and variable lead of 3 hours. When MRP passes a planned order for 100 it uses 300 hours (100 * 3 hr var lead) which comes to 38 days. When the planned order is turned into a job, the scheduling system would use the offset and arrive at 130 hours which is 16 days. The results in MRP showing the materials being needed 21 days earlier when the planned order is being passed then it will when the job is created.
Since operation 30 "covers" all but the non-overlapped time of operations 10 and 20, the offset hours from 20 can be considered a fixed duration for 10 and 30’s offset can be considered a fixed duration for 20.. Since offset does not vary with quantity, it makes sense to store this offset as fixed lead time.
In this example, if you tell the LTP to consider offset it would use operation 20’s offset of 20 hours as fixed time for 10 and ignore 10’s variable time. It would then use 30’s offset and use it for 20’s fixed and ignore 20’s variable. This would result in variable lead if 1 hour (30’s variable) and a fixed lead of 3 days (30 / 8 = 2.5 rounded to 3).
For a planned order for 100, MRP would pass the order using:
(100 pieces * 1 hr var lead) + 3 days fixed = 16 days
Using these two options, there may be a small difference between MRP’s calculation and scheduling’s calculation but it will certainly be more accurate than if not using them. It is important to realize that MRP is a planning tool, not a scheduling tool and cannot be expected to be as precise as the scheduling algorithm. To have MRP "schedule" each planned order using the item’s current routing would not be feasible purely from a processing time perspective.

For Report Previews to work, the SL 8 Click Once Client needs to authenticate to the Utility Server Syteline directory where the reports are actually generated.

Click Once Client users only require internet access to the Website to download the Click Once Client. They do not need network permissions to access the directory on the Utility Server where the Previews are generated to.

For Click Once Client users on the domain, you can adjust the security on the utility server directory to give the user’s access to the SyteLine report output directory:
C:\Program Files\Infor\SyteLine\Report\OutputFiles  

For Click Once Client users outside the domain and/or firewall, clients may not be able to download and the run the Click Once client unless changes are made to the client’s HOSTS file.  You may receive an error similar to the following when accessing the click-once URL: 

* [11/29/2007 1:24:54 PM] : Activation of http://10.21.1.46/SLClientDeploy/SyteLine.application has started.  ERROR DETAILS
   Following errors were detected during this operation.
* [11/29/2007 1:25:16 PM] System.Deployment.Application.DeploymentDownloadException (Unknown subtype)
– Downloading http://sline_utl1/SLClientDeploy/SyteLine.application did not succeed.

Resolution

One way to resolve this is:  On the user’s computer running the Click Once client from outside of the domain, you will need to edit the file C:\WINDOWS\system32\drivers\etc\hosts. 
For example:

After the line:
127.0.0.1 localhost
Add the line:
10.21.1.46 SyteLine_UTIL1

Another way to resolve this is: Create an IIS Virtual Directory, is to create a virtual IIS directory on the Utility Server. Windows 2003 as follows:

On the SyteLine utility server, open IIS Manager
Right click Default Web Site
Select New>Virtual Directory
Name the folder ‘SLReports’ and designate the directory path C:\Program Files\Infor\SyteLine
Virtual Directory Access Permissions were set to READ, WRITE, and BROWSE.
Open Intranets form and go to the Reports/Taskman tab
Enter http://<servername>/SLReports in the Report URL field
or use http://ipaddressofserver/SLReports

On Windows 2008:

Right click Default Web Site
Select Add Virtual Directory
Set Alias as SLReports
Set Physical Path to the installation directory, usually: C:\Program Files\Infor\SyteLine
This should create the Virtual Dirctory for you. Click on it. In the middle pane there should be a Directory Browsing icon, double click that
In the right hand pane here, click Enable.
In SyteLIne, open Intranets form and go to the Reports/Taskman tab
Enter http://<servername>/SLReports in the Report URL field
or use http://ipaddressofserver/SLReports

Changing the Report Logo for Syteline is fairly easy.  Just place a new SLHeaderLogo.bmp (your company logo) in the C:\Program Files\Infor\SyteLine\Report\Reports folder in the utility server.

If you have multiple Syteline configurations for differ branch companies, and want to use differ logos, you can create folder under the above Reports directory.  Make the folder name matches exactly the configuration name, and put the logo inside the folder.  Syteline is smart enough to pick them for each configuration.  The same thing applies to report customization too.

Use the following script to shrink/truncate SQL database log file

USE [Database_Name]
GO
ALTER DATABASE [Database_Name] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC SHRINKFILE(DB_Log_File_Logical_Name, 1)
ALTER DATABASE [Database_Name] SET RECOVERY FULL WITH NO_WAIT
GO

Use the following script to check the file size.

USE [Database_Name]
GO

select name,  size from sys.database_files

When you try restoring a SQL database, you may get an error message saying “Exclusive access can’t obtained, database is in use”.   First, of course, stop all Syteline service, like IDO, Taskman.  If it still doesn’t work, try the below to set it to single user mode

Use Master

Alter Database Database_Name  SET SINGLE_USER With ROLLBACK IMMEDIATE

You may run Exec sp_who2 to see the user connection to database.

If this still doesn’t work, try detach/reattach the database.

Tax system 1, set to be area tax

Tax code

17% VAT tax for normal product and goods.

3% VAT tax for small enterprise.

There may be 5% normal business tax (not VAT, not deductible)

Vendor

Customer

Customer Order Header

Purchase Order Header

Amount tab, cost amount has excluded tax.

There are just so many cost related fields in item table.  I here try to map them out one by one with fields in Item Cost Form

Purchased Current Unit Cost:

cur_mat_cost

cur_duty_cost

cur_freight_cost

cur_brokerage

cur_insurance_cost

cur_loc_frt_cost

Manufacturing Current Unit Cost:

cur_matl_cost

cur_lbr_cost

cur_fovhd_cost

cur_vovhd_cost

cur_out_cost

Unit Cost

matl_cost

unit_mat_cost

unit_duty_cost

unit_freight_cost

unit_brokerage_cost

lbr_cost

fovhd_cost

vovhd_cost

out_cost

Unit_Cost

Unit Cost

Current Unit Cost:  cur_u_cost

Unit Cost: unit_cost

Assembly

asm_setup

asm_run

asm_matl

asm_tool

asm_fixture

asm_other

asm_fixed

asm_var

asm_outside

Accumulated

comp_setup

comp_run

comp_matl

comp_tool

comp_fixture

comp_other

comp_fixed

comp_var

comp_outside

Standard is from frzcost table.

In order for output print out in Chinese correctly, you will need to set up the font in Language ID form for zh-CN

When creating a new Syteline financial Statement, it is much easier to work on a copy of existing statement report, instead of starting from scratchy.  You can certainly use the Excel export/import to do the copying, but one part of the financial statement line, the total tab, would not get copied over that way. 

Syteline Financial Statements are stored in the following tables.

1) glrpth   statement definition

2) glrpthc   statement columns definition

3) glrptl      statement lines definition

4) glrptls    statement lines definition, total tab, line add up

5) glrptlc    statement lines definition, total tab, column defined.

By using Excel import, only the above 4) would not get copied over correctly.  You may use the following script to get the copy completed.

insert into glrptls
(rpt_id, seq, from_seq, to_seq, total_add)
select
‘New_Report_ID’, seq, from_seq, to_seq, total_add
from glrptls  tt1 where tt1.rpt_id = ‘Old_Report_ID’

One thing to remember, before running the above script, re-set sequence for both new and old report, make them both start from 10 and increment by 10.  This is to ensure both have the identical sequence.  Or, better yet, before you do the Excel import/export, re-set the sequence in old report.