SytelineMaster

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.

SOLUTION #1 – This is to be used if you are UPGRADING from a previous SL7.0x version, and applying a Service Pack.  This is NOT to be used if you are ONLY applying a Service Pack to the same SL7 version.

Before you begin the upgrade, please review your Client Configuration Names go to Start>Programs>MAPICS>Tools>Client Configuration Manager. The Syteline Client Configuration names will be listed on the left.  Each Syteline Client Configuration consists of xxxx_app and xxxx_forms ( see your Syteline Client Configuration Manager for the names of your databases)
**Always make a back up of your xxx_app and xxx_forms database prior to executing any Service Pack or Upgrade so that you have a restore point to go back to if you run into problems.
In this example the Syteline Client Configuration name prior to applying the Service Pack is called "Live". This Syteline ‘Live’ Configuration consists of Live_App and Live_Forms databases.
1. Uninstall your current version of SL7.0x
2. Install the new version of SL7.0x
3. To prepare for FormSync create a SQL backup of Live_forms database and restore the back up as the name temp_forms
4. Execute the SyteLine Configuration Wizard on the Utility Server and create a new temporary Client Configuration called "SP#Temp". (for example if you are installing SP09 for SL 7.03 then the naming convention of the configuration would be named ‘SP09Temp‘). This new configuration will consists of Live_app and temp_forms databases respectively.
5. Run the Upgrade – to affect all configurations.
6. Apply the Service Pack to the "SP#Temp" configuration, but do NOT apply the Service Pack to "Live".
7. So far Live_app and temp_forms have been upgraded and service packed, but Live_forms has only been upgraded, not Service Packed.
8. At this point you have a choice. You can either create a brand new Forms database and use the SyteLine Configuration Wizard to connect that forms db to the SP#Temp configuration, or you can proceed with the upgraded SP#Temp configuration as it is. In theory they should both now contain all the new Vendor level forms and objects. If you want to avoid any doubts of getting only the latest vendor versions of objects however, the safest option would be to create a brand new forms db.
Now you are ready to run FormSync.
Select the SOURCE: SP#Temp configuration (temp_forms db or brand new forms db)
Select the TARGET: Live configuration (live_forms db)
Click Synchronize.
EXAMPLE: SL 8.00.00 apply Service Pack 10
Source = SL8.00.10 forms database created after SP10 was applied to the Database Server (new forms database)
Target = SL8.00.00 – This is the live forms database that you have all our customizations located in (old forms database)
Notice, you NEVER apply the service pack to the "Live" configuration and therefore the live_forms database was never service packed in this process. FormSync applied the changes to Live_forms database. You can now run the "Live" configuration at the new service pack level.
To Verify the version of a Syteline Database
There is a table named ProductVersion that is updated when the Service Pack is applied. Open each database (app and forms) and select Tables, on the right hand window find the ProductVersion table. Right click on the ProductVersion table and select Open Table>Return all Rows. The version listed should match the service pack level you just installed.

Note

See Related Primus:
Form Sync Utility – Newest Version
FAQ – Form Sync
Form Sync Utility Configurations on two Servers

In Formsync under OPTIONS there are settings for handling form customizations and then a different setting for Global objects. It is important when doing a formsync to consider the options chosen for Global objects. Global objects include any scripts used on a form, PropertyClassExtentions, ComponentClasses, Validators, Variables and Strings. If you have made a change to any of these global objects they can affect more than just one form, so the choice to either keep or remove customizations in any global objects is VERY important. Wherever possible try to avoid making changes to standard SL scripts. Scripts can NOT be merged by formsync. You either have to accept the Vendor changes (and thereby remove all your customizations to the script) or you keep your version of the script and lose all the bug fixes that went into the vendor version of the script. As a rule, changing standard Global objects in Syteline is not recommended. If you must change a global object, then rather create a NEW global object with a copy of the original, and make changes to that. For instance, instead of making changes to the standard script named ‘EnableDisable’, rather copy the script, make your changes and name it ‘EnableDisable_mycompanyname’. Often you can accomplish the same things through Events and inline scripts or Events calling a custom stored procedure from a form using the SP! method.

Form Sync when Forms databases reside on two separate SQL Servers
Click Here for details: