Archive

Archive for January 17th, 2011

Copy the User/Module Authorization from one Syteline DB to another DB

January 17th, 2011 No comments

If you have hundreds users, manually rebuilding the User/Module Authorization will be painful.  The below query will copy over the User/Module Authorization from source DB to target DB.  Just run it against your target DB.

insert  modulemembers (objecttype, objectname, modulename, originalmodulename, modulememberspec)
select objecttype, objectname, modulename, originalmodulename, modulememberspec
from [Your_Source_DB_name].[dbo].[modulemembers]
where objectname like ‘OS_%’

Search Store Procedures

January 17th, 2011 No comments

If you even need to find out all store procedures that contain certain phrase, such as “PurchaseOrders”, the following query will help.

select so.name, sc.text from syscomments sc inner join sysobjects so on sc.id = so.id
where so.xtype = ‘P’ and sc.text like ‘%PurchaseOrders%’

This can be extended to other object type, for example ‘TR’ for trigger.   Here is a list of object type.

AF = Aggregate function (CLR)

C = CHECK constraint

D = DEFAULT (constraint or stand-alone)

F = FOREIGN KEY constraint

FN = SQL scalar function

FS = Assembly (CLR) scalar-function

FT = Assembly (CLR) table-valued function

IF = SQL inline table-valued function

IT = Internal table

P = SQL Stored Procedure

PC = Assembly (CLR) stored-procedure

PG = Plan guide

PK = PRIMARY KEY constraint

R = Rule (old-style, stand-alone)

RF = Replication-filter-procedure

S = System base table

SN = Synonym

SO = Sequence object

Applies to: SQL Server 2012 through SQL Server 2016.

SQ = Service queue

TA = Assembly (CLR) DML trigger

TF = SQL table-valued-function

TR = SQL DML trigger

TT = Table type

U = Table (user-defined)

UQ = UNIQUE constraint

V = View

X = Extended stored procedure

Categories: Development, SQL Tags:

Copy Production DB to Test/Training DB

January 17th, 2011 1 comment

If you are a Syteline administrator, you will often need to refresh your Test/Training database with update-to-date Production database.

The most common way for copying DBs in SQL server is to use the backup/restore function.

1) Bring down all Infor service.

2) Backup your Syteline production database.

In SQL management studio, right click database name, task-> backup.

image

3) Restore it to Test/Training DB.

In SQL management studio, right click database name, task-> restore –> database.

image

Select source from device, give it the backup file location and file name.

Click Option.  Select the “Overwrite the existing database” option.  Provide the restore to DB

image

4) Once the restore process is done, right click on your Test/Training database name, go “Property –> File”.  Make sure the database owner is sa.  If it is not, change it to sa.

5) Run the below command to your Test/Training database.

ALTER DATABASE dbname SET TRUSTWORTHY ON

6) Bring back all Infor service.

7) Login to your Test/Training Syteline system.  Go to Site/Entities form, change the “Database Name” and “Form Database Name” to correct name.  Since this is a copy of your production database, it carries that Production DB name over, and you will need to change them to correct Test/Training DB name.

image

8) In a multi-site environment, there are a few more steps need to be completed.  First, if you are using intranet licensing, you may have problem login, even with sa account.  Need to do the following in SQL.

1.  Temporarily disable any replication for the Site Admin category in the database to prevent any later updates from replicating over to the production database. This is generally only an issue if the test, pilot, or development database is housed on the same server as production, but I would strongly recommend disabling replication under any circumstances to avoid any possible unexpected issues.

To disable replication for Site Admin, run the following in SQL against the database that has been copied over:

update rep_rule set disable_repl = 1 where category = ‘Site Admin’

2. With replication disabled in step 1, now update the site record to temporarily disable intranet licensing, which should allow the ‘sa’ user to login without error. To disable intranet licensing, run the following query in SQL:

update site set IntranetLicensing = 0

9) Now, you should be able to login with sa account.  Complete the above step 7) to update the DB name.  This need to be done for all sites.

10) If the Site name is differ between your production and pilot environment, you need to run the “Change Site Name” utility to correct the site name.

11) Finally, regen Replication Trigger.

12) Once all the updates are finished, replication triggers are regenerated,  you should be able to return to the Sites/Entities form and re-enable Intranet Licensing for all sites, and then do the same for Disable Replication in the Replication Rules form.

13) Update the license

Done.

How Syteline uses the item master lead times

January 17th, 2011 No comments
Overview

There are four lead time fields in the Syteline item master: fixed, variable, paperwork and dock-to-stock. The fixed, paperwork and dock-to-stock leads are expressed in days and the variable is expressed in hours (run time per piece). For purchased items, they must be manually entered. For manufactured, they can be either manually entered or you can use the Lead Time Processor utility which populates the fixed and variable fields using the times in the item’s current routing .
In general, purchased and transferred items will have a fixed lead time and perhaps a paperwork and dock-to-stock but no variable. Manufactured items will typically have a fixed, variable and perhaps a paperwork but not a dock-to-stock. The following is an explanation of what functions in the system use lead times and how they are used. It is broken down by manufactured vs purchased items.
NOTE: All calculations of dates involving item master lead times are done using manufacturing days (M-days), not calendar days. For example, when the system deducts 10 days from an end date to arrive at a start date, it is actually counting back 10 M-days

Manufactured Items

The lead times for manufactured items are used to estimate job start dates and material requirement dates, which are essentially the same thing. That is, you need the material at the start of the job. The calculation used for manufactured items to arrive at a projected start date is the following. The .499 is added before the integer function (which rounds) is used so that it always rounds up to the next full day.
start date = end date – fixed lead – integer((var lead * qty / hrs per day) + .499)
The following functions use this calculation:
1) Job Creation
When you manually add a job, you must enter either the start or end date. Whichever you enter, the system arrives at the other using this calculation. When you use a system feature which creates a job, the end date defaults from the source record’s due date and the start is calculated using this formula.
Manually add a job
Firm a PLN to job from the MRP Detail Display
Firm MPS to job from the MPS screen
Add a production schedule release
X-ref and create a job from CO line item
X-ref and create an estimate job from an estimate line
X-ref and create job from a transfer order line item
X-ref and create job from project resource
2) MRP passing requirements
When a parent item has a PLN or and MPS receipt, the system passes it to the materials in the item’s current BOM to create PPLN and PMPS requirements for the materials. The date assigned to those requirements is calculated with the above formula using the MPS or PLN due date as the “end date”.
This calculation is also used to pass job requirements to the job’s BOM if the MRP parameter “Use Dynamic Lead Time” is No (or not checked). In that case, the item master lead times are deducted via the formula from the job’s “MRP End” date.
3) MRP Order Action report
The order action report reads through all planned orders and prints those that need to be released. The report deducts the item’s lead time from the planned order due date using the following calculation which differs from the one given above in that paperwork lead and dock-to-stock are both also deducted. The report prints the PLN if the resulting “Release Date” is less than the “Ending Date” entered on the option screen. The paperwork lead is included since that is time before the start of the job which must be accounted for when releasing planned orders. The dock-to-stock is included since the report uses the same calculation for purchased and manufactured items but while have no impact since it should be zero for manufactured items.
release date = PLN due date – fixed lead –
integer((var lead * PLN qty / avg hrs per day) + .499) –
dock-to-stock lead – paperwork lead.

Purchased Items

For purchased items, the lead times are used to either calculate a PO release date when starting from a due date or to calculate a PO due date when starting with release date. The specific functions which use lead times for purchased items in one way or another are the following:
1) MRP Order Action report to calculate Release Date
Used as described above for manufactured items. The variable lead is used in the calculation but will typically be zero for purchased items.
2) Firming a PLN from MRP
When you firm a planned order from the MRP detail display, the system deducts the item’s dock-to-stock lead time from the PLN due date to arrive at the PO line (or PO requisition line) due date. The PLN due date is the date you need to issue the material to the job so the dock-to-stock must be deducted from that date for the PO due date.
3) X-ref and create PO from a job material
Same logic as item 2 applies here. The dock-to-stock is deducted from the operation’s start date if not blank or the job’s start date if the operation’s is blank.
4) “Matl Chk FWD Sched” algorithm
Enabling the “Matl Chk FWD Sched” SFC parameter causes the scheduling routine to potentially move out the start date of operations if it determines that purchased, non-stocked materials cannot be available by the desired start date. If the material is not tied to a PO line item, determines when it can be available by adding the item’s lead times to the current date. (i.e. when can we have the material if ordered today?). If an item/vendor cross reference records exists for the item, the system uses the lead time from the number one ranked vendor. Otherwise, it uses item master lead times.
5) Calculating a “Release Date” displayed on reports
A handful of purchasing reports deduct the item’s fixed and paperwork lead times from the PO line due date and print the result in a “Release Date” column. The dock-to-stock is not deducted since it is assumed that it was already deducted from the true need date when arriving at the PO line due date. The reports which show this are the following:
PO Status
Purchase Requirements (if status is planned)
PO Requisition by Buyer
6) Calculating due date when manually adding PO
If you manually add a PO (or requisition) line and an item/vendor cross reference record exists for the item and the PO vendor, the default due date is calculated by adding the item vendor record’s lead time to the date listed below:
Regular PO line: adds item vendor lead to PO order date
Blanket PO release: adds item vendor lead to Rel Date entered
PO requisition: adds item vendor lead to Req Date
NOTE: Unlike the item master lead time field, the item vendor cross reference lead time should be expressed in calendar days, not manufacturing days. When used as described in this point and point 4 above, the item vendor lead is simply added to the one date to arrive at the other. That is, it does not count M-days as do the functions which utilize the item master lead times.
Transferred Items
For the item with a source of Transferred, the fixed and variable lead time fields are not used by the cross-site functionality. When the MRP module passes planned orders (PLNs) for a transferred item to the item’s supply site to become a TPLN requirement in that site, date assigned to that requirement is the due date of the PLN minus the Transit Time in the Inter-Site Parameter record. Also, when you firm the PLN into a transfer order the Transit time is also used for setting the line’s Schd Ship Date. The Schd Rcvd Date is set to the PLN’s due date and the Transit Time is deducted from the date to arrive at the Schd Ship Date.
However, the Order Action report does use the item master lead time to calculate the Release Date for PLNs. That release date is then used to determine if the PLN will display in the “Transfer Orders to be Firmed” section of the report. For that reason, it may be best to set the item master fixed lead time equal to the transit time from the item’s ship site for all transferred items.