SytelineMaster

Parameters can be setup on the Accounts Receivable Parameters form. A Returned Check Fee amount can be entered there. They can also designate to create Debit Memo for the customer for the returned check amount, plus returned check fee amount.
In order to create a Debit Memo to send to the customer when a check is returned, follow these steps:

1) Go into Bank Reconciliations
Filter for bank code
Put cursor in bottom to add a bank rec
Add bank rec type "Deposit"
Transaction Number = this is the bank rec trans #, similar to manual check number. They can start with 100 and let system increment after that
Ref Type = A/R
Ref Num = Customer Number
Customer Check Number = check number returned
Amount = Amount of check
Bank Amount = Amount of check
Generate Returned Check Fee = Yes
Save the record

2) Open the Returned Checks form
Enter the bank code
Process Returned Checks = Yes
Preview – Process
They should see the record in the grid
Commit – Process
Debit Memo should have been created
If the check is re-deposited, the user can select the Process Returned Check Deposit option on the Returned Check form, and the system will create a credit memo to offset the debit memo.

For Businesses operating in Canada:

The Syteline system presumes that the main tax system (GST) will be setup as Tax System 1 with a Tax Mode of either Item or Area depending on the requirement of the province. The Syteline system also presumes that PST and HST will be setup as Tax System 2 with a Tax Mode of Area.

For any European Economic Countries and Australia:

The Syteline system presumes that the main tax system (Sales Tax or VAT Tax) will be setup as Tax System 1 with a Tax Mode of Item.

For the United States:

The Syteline System presumes that the main tax system (Sales Tax) will be setup as Tax System 1 with a Tax mode of Area.

The Parametric Sales Tax System allows the User to set up Tax Systems to change sales tax at the "Item" level or an "Area" level.
The Area Based Tax System, which applies to U.S. Companies, allow taxes to be charged at the header level, Setting up the Tax Codes entrails assigning tax rates to a State Tax Code. The flags "Include Price" and " Include Misc." Should be set to YES and the A/R tax account number needs to be defined.
Under the Area Tax System, if an item is tax exempt (as specified in the item master), the system will ignore the tax code at the header level and not charge sales tax. If the item is taxable, the system will charge tax based on the "ship to" customer’s tax code ( or the "bill to" if it is the same as the "ship to" customer). If a line item is "dropped shipped", tax will be charged based on the tax code of the "drop ship" customer. This will override the tax status of the line item and the header tax code. If the user wished a message to appear, asking if sales tax should or should not be charged based on the tax code of the drop ship customer, then the following two flags must be set to YES:
"Prompt on Line Item" flag on the Tax System screen. This flag will prompt that the item is taxable or non taxable at the item level of an order.
"Prompt for State Tax" flag on the Tax parameters screen. This flag will prompt that the item is taxable or non taxable in the item master sales screen and page two of the Customer Order Header.
The Item Based Tax System will mainly apply to Canada, UK and European countries. It allows sales tax to be charged at the item level and tax codes to be specified in the item master. (For example, the GST in Canada.) The system will look at the tax rate of the item and override the tax code on the header.
The Parametric Sales Tax System was designed to allow flexibility mainly for the European Community. Many of the fields and flags should be ignored ( or set to "NO") for U.S. Countries.
The following fields give a brief description of what all is involved with the tax structure. The fields with a * indicate they are relevant for the AREA based tax system ( U.S. Countries.)

I. GENERAL PARAMETERS:

• EC Reporting: "Y" Activates EC VAT information.

• ED Weight Conversion Factor: Converts Weight field in item file to kilograms ( unit weight on EC SSD.)

• Capitalize State: "Y" – Upper Case

II. TAX SYSTEMS: (File, System, TS) – Can have both tax systems working simultaneously.

• AREA (US Business) – allows tax rates to be entered at the header level.

• ITEM (European/ UK) – only allows tax rates to be entered at the item level. (Taxes based on each item of the sale -VAT.)

• PROMPT ON LINE ITEM- Will show the item is taxable or not at the item level of an order. Will also give y/n message to change "drop ship" tax codes per line item.

• PROMPT TAX CODE LABEL- Allows use of set up labels ( header).

• PROMPT TAX CODE ITEM LABEL- Allows use of set up labels (item).

• PROMPT AMOUNT LABEL- Allows use of set up labels (amount).

• TAX ID LABEL- (ex: Federal ID# on Vendor Screen)

• ACTIVE FOR PURCHASING- Can turn off Purchasing Side (normally "No"). Can be edited at the distribution level. (Primarily used for EC).

• USE WHOLESALE PRICE- Will cause a secondary Unit Price Field to be displayed/updated on the Item Master screen. (Calculates taxes in place of the "real" item master unit price.) Wholesale price used first.

• APPLY TO PROGRESSIVE BILLING- Indicates if taxes should be billed during Progressive Billing.

• RECORD ZERO RATED- "Y" if it is necessary to record/report transactions which have a tax amount of zero. (May be used for later reporting.) Ex: Selling children’s clothing (textile industry.)

• TAX ID PROMPT LOCATION- Enables/Disables prompting for the Tax ID on Customer/Vendor screens. (C,V,B)

• DEFAULT ITEM TAX CODE- Used for new items entered into the Item Master.

• AR/AP TAX CODE: Tax Code = That of the Customer Vendor.

• FREIGHT/MISC. TAX = AR/AP Tax Code default.

• DEFAULT CUST/VEND TAX CODE – Default for Customer/Vendor Screen.

• COMMISSION TAX CODE – That default rate will calculate tax on commissions.

• NON A/P TAX CODE – Will default to what is filled in for Non-A/P Payments.

III. TAX PARAMETERS

• Set to company’s specific reporting and functionality requirements.
• STARTING TAX PERIOD DATE – Stores the dates following the last submission of the VAT return and SSD report.

Usual Field Values For US:

• CASH ROUNDING FACTOR = 0 (If >0, "Cash Only Flag" is prompted on Billing Terms screen. "Y" will round final invoice to the nearest cash rounding factor.)
• PROMPT FOR TAX DISC. = NO; if yes, will prompt to only pay taxes on the final amount they are paying (after discount). Must apply to the Taxing Authority to qualify.
• PROMPT FOR PRICE INCL. TAX = If YES, tax is fixed in price when invoice is posted.
• PRINT TAX CODES ON INVOICE = "Y" prints tax codes on invoices.
• PRINT TAX FOOTER ON INVOICE = "Y" prints a Tax summary on invoices.
• *PROMPT FOR STATE TAX: YES – Will prompt for if an item is taxable/non-taxable in the item master. Will also give Y/N message to change "drop ship" tax codes per line item.
• TWO EXCHANGE RATES -Used for Multi-Currency.

IV. TAX JURISDICTIONS

Used to record where taxes are located. Allows the user to group the tax codes into Jurisdictions. Each tax code can be assigned a Jurisdiction. Ex: EC = FR (France UK) Tax ID in France. (Not applicable in US.)

V. TAX CODES

1 Set of Tax Codes per Tax System. * Choose between E (Exemption) or R (Rate).

• TAX AT ITEM LEVEL: (Item Master, Sales)
• TAXABLE BLANK: Taxed at Rate that is on the header (Tax Code Type = E (Exemption) or N – Not Taxable – That line item will not be taxed.)
• HEADER BLANK- Individual items get taxed at the rate set by the Tax Codes at the item level.
• HEADER-ZERO – Entire order is presumed tax exempt.
• ASSESS ON RETURN – Active for Vouchers. Indicates tax was never paid on the item and must be assessed at the time of return.
• DEDUCTIBLE – Active for Vouchers. Indicates that the item purchased is deductible from taxes. (i.e. Syteline user is not the end user of the item.)
• INCLUDE PRICE, DISC., FRT., MISC. – Y/N – What amount should be taxes?
• INCLUDE PRICE ON PREV. SYSTEM – Causes the tax amount calculated on Tax System 1 to be added to Tax System 2.
  * Tax Account # must be entered.

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.

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. 

This solution contains two options on processing returned items for rework, incorporating the returned item and costs into rework jobs for SL-ERP versions prior to SL8.

With the release of SL8 , job orders can be flagged rework josb by checking a Rework flag on the job order. This will allow recursive materials to be added to the job so the same material can be both the end item and a job material on the Rework job.

Resolution

Versions Prior to SyteLine 8 – Option 1:

1. Go to Job Orders and reopen the job by changing job status from "Complete" to "Released"

( For SL-ERP go to Production – Job Orders )
(For Symix go to Modules – Shop Floor Control – Job Orders)
2. Withdraw material returned by customer from inventory to the Job using a reversing job transaction.
NOTE: See solution 2003Syteline4586 for instructions on how to do a reversing job transaction.
3. Add Job Operation 999 (or some other operation number out of normal sequence on job) as the last Job Operation.
( SL-ERP and Symix go to View – Job Operations)
4. Post all materials and labor for rework process to the 999 operation.
(SL-ERP and Symix select Activities | Job Transactions for entry of labor transactions.)
( Select Activities | Job Transaction Posting to post labor to job.)
(Select Activities | Job Material Transactions to enter and post material issues to rework. )
5. Move reworked item into inventory and complete the job.

Note: If the original job is not in status of "History" and is in "Complete" status you can use this process.

Versions Prior to SyteLine 8 – Option 2

1. Create a new released job for the returned item that must be reworked.
(In SL-ERP go to Production | Job orders.)
( In Symix go to Modules | Shop Floor Control | Job Orders)
2. Enter a Miscellaneous Issue to remove the returned item from inventory with a reason code "REWORK". Your inventory quantities will be doubled for the item if this is not done since the return was received into inventory and the rework job is also received into inventory.
( SL-ERP , select Material | Inventory- Activities | Stockroom Activities | Miscellaneous Stockroom Issue.)
( Symix, select Modules | Material | Inventory | Activities | Stockroom Activities | Miscellaneous Stockroom Issue.)
3. Issue a material to the job that is not in the Item Master records which will be used to represent the returned item. You cannot add the parent item to the Job. This would be a recursive Bill of Material which is not valid in Symix/SL-ERP. Using an item not in the Item Master (for example, "rework-xxx" where xxx is the parent item) eliminates the recursive error message and allows you to enter an account numbers and costs associated with the returned item.
(SL-ERP and Symix, select Activities | Job Material Transactions.)
4. The Job BOM can be modified to account for the additional labor and materials required to complete the rework using Job Operations and Job Materials screens.

Note: If original job has been changed to "History" status, you will need to use this suggestion.

SyteLine 8

1. Enter a job for item to be reworked

2. Check the rework job flag on the job order header. This flags the job as a rework job.

3 Add a job material to the job that is the same as the job end item.

4. Issue the Material to the job. (This recursive job material cannot be flagged as backflushed and must be issued to the job using the Job Material Transactions form. If the material is serial tracked, the serial number status must be "In Inventory" so that it can be issued to the rework job. Once this material is issued to the job, the serial number status is "out of inventory". This serial number can then be used to move the end item back into inventory when the rework job is complete.

5. Continue processing the job adding additional material and labor as needed.

6. Perform a Job finish to move the end item to inventory.

Additional information concerning this new functionality:

MRP and APS planning will ignore any rework jobs with no defined routing\ bom structure and will not use the current bom structure for the end item on the rework job. Rework job end items are treated as planned receipts. Components that are same as job end item are not processed as a material requirement.

The Copy Routing/BOM utility will not create sub jobs if the "from" job is flagged as a rework job. Rework check boxes have been added to the Copy Routing/BOM utility for the From and To jobs.

The Job Pick list does not allow auto issue materials for rework jobs. This gives the user more control on issuing materials to the rework job.

Data collection allows the processing of recursive material on rework jobs.

The Job Split Utility sets the new job flag for rework job on the split job the same as the original job rework flag.

The Job Merge utility requires both jobs to have same setting for the rework job flag.

Rework jobs for lot and serial tracked items are supported.

No changes for Costing were implemented. The Rework Job WIP Cost is equal to the Job Cost less the recursive material cost. Standard Costed items will generate variances.

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.