SytelineMaster

Open the component class “UserDefinedType”, go to validator, add one more parameter %2 to the UserDefinedTypeValue validator.

Open the validator, make sure %2 is there.

Then open the property of the validator.

Open the Parameters screen

Set %=Description in Set Prop/Var/Comp section.

OK all the way back to save the change in Component Class.  Now we have component class “UserDefinedType” ready to show description of user-defined-type as second parameters.

To use the component class, just put the field that you want the description display on as second paramenter of component class.  Here is sample,

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_%’

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

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

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.

3) Restore it to Test/Training DB.

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

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

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.

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.

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.

Here is the way to check a form’s mode in script.

If Instr(1, ucase(ThisForm.Caption), “(FILTER IN PLACE)”) > 0  Then
ReturnValue = “-1”
Exit Sub
End If

General Concept:

• Customer amounts will be stored in the customer’s currency. This effects CO, Estimating, and AR.
• Vendor amounts will be stored in the vendor’s currency. This effects PO and AP.
• Cash accounts in Bank Reconciliation may be stated in non-domestic currencies. When receiving customer payments or making vendor payments we may specify the payment with either domestic currency or the customer/vendor currency.
• All journal. Ledger, inventory ( price & cost) and shop floor amounts are always stated in domestic currency.

NOTE: Therefore when amounts are posted into journals they are translated.

PO & AP:

• Gain/Loss – When exchange rates increase over time (foreign currency per one unit of domestic currency), we record a gain and when exchange rates decrease, we record a loss.
• Entry – PO header & line/release casts are entered and stored in the vendor’s currency. Whenever these amounts are defaulted from the Item master, they are converted using the current exchange rate.
• Receiving – At receiving time, we record the amount received, cost, and exchange rate. We post domestic amounts to the journal using this exchange rate.

Account Numbers Posted (PO Dist):

• Debit- Inventory account
• Credit- Vouchers Payable

Generating Voucher (PO) & Posting Vouchers (AP) – When we create the voucher record, we store any change in exchange rate from Receiving time to voucher generation time as a distribution. The voucher is stored in the Vendor’s currency. When the Voucher is Posted, domestic amounts are posted to the journal and vendor amounts are put on the Posted Transactions record along with the exchange rate that was used for posting.

Account Numbers Posted (AP Dist):

• Credit – Accounts Payable
• Debit- Vouchers payable

Payment – Payments may be entered in either Domestic Amount or Vendor’s amount based upon the currency code of the Bank Code you select for the payment. When the payment is posted, domestic amounts get posted to the journal, and vendor amounts are put on the Posted Transaction record. At payment posting time, we perform a mini-gain/loss for the voucher and any payments or adjustments to that voucher. All of the Posted transactions tied to the voucher will be “upgraded” to the new exchange rate
Account Numbers Posted (AP Dist):

• Credit – Cash account (Payment Amt @ new rate)
• Debit – Accounts Payable (Voucher Amt @ old rate)

Voucher’s Gain/Loss posted to either Loss (Debit) or Gain (Credit)

CO & AR:

• Gain/Loss- When exchange rates decrease over time ( foreign currency per one unit of domestic currency), we record a gain and when exchange rates increase, we record a loss.
• Entry- CO header and line prices are entered and stored in the customer’s currency. Whenever these
  amounts are defaulted from the item master, they re converted using the current exchange rate.
• Shipping- At shipping time, we record the amount shipped, price, and exchange rate. We post domestic amounts to the journal using this exchange rate.

Account Numbers Posted (CO Dist):

• Debit – Cost of Good Sold
• Credit – Inventory

Invoice Printing (CO) Posting (AR) – When we create the invoice record, we store any change in exchange rate from Shipping time to invoice printing time as a distribution. The invoice is stored in the Customer’s currency. When the Invoice is Posted, domestic amounts are posted to the journal and customer amounts are put on the Posted Transaction record along with the exchange rate that was used for posting.

Account Numbers Posted (AR Dist):

• Credit – Sales (Invoice @ Old rate)
• Debit – Accounts Receivable (Invoice @ new rate)

Payment – Payments may be entered in either Domestic Amount or Customer’s amount based upon the currency code of the Bank Code you select for the payment. When the payment is posted, domestic amounts get posted to the journal, and customer amounts are put on the Posted Transaction record. At payment time, we perform a mini-gain/loss for the invoice and any payments, debits or credits to that invoice. All of the Posted transactions tied to the invoice will be “upgraded: to the new exchange rate.

Account Number Posted (AR Dist):

• Debit – Cash (Payment Amt @ new rate)
• Credit _ Accounts Receivable ( Invoice Amt @ old rate)

Difference to currency Loss (Debit) or Gain Account (Credit)

Gain/Loss Utility

At various times, users may wish to recognize any outstanding Gains or Losses. They may run this utility and specify either AR,AP or both.

AR – We process all Posted A/R Transactions and upgrade them to the current exchange rate. For each invoice that has a gain or loss, we post the amount to Accounts Receivable and the Gain or Loss Account.
AP- We process all outstanding PO Receipts (received but not yet vouchered) and upgrade them to the current exchange rate. For each record that contains a gain or loss. We post the amount to Vouchers payable and the Gain or Loss Account.

We process all unposted vouchers and upgrade them to the current exchange rate. For each voucher that has a gain or loss, we post the amount to Vouchers Payable and the Gain or Loss Account.

Gain/Loss Accounts:

• Users establish account records for Gains and Losses.
• The Gain Account is always used to record gains due to exchange rate changes.
• The Loss Account is always used to record losses due to exchange rate changes.

Currency Master:
SyteLine contains a currency master file where all currencies are maintained. Users may enter an unlimited number of date & time stamped currency exchange rates. They may also back-date these rates by entering a past date. There are two exchange rates entered. The Buying rate is used exclusively in PO and AP. The selling rate is used exclusively in CO, Estimating, and AR.

Financial Statements:

Users are able to print Financial Statements in different currencies. Prior to SYMIX 4.0, they could only accomplish this when they were consolidating multiple divisions. The “final” Financial statement would be printed in the currency of the division running the report. The exchange rates used to convert the data were the ones stored in the division running the report. Now in V 4.0, users can choose which currency they wish to print their financial statements in. The exchange rates used to print the report are the rates stored in the database that contains the ledger records being processed. The translations are for display purposed only. No posting of any kind takes place & no gain or loss is calculated.
Translations are defined for each line of the financial statement. Users choose to use the Buying or Selling Exchange rate. They choose a translation method: None ( no translation), Spot ( historic rate for each transaction), Current ( current exchange rate), Average Period ( weighted average exchange rate in effect for the accounting period for each transaction), End of Period ( exchange rate in effect at the end of the accounting period for each transaction)

Basically, this is handled through a 3-Step Process. Cut the check to the vendor, designating it as an Open payment. Receive and voucher the purchase order. Reapply the open payment against the voucher generated. Below are the steps for handling this process.

The process for handling Deposits or Pre-Payments to Vendors is as follows:

1. In the A/P Payment form, add a new record for the vendor
On the Payment Distribution form, select type “Open”
If Purchase Order Number is known, you can link the PO to this Open Payment. When check is printed, it will update the Prepaid Amount field on the Purchase Order Header.
Note: The account that defaults for the Open Payment comes from the default “Deposit Acct” from the Accounts Payable Parameter. This account change be overridden if needed.
Print and Post the check as normal.

2. When purchase order is received, generate voucher as normal from the Generate A/P Transactions form
Perform Voucher Posting to post the voucher to vendors A/P Posted Transaction Details

3. Reapply the Open Payment to voucher generated from Purchasing.
Determine the original check number of the deposit or pre-payment. (This can be found on the A/P Posted Transaction Detail form).
Open A/P Payment form
Enter a new record for the vendor, flag the record as “Reapplication”
Enter the original check number in the check number field
System will automatically recognize this as a “Reapplication”. The original amount should default in the payment amount. Save.
Either through Quick or Distribution, select the voucher/vouchers where the deposit or pre-payment needs applied against. Save.
Go to the A/P Check Printing/Posting form and perform Final Register and Post
Journal entries will be created reversing the amount from the “Deposit” account and applying it against “Accounts Payable” account

NOTE: Open Payments should NEVER be applied to vouchers via the A/P Posted Transaction Details form. Journal entries are not created from this form.

A refund check has been received from a vendor and you need to enter it into SyteLine, the following are the steps that you should take to complete this process:

1) Go to Customer Maintenance and add a new customer record with the Vendor’s information.
2) In AP, you currently have a voucher and a payment on this vendor record. At this point, you need to decide whether or not you want this refund reflected in AP Posted Trans. If you’ll never repay this and don’t want the vendor’s balance due to increase, then you won’t enter any transactions on the AP side.
On the other hand, if you will eventually pay them back this amount, then you’ll want to adjust that payment amount, so that this refund is reflected on the voucher. In order to do that, you want to go to Vouchers and Adjustments and create an adjustment voucher against the voucher number, for the amount of the refund (should be a positive amount).
3) If you created an adjustment voucher in step (2), then you’ll need to process Voucher Posting to post that adjustment. If you didn’t, proceed to step (4).
4) In AR, create an invoice for the amount of the refund, using the new customer number that you created.
5) Perform Invoice Posting.
6) In Customer Payments, enter a payment for the new customer number, using the check # and the amount on the refund check.
7) Use Check Posting to post the payment.
Now AR has a zero balance.

Recurring Vouchers are designed to handle repetitive vouchers each month, where basically, only the Invoice Date, Distribution Date and Due Date change each month. The steps to set up a Recurring Voucher are as follows:

1. Open Recurring Vouchers form (in SL4, SL5 and SL6 go to Vendor – Recurring Vouchers) New (or add)
   Enter the Vendor Number
   Voucher (allow system to assign the next voucher number)
   Distribution Date (defaults to current date. This date will be designated at time of Recurring Voucher Generation for new vouchers)
   Invoice Date (this is the date of the month that will be used for subsequent vouchers generated)
   Due Date (automatically calculates based on terms of vendor and invoice date)
   Purchase Amount (the amount of the voucher that will be generated each month)
   NOTE: This amount may be updated after the recurring voucher has been generated if needed. If amount is updated, the distribution amount will also need to be updated
2. Voucher Distribution
   Add the necessary distributions to fully distribute the Purchase Amount of this voucher

With the steps above, you have created your template voucher. You can now generate this voucher for a new month as needed. The steps to generate the Recurring Voucher are as follows:

• Open A/P Recurring Voucher Generation (in SL4, SL5 and SL6 go under Vendor – A/P Activities – Recurring Voucher Generation)
• Select the range of vendors who have recurring vouchers created, or leave blank to generate for all vendors
• Enter new month of voucher (example, you created the recurring voucher in February, and want to create a voucher for March. The new month would be 03)
• Enter new voucher year (this will only occur when generating vouchers for January)
• Enter Distribution Date (this will be date the voucher will be posted in the GL)
  Process

NOTE: You can review and update these vouchers in A/P Vouchers and Adjustments prior to posting.