Payroll Generation: pr/pr-trxg.p, main logic in pr/pr-trxg1.p
Payroll record prlog can be generated from 4 differ sources:
Manufacturing transaction jobtran. The Generate Payroll From field on the Employee Master must also be set to M. The summarized transactions include: WC Labor, WC Machine Time and Job Labor. prlog.posted-from = “M”.
Manufacturing Project transaction projtran. The Generate Payroll From field on the Employee Master must also be set to M. prlog.posted-from = “M”.
Time and Attendance record timeatt. The PR From field must also be set to T. Total Hours are calculated on the time between clock-in and clock-out with all break times subtracted out. After each time & attendance transaction is summed to the Payroll Transaction record, the time & attendance transaction status is changed from Unposted to Posted. prlog.posted-from = “T”.
Attendance transaction prhrs. When the reason code is set to Vacation, Holiday, or Sick, the record is treated as if it were the Vacation, Holiday, or Sick record entered into the Payroll Hours file. prlog.posted-from = “P”. Noted that prhrs record got deleted after the process (prlog created.)
The table contains MPS is rcpts with the ref-type = “M”. rcpts also contain other records that generated by MRP. To remove any MPS demand, remove rcpts records with ref-type = “M”.
Landed costs may be added to purchase order lines in order to receive estimated costs for freight, duty, and brokerage into the inventory value of an item. Each of the separate landed cost components may be paid to the purchase order vendor or to a different vendor. Landed cost capitalization is available for both actual and standard costing.
Landed cost setup requires accrual accounts in the Purchasing Parameters file and a landed cost inventory adjustment account in the Product Code file for those inventory items for which landed cost is to be activated.
To set up Purchasing Parameters: File ->Parameters->Purchasing ->Purchasing Parameters ->Edit->Update
Enter accounts in the following fields – Freight Payable Acct, Duties Payable Acct, and Brokerage Payable Acct
To set up Product Code file account: Modules ->Inventory ->Item Master ->View ->Files->Product Codes ->Product Code – Miscellaneous
In each product code record, enter an account in the Landed Cost Inv Adj Acct field
To use Landed Cost functionality, add Purchase Order and PO lines. Assign estimated costs and vendors for freight, duty, and brokerage:
(From PO screen) View -> Landed Cost ->Edit ->Update
Add a Freight Vendor and Frt Alloc Type. Freight, duty, and brokerage may be calculated using either percentage of cost or a fixed amount.
These costs are then allocated over all lines on the PO by one of the following three methods:
Cost: The total cost for the PO and the proportion of each PO line’s cost to the total cost will be determined. The estimated landed cost amount will then be allocated across all PO lines according to the same proportion.
Unit: The total number of units for the PO and the proportion of each PO line’s units to the total number of units will be determined. The estimated landed cost amount will then be allocated across all PO lines according to the same proportion.
Weight: The total weight for the PO and the proportion of each PO line’s weight to the total weight will be determined. The estimated landed cost amount will then be allocated across all PO lines according to the same proportion (weight field stored in the Item Master General screen). The following points are important when using weight:
Zero weight items will have a zero landed cost assigned
Weight allocations will not be allowed if all PO lines have zero weight
Weight units of measure will not be considered, therefore, incorrect allocations could result when weight units of measure are mixed (ie – lb and kg)
Enter estimated freight charge if the allocation type is Amount or add a percentage if type is Percent
Repeat for duty and brokerage charges
Perform allocation by selecting Activities, Allocate Landed Cost
These amounts will then be reflected in the Unit Cost field on each PO line. When the PO is received, these amounts will be added to the cost of the item received into inventory if an actual cost item, or be considered in a variance calculation if a standard cost item.
The calculated landed costs may be overridden by the user from the PO line by selecting “Update Costs” in the Edit-Update mode, and entering a new value in the appropriate landed cost fields. The “Overridden” box will be marked. Any lines marked as overridden will be ignored on subsequent allocations and the costs for the overridden lines will be subtracted from the landed cost estimate for the PO.
Vouchering Landed Costs
At the time of purchase order receiving, two purchase order receipt records will be created, one for material costs and one for landed costs. Once an invoice has been received from a vendor, generating vouchers for the landed cost receipts is done in the AP module.
Enter the vendor from which the invoice is received. Enter the invoice number and actual amounts for duty, freight, and/or brokerage charges.
Receipts to be paid by this invoice may be selected by a combination of sorting criteria, including the Selection Method, Landed Cost Type, and Receipt dates
Choose a Selection Method as follows:
S to display landed cost receipts for only this vendor
O to display landed cost receipts that do not have a vendor assigned
SO to display both
Blank to display landed cost receipts for all vendors within the date range
Choose the Landed Cost Type as any combination of (D)uty, (F)reight, and/or (B)rokerage
Enter beginning and ending receipt dates to narrow down the selection
All landed cost receipts that match the selection criteria will be displayed. Select the lines to be included in this voucher by utilizing the selection options under the edit menu. Highlight each line to be chosen, and then Edit-Select/Select All/Deselect
Highlighted lines may be updated to indicate the actual amount to be paid to the vendor (Frn Trans Amt) and whether or not variances should be recognized at this time for the receipt (Final = Yes). A landed cost variance is calculated when the estimated landed cost is different from the vouchered landed cost. “No” should be selected in the “Final” field when less than the entire quantity is vouchered. When the balance is vouchered on a later invoice, “Yes” should be selected in order to recognize the variances. If the entire PO line has not been received and “Final = Yes” is indicated in this screen, an error message will prevent the user from posting this line as final.
After the selection process is complete, select Activity – Generate Voucher. Vouchers are posted to the Vouchers and Adjustments file.
In the Purchasing module, the Landed Cost Variance Report is available to assist in analyzing variances.
Any credit memo created in SyteLine from a credit return or price adjustment invoice will automatically be created as an open credit. Debit memos created by price adjustment will also be open. Only when creating a credit or debit through AR you are given the opportunity to dictate which posted invoice the transaction is to be applied to at the time of creation.
To “clear up” open credits, debits and payments in Accounts Receivable Posted Transactions the open items must be applied to one or more invoices. Credit memos and debit memos cannot be selected for payment and therefore can remain on an aging report as an open balance causing some amount of trouble in reporting as well as causing aging reports and other reports to take longer to run.
The reapplication process for each transaction type will be addressed individually.
Credit and Debit Memos – One to one
To reapply a credit or debit memo to a single invoice navigate to the AR Posted transactions screen and follow these steps. Prior to doing the steps for reapplication review the transactions for the customer and determine in advance where you want to apply the credits.
Put focus (cursor) on the credit/debit memo to be applied.
View the detail for this transaction. Depending upon the version you are running this may be a check box, double click, or tab.
In the field labeled Invoice enter the invoice number this credit is to be applied to.
Save.
If you have an open credit and an open debit for the same absolute amount apply them to the same invoice. If you want these items to drop off your aging immediately apply them to a paid invoice. Providing the debit and credit are for the same absolute amount the net change to the value of the invoice will be zero.
Credit Memos and Open Payments – Applied to Multiple Invoices
In the case where there is one credit memo that needs to be spread over multiple invoices or if only a portion of a credit memo is to be applied to an invoice follow these steps.
Navigate to A/R Posted Transactions.
Put focus on the target credit. Note the number appearing for this transaction in the Chk/Ref column.
Navigate to Customer Payments. Enter a payment for the customer under discussion. In the Check Number field enter the Chk/Ref number you just looked up.
SyteLine should give you a display in the Description field that says Reapplication of Open Credit.
Be aware the date that SyteLine returns will be the date the open credit was created. This date should be overridden and changed to the current date in order to keep historical aging reports accurate.
Apply the credit as if it was a check, using all standards and procedures you have in place for AR cash receipts.
You can leave an open remainder if desired.
Removing or hiding applied items
Once all of the open credits, debits and payments have been applied to the appropriate invoices you may want to have them drop off your aging and posted transaction screen. This can be accomplished by running either Activate/Deactivate Posted Transactions or Delete A/R Posted Transactions.
Proper order for running MRP and MPS ProcessorThe order in which the MPS Processor and MRP Generation utilities are run depends upon the way you are using the MPS functionality. Which should be run first depends on whether or not you have MPS items which are not top level items and whether or not you are using the MPS Planning Fence feature. The primary function of the MPS processor is to examine the receipts and requirements which exist for each MPS item and generate the appropriate exception messages. Beginning with version 4.0, it also generates MPS receipts for requirements outside the MPS Planning Fence. It does not do any multi-level BOM processing (e.g. passing of requirements). The following is an overview of the MPS Processor algorithm.
– Reads each item master which is an MPS item.
– Deletes all exception messages which exist for the item.
– Generates requirements from COs for the item and consumes forecasts.
– Reviews all other requirements and receipts which exist for the item.
– Generates the appropriate exception messages.
– Generates MPS receipts if any unsatisfied requirements exist outside of the planning fence.
The key points to consider are the following:
1) The MPS processor generates exception messages after reviewing all receipts and requirements for the item. Since the MRP Generation does all passing of requirements, this means that the MPS processor needs to be run after MRP if you have MPS items which are not top-level items. In that case, if you ran the MPS Processor first it may not generate exception messages properly since the item has not yet been passed requirements from its parent items (or had the dates of existing requirements adjusted).
2) You can use the MPS Planning Fence field to have the system generate MPS receipts for uncovered requirements which exist for MPS items outside of the number of days specified. The MPS Processor is what generates these receipts but, like manually entered MPS records, these are exploded to the MPS item’s BOM by the MRP Generation. So, if you are using the fence and run the MPS Processor after MRP, it may generate MPS receipts which will then not be passed to the MPS item’s BOM until the next night’s MRP run.
Therefore, to have clean MRP data and exception messages after each night’s run, you should:
1. If you are using the MPS Planning Fence, run the MPS Processor and then MRP.
2. If you have MPS items that are not top-level items, run MRP and then the MPS Processor.
3. If you are not using the planning fence and all of your MPS items are top-level items, the order in which you run them does not matter.
4. If you have top-level MPS items for which you use the planning fence and non-top-level MPS items for which you do not use the planning fence, running the MPS Processor, then MRP, and then the MPS Processor again would result in clean information.
The situation you may want to avoid is having non-top-level MPS items for which the planning fence is being used. In that scenario, you may not have completely clean data and exception messages after one night’s processing even if you run the MPS Processor twice since an MPS receipt may not be generated for an MPS item until the second time the MPS Processor is run.
For example, if a new requirement which is outside the planning fence needs to be passed from a parent item to a level-2 MPS item, it wouldn’t exist when the first MPS Processor is run so no MPS receipt would be generated to cover it. MRP would then pass the requirement to the level-2 MPS item. The second running of the MPS Processor would then generate an MPS receipt to cover the requirement and generate correct exception messages, but that MPS receipt would not be passed to the level-2 item’s BOM until the next MRP run.
There are three main tools you can use to plan with SyteLine:
MRP
APS, finite
APS, infinite (APSI)
These key factors will help you decide which planning tool best fits your needs:
Constraint behavior
Accurate times
Motivation
There are also a few secondary factors that may affect your choice. We’ll explain each below
Constraint behavior
Do you want constraints to push out plans or do you want a fixed target?
Here are the constraints that may move plans out:
Material availability
Capacity
Time on-shift
Today
APS backwards plans. If any of the first three constraints is not available between today and the due date, and it lies on the critical path, the system will push the plans out and backwards plan from the new date. If the plan is moved out, then ALL plans for that order are moved out.
For example, a user receives a customer order. If the user constrains on a material and its lead time is such that it affects the critical path, then APS will move all plans (all purchase orders, manufacturing orders for subassemblies, etc.) for the meeting the customer order out. You can turn off this constraint at the item level, but if a constraining material is not available and on the critical path, APS will move ALL plans for the end order out.
Another example. If you do not have capacity, APS will search for earlier time when you do. If you have none, it will push out the plan to find available capacity. And because the plan for manufacturing is pushed out, so are all the need dates for purchased materials. (Time on-shift works like capacity in that APS applies your times to a working calendar, if you choose, instead of a 24×7 calendar.)
The whole concept of pushing out plans is tied to the just-in-time philosophy. So if you have capacity constraints, the APS approach will minimize the inventory by synchronizing its arrival with its use. APS provides tools to see plans that are late. You can then work to resolve those issues and meet your due date. If you want any of these constraints to move your plan dates, you’re probably a candidate for APS or APSI.
However, some users do not want constraints to move out target dates. They want a fixed target for a plan. They want to see what they need to do to ship at a certain date. They want to clearly see when something is supposed to happen and will expedite and increase capacity to make it happen. These users do NOT want to see moving release dates and non-critical item pushing out the critical path; they simply want to freeze the plan until they’ve exhausted all expedite and capacity solutions.
If you want a fixed target, you are a candidate for APSI or MRP. Generally, such users have the following characteristics
To-order environment with revenue targets and cyclical order bookings
Most of their products are engineer-to-order, assemble-to-order, or make-to-order. They often sell configured products so they can’t make them ahead of time and level their production. The best they can do is plan for common sub-assemblies and purchased parts using planning BOMs and forecasts or dummy MPS lines with a kit of these common items.
These users have quarterly revenue targets and most of the order bookings come later in the quarter. There’s a rush to sell and ship product to meet the revenue targets at the end of the quarter, then a slow period at the beginning of the next quarter.
These users don’t want their plans to move. They want a fixed target and will do whatever it takes to get it out the door.
Material, not capacity, is the critical constraint
Backlogged orders or late shipments are most often caused by material shortages. Such users would rather get material in, even if months early, than experience a shortage. Variability in lead time only adds to this issue. A lean, JIT environment poses too much risk of material shortages for these users.
Capacity is not an issue for these users. They only need to know WHEN they need the capacity and HOW MUCH. Then they’ll make sure it happens.
No negotiation power with customers
Users who have little negotiation power with their customers usually have the following characteristics:
Often a majority of their business comes from a handful of customers.
The customers require them to feed their production schedule, and if they’re late they’re heavily fined.
It’s cheaper to expedite than miss the customer deadlines.
A highly competitive environment and meeting due dates is critical.
In these situations, the user wants a fixed target for production. They want to know when they need materials in and when they need to increase capacity. They will do whatever it takes to make the date.
Accurate times
Do you have accurate operation times for mfg items and lead times for purchased parts? If not, are you willing to spend time to update them?
APS will push plans forward using mfg times and lead times. If users can identify the critical materials and operations and have accurate times for these, they will find APS results reasonable. In complex manufacturing or assembly environments, balancing/synchronizing material and capacity is more important, and APS can help if a user has accurate data.
Note: in such situations a user does NOT need accurate data on all operations and materials–they only need it for the critical materials and the bottleneck resources.
If a user does not have accurate time information for the critical resources and materials and does not want to do what is required to update those times, then that user is a good candidate for MRP or APSI. In these situations, the user is comfortable with MRP or APSI backwards planning without constraint and working with a rough idea of how much expediting is needed for a given item.
Motivation
Are you actively looking for a solution to improve your planning or are you satisfied with MRP?
APS approaches planning different from MRP. Here are some of the key differences:
Constraints pushing out plans
Using projected late instead of past due to flag problems
Consolidation
Load (APS provides)
BOM data needed (can run MRP on lead times, good routing times not required), good lead times defined
New parameters
Moving from MRP to APS or APSI requires a significant change. It requires commitment and energy to revise appropriate business processes, obtain accurate date for critical resources and materials, and train the users. Many APS and APSI users have realized significant benefits in reduced lead times, reduced inventory, and increased on-time deliveries. However, if a user is simply trying to move from SL6 to SL7 to take advantage of the Microsoft platform or is happy with the results of MRP, then they are not a candidate for APS or APSI.
Secondary factors
There are a few other factors that differ between MRP and APS. Consider these when making a decision.
Load views
APS and APSI will show you capacity. MRP will not. If you want a view of the load, even if you want an MRP-like plan, and are not using scheduler, then you’ll want to use APS or APSI.
What-if analysis
Only APS and APSI provide what-if analysis with the Analyzer.
Consolidation
Will the difference in consolidation hurt your process? Can you set consolidation times to be equal at all levels of a BOM or use order mins and multiples to manage inventory?
Decision Table
The 3 key questions you need to answer:
Question
APS
APSI
MRP
Do you want constraints to push out plans or do you want a fixed target?
Push
Push or Fixed
Fixed
Do you have accurate operation times for mfg items and lead times for purchased parts? If not, are you willing to spend time to update them?
Yes
Yes
or No
No
Are you actively looking for a solution to improve your planning or are you satisfied with MRP?
Looking
Looking
Satisfied
Notice that in many instances a user can run APSI like MRP, yet take advantage of some of the tools in APS. To do this you need to make some specific settings.
How to set up APSI to run like MRP
If you want the load data, Analyzer what-if capability, and order visibility provided by APSI, but want it to run like MRP, you’ll need to set a few fields. The table below describes what you should do.
To…
Do this…
Turn off constraints so they don’t push out plans
Make all resources and resource groups infinite. This will turn off capacity constraint.
Give all resources a 24×7 shift. This will turn off the on-shift constraint. You can also use the MRP Item checkbox to turn off on-shift constraint for specific items.
Set Fixed Time to today – the longest lead time. This parameter can be set via the Analyzer. This will turn off the today and material availability constraints.
If you want to turn off material availability constraints for specific items, use these fields on the Items form:
Infinite checkbox (for purchased items)
Accept Requirements checkbox (no PLN generated)
Pass Requirements checkbox (no PLN generated for components)
Expedited Lead Times (set to 1 day, this will generate PLNs and allow you to see total days needed to expedite)
Set up consolidation to behave more like MRP
Make sure that higher levels in the BOM have a consolidation period equal to or less than the consolidation period of items in lower levels.
Or you can use order minimums and multiples to manage inventory instead of consolidation.
Use target dates instead of projected dates
Select the Preserve Pre-released Production Dates and deselect the Use Scheduled Times in Planning checkboxes. This will tell APS to use the end dates, not projected dates, as dates jobs will finish.
Set up safety stock exceptions for purchased items to behave like MRP
Select the Purchase Supply Switching and Generate Purchase Order Exceptions checkboxes.
Set up safety stock exceptions for manufactured items to behave like MRP
Apply the support solution for planning safety stock if your order minimums are larger than your safety stock level.
Open Payments in SyteLine AP are designed to record a payment as an asset and to later allow reapplication of the payment to an invoice at a later date. The flow in a typical scenario is illustrated below:
A check is written to a vendor for a $5000 deposit (50%) on a capitol asset purchase.
Prepaid Deposits
Cash
5000
5000
An invoice from the vendor for $10000 is received and entered into AP.
Capitol Assets
Accounts Payable
10000
10000
The Open Payment is reapplied to the posted voucher.
Accounts Payable
Prepaid Deposits
5000
5000
Set Ups
To get the correct flow of data the following tables need to be set up as follows:
Accounts Payable Parameters, Misc Tab – Deposit Account needs to be an Asset , typically Prepaid Deposits.
Bank Reconciliations – Cash Account needs to be a cash account.
Processing
Creating the Payment
In the A/P Payments form enter a payment for the desired Vendor. Type can be any valid Payment Type. Save. Go to Distributions. Enter a distribution with a Type of Open, accept the default value for Vch/Seq, select the appropriate Site, enter a PO number if you wish this to be reflected on a PO, on the Accounts Tab enter the amount of the payment. Save. The distribution will be to the Prepaid Deposit Account. Print and Post the check using A/P Check Printing/Posting.
Purchase Order
If a PO is entered in the Payment Distribution a cross reference is created. The PO will now reference the payment and payment information will print on the PO.
AP Posted Transactions
The Open Payment will be visible in AP Posted Transactions and will have a Type of Open.
AP Aging Report
The Open Payment can be included or excluded from the AP Aging report by using the Print Open Payment check box on the selection criteria. If the aging is being printed for use in reconciling the Ledger to the AP Aging exclude Open Payments. Otherwise the balance will be off the amount of all Open Payments.
Voucher
When the invoice for the item(s) arrive voucher and post as usual following standard procedures for voucher entry. Enter the voucher for the entire purchase amount, ignoring the deposit amounts, i.e. you are purchasing $10000 worth of product, made a $5000 deposit – enter the voucher for $10000.
Reapplication of the Open Payment
To reapply the open payment you need 3 pieces of information; Vendor number, Check number, and Voucher number. Go to AP Payments, enter the Vendor, check the Reapplication checkbox, enter the Check number of the Open Payment to be reapplied. Save. Go to either Quick or Distribution and select the Voucher the payment will be applied to. Save or Apply. Post the check using AP Check Printing and Posting. Do not print a check, only the Preliminary Check Register and Final Register and Post are required.
AP Posted Transactions
After reapplication the Open Payment now is reapplied to the Voucher and the posted balance of the Voucher and AP have been reduced by the amount of the Open Payment..
At the end of the MRP Generation, you receive the following error:
[WARNING – Low level codes are improperly set. MRP Generation is not complete – re-run Net Change. MRP PROCESSOR] was not successful.
If you receive this error at the end of running the MRP Generation, it may or may not mean that the low level codes in the item master are improperly set. When the MRP Generation completes, it scans the item master file for any item where the “Net Change” flag is yes. All flags should be no if MRP runs successfully.
If any items are found with the net change flag set to yes, MRP displays the above error. Although it is not always the case, MRP is making the assumption that items found were not processed due to a low level code problem. The following are all of the known reasons for why this error may occur:
1) Low Level Codes are incorrect.
This is the most common reason for this message. To ensure that low level codes are accurate you should first run the “Current BOM Processor” and then the “Job BOM Processor” before running the MRP Generation. If your low level codes are not correct, your MRP data will not be accurate for the problem items and all items below them in your BOM structure.
Because of the nature of these algorithms, running them both and doing so in the proper sequence is crucial. Not running the job processor or running it before the current BOM processor may result in incorrect codes. There is a utility attached to this entry that can be used to display any items that have an incorrect low level code after the two processors have been run.
An alternative to running both processors before each MRP run is to have the inventory parameter “Low Level On-line” enabled which causes the system to adjust low level codes on-line as BOMs are copied and maintained. If both processors have been run at some point without errors and this flag is enabled, your low level codes should not be the problem. If you are relying on this parameter to maintain your codes, it may be worthwhile to run both processors before the next run to see if they fix the problem.
2) People are using the system while MRP is running.
Although it is not always feasible, the MRP Generation is designed to be run when no users are in the database. If there are users working in the manufacturing modules while MRP is running, there is a strong chance you will receive this error. If MRP plans an item (changing its flag to no) and then a transaction is processed or an order entered for that item while MRP is still running, the item’s flag will be flipped to yes which will result in the error at the end of the generation. In this situation, there really is no problem which needs addressed other than perhaps a procedural change to assure no one is using the system while MRP is running.
3) Invalid cross references.
If you have what MRP determines to be an invalid cross reference, it will generate and error and skip the next item before changing the item’s net change flag to no. Therefore, the item with the invalid cross reference will generate the low level code error. If MRP is being run in the background queue, the error will be written to the MRP error file (mrp.err). If being run in the foreground, the error will appear on screen. This problem cross references must be manually cleaned up in order to prevent this error.
Cross references can be created between CO line items and jobs, job materials and subjobs, or job materials and PO line items and must be a one-to-one relationship. If one record points to another which is not linked back or if multiple records point to the same record the system considers that an invalid cross reference. Examples would be if a CO line item is referenced to a job which is not referenced to the CO line or multiple job materials all referenced to the same PO line item.
4) An item is missing the inventory default warehouse.
Every item in the item master file should have and item warehouse record (itemwhse) for the warehouse that is defined as your default warehouse in the inventory parameters (typically MAIN). SYMIX always expects that record to be there. If the “Whse Considered For” MRP parameter is set to “Single” and an item is missing this record, MRP will skip the item without resetting its net change flag. To check for this condition, you can run the following program from the Progress query editor:
find symix.parms 0.
for each symix.item no-lock where item.item <> “”:
find itemwhse where itemwhse.item = item.item
and itemwhse.whse = parms.def-whse no-lock no-error.
if not available itemwhse then
display item.item item.change-date.
end.
If any items are missing this record, it can be created by running the “Item Stockroom Loc Mass Create” utility on the inventory Warehouse Transfer Utilities menu.
5) The BOM processor(s) failed without error due to incorrectly imported data.
Like item 1 above, this may result in incorrect low level codes but it is really a different problem. If you have imported data such as item master records, current routing and BOMS, jobs, job routings and job BOMs and all of the files and fields have not been populated appropriately, both processors may complete with no error messages but your low level codes may still be inaccurate.
One past example of this was imported actual jobs that did not have the “Finish Job” field populated. The Job BOM processor gave no errors but did not work since it counts on that field being set for identifying top level jobs.
6) Low level code are incorrect due to bugs 19385 or 19387
These are two bugs that ONLY EXIST IN VERSION SL3b00. The problem defined by bug 19387 is that the low level codes are not set properly when you add materials to a current or job BOM if the “Low Level On-Line” inventory parameter is enabled. The workaround is to run the Current BOM Processor and Job BOM Processor before each MRP run.
The problem described in bug 19385 is that the Job BOM Processor may not adjust your low level codes correctly if there are manufactured items used in job BOMs at lower levels than they are used in any current BOMs. The true cause of the problem is that the inventory module is leaving the status field blank in the current job it creates when you create a current routing for an item. It should be (F)irm. The workaround is to run the following program to populate that field and then run both processors.
for each symix.job where job.type = “S”:
job.stat = “F”.
end.
If none of these prove to be the source of the problem, the first step should be check the background queue log file, MRP error file, and the database log file. If there was a Progress error generated due to missing or corrupt data, it will appear in one of these files.
If no errors are found, the next step would be to run the “Items with Net Change Flag” report immediately after MRP finishes. Any items for which the net change flag is yes will appear on the report. You should then examine the data structures in the system for those items. For example, run a “Single Level Where Used” report for the item and verify its low level code is higher than all its parent items’ codes.
It is imperative that the report is run after MRP finishes but before any users begin using the system since there activities will likely turn on the net change flag for items making it impossible to know which items generated the low level code error. If running MRP in the background, you can set up this report to also run in the background after MRP.
The following is a list of Year End Procedures. An asterisk (*) denotes the procedures which initialize year-to-date fields in various files. In order to ensure accurate data, these utilities must be run before any processing that updates these fields is done in the new year. The timing of executing the remaining utilities is not critical. These procedures apply to SYMIX and Syteline. The following Resolutions have an explanation of each procedure and the keystrokes to select from the main menu.
1) A/R Year End Procedure *
2) Vendor/Item and Customer/Item YTD *
3) P/R Year End Procedure (Based on Calendar Year) *
4) Print W-2 Forms (Based on Calendar Year)
5) Human Resources Year End Processing *
6) Year End Closing Journal Entries
7) A/P Year End Procedure (Payments YTD Based on Calendar Year) *
8) Print 1099 Forms (Based on Calendar Year)
9) Set Item PTD and YTD Totals to Zero *
10) Fixed Assets Year End Procedure*
11) Update Current Period and Current Fiscal Year
==========================================
CUSTOMER (Accounts Receivable)
1) A/R Year End Procedure*
This utility will reset fields in the Customer Maintenance and/or the Salesperson Master tables. The fields that will be reset to zero are the Sales PTD, Sales YTD, Discounts YTD, Sales Last Year, and Discounts Last Year for the Customer Master. The fields that will be reset to zero for the Salesman Master are Sales PTD and Sales YTD. This utility MUST be executed after generating invoices and posting customer payments for the current year BEFORE posting any of these transactions for the new year.
NOTE: This utility should only be run once. If you run it more than once, it will results in zeros in Sales Last Year and Discount/Allowance Last Year fields.
-Customer
– Payments
– Utilities
– Period/Year End Procedure (ar/arend.p)
2) Vend/Item and Cust/Item YTD *
This utility will reset the fields in the Vendor/Item Cross Reference (venditem) and the Customer/Item Cross Reference (custitem) fields to zero. The Vendor/Item fields reset are Ordered YTD, Received YTD, Rejected YTD, Avg Cost, Avg Lead Time, Avg Lateness, Avg Cost/Plan %, and Last Cost/Plan %. The Customer/Item fields reset are Purchases YTD, Ordered YTD, Shipped YTD, and Ordered PTD.
– Customer
– Customer Inquiry (or Customer Maintenance)
– Utilities
– Order Utilities
– Vend/Item and Cust/Item YTD (util/cvitem-y.p)
NOTE: This utility is located in both the Customer and Vendor modules but only needs to be run once.
========================================
EMPLOYEE (Payroll and Human Resources)
1) Payroll Year End Procedure *
This utility updates the Employee Master to reflect the change of the year. The year to date gross and tax fields are set to zero in the Employee Master and the vacation hours due is reset to the sum of the remaining hours due and the vacation hours paid (the sick hours due must be manually reset). This utility should be run after the last payroll of the year and before the first payroll for the next year. All adjusting transactions for the current year must be entered and posted before executing this utility.
– Employee
– Payroll Processing
– Utilities
– Year-End Closing (pr/prend.p)
2) Print W-2 Forms
This procedure will calculate the year-to-date gross wages and taxes for each employee in the Employee Master file. The information comes from the posted payroll file (prtrxp). Please be prepared for the W-2’s to take a long time to process. The length of time is dependent upon the number of employees and the frequency with which they are paid. It is not uncommon for the processing on large databases to take several days. If you have an automatic overnight backup procedure, such as a cron, it should be disabled to ensure that the database server is not shutdown. In addition, sending the output to a file can be helpful. This will allow the W-2’s to be reviewed before they are printed and to be re-printed if necessary without additional processing time.
– Employee
– Payroll Processing
– Reports
– Other Payroll Reports
– W-2 Form Printing (?)
W-2’s can also be generated on Magnetic Media which is available under Other Payroll Reports and then W-2 Magnetic Media Reporting. A file called W2REPORT is created which is the file name required by the Social Security Administration and should not be changed. The file can be put on either a tape or any size Floppy Disk. There is an option for Create State Tax Records for states that require Magnetic Media W-2’s.
3) Human Resources Year End Procedure *
This utility updates sick leave and vacation records for the selected range of employees. Only records which have not been processed during this calendar year will be affected. The total amount of sick leave or vacation hours due last year is calculated and this number plus any carry over amounts minus any days used will be the new total days. All other fields are set to zero.
– Employee
– Applicants
– Utilities
– Year End Procedure (hr/yearend.p)
=====================================
FINANCIAL (General Ledger)
1) Year End Closing Journal Entries
This procedure will create debit and credit entries to close out all revenue and expense accounts for the date range specified. These entries will be placed in the General Journal and the General Journal must then be posted to the General Ledger. When prompted to enter “Income Summary Account” enter the Retained Earnings account that has been setup as type “O” in the Chart of Accounts. The question “Delete journal entries first?” on the option screen refers to existing entries in the General Journal only. When saying YES to Unit Code Detail, the unit code balances in the revenue and expense accounts will be cleared as well. Saying NO will leave the balances in the unit codes, and carry them forward.
DO NOT change any of the references generated by the system on the entries in the General Journal. This procedure should be run after all entries made to the fiscal year are posted. In addition, if any adjusting entries need to be made after the procedure has been run, the procedure MUST be performed again.
– Financial
– Journal Entries
– Utilities
– Year End Procedures (gl/glend.p)
=============================================
MATERIAL (Inventory and MRP)
1) Set Item PTD/YTD Totals to Zero *
This utility will reset fields in the Item Maintenance to zero. The fields reset are Sold YTD, Used YTD, Purchased YTD, Quantity Manufactured YTD, and Sales YTD. The utility should be run after completing jobs, shipping orders, and PO receipts for the previous year and prior to performing any of these transactions for the next year.
– Material
– Inventory
– Item Maintenance
– Utilities
– Set Item/Whse PTD/YTD to Zero (util/set-iytd.p)
EXAMPLE — GENERAL LEDGER YEAR END CLOSING
Suppose the following entries were the financial activity for a company for the fiscal year of 01/01/00 to 12/31/00 using the following accounts:
10000 Asset
20000 Liabilities
30000 Owner’s Equity
40000 Revenue
50000 Expense
— Example of Ending Balances (12/31/00)
10000 100,000.00
20000 (64,500.00)
30000 (20,000.00)
40000 (23,500.00)
50000 8,000.00
— Example of Year End Entries
30000 15,500.00
40000 23,500.00
50000 (8,000.00)
— Example of Ending Balance (12/31/00) after Year End Procedures
10000 100,000.00
20000 (64,500.00)
30000 (35,500.00)
40000 00
50000 00
NOTE: No entries were generated for Accounts Receivable or Cash because they are asset accounts. Only revenue and expense accounts are closed out.
2) Update Current Period and Current Fiscal Year
In order to post journals for next fiscal year and close previous year, the Current Fiscal Year field on the General Parameters screen must be manually updated to the next fiscal year. Note: You must create the accounting periods (see below) before you can change the fiscal year.
– File
– Parameters
– General
You also need to update the Current field on the Accounting Periods screen.
– Financial
– Accouting Periods
– Activities
– Current Period Update
3) Fixed Assets Year End Procedure * (See notes on General Ledger)
This procedure will reset the year-to-date depreciation field for each fixed asset master record that falls within the selected range of assets. This utility MUST be performed after the last depreciation generation for the current year and before generating depreciation for the new year.
– Financial
– Fixed Assets
– Utilities
– Year End Procedures (fa/faend.p)
NOTE: When Generating Depreciation for the 12th period, there is an option for Year End processing. If yes, the Depreciation will be done for all periods and year items. Depreciation for period and year cannot be done separately. If Depreciation is run and posted twice, once with year end processing no and once with yes, it will double depreciate all period items.
======================================
VENDOR (Accounts Payable)
1) A/P Year End Procedure *
This utility will reset fields in the Vendor Master file (vendor). The fields are reset to zero (Discount YTD, Purchase YTD, and Payments YTD). In addition, the Purchases Last Year is set with the current value of the Purchases YTD and the Discounts Last Year is set to the current value of the Discounts YTD. The Payments YTD procedure MUST be performed after the last Accounts Payable check run for the calendar year, BEFORE posting any Accounts Payable checks for the new year.
NOTE: Payment YTD Year End must be run at the end of the calendar year (not the fiscal year). This field is used in generating 1099’s which are printed on a calendar year basis.
– Vendor
– Payments
– Utilities
– Year End Procedure (ap/append.p)
NOTE: This utility should only be run once. If you run it more than once, it will results in zeros in Payments Last Year, Purchases Last Year and Discount Last Year fields.
2) Print 1099 Forms *
A 1099 will be printed for each vendor that has a Federal ID entered on the Vendor Maintenance (Tax Info tab). The value printed can be specified as either the Vendor’s Payment YTD or the Vendor’s Payments Last Year at the time the 1099s are generated. The choice between using the Vendor’s Payments YTD or Payments Last Year is based upon the execution of the A/P Year End Procedure. Please review the A/P Year End Procedure above.
– Vendor
– A/P Reports
– Other A/P Reports
– 1099 Forms (?)
Magnetic media is available for the 1099 report. You may choose to run a test, correction or original magnetic media report. You may create 1099 records by state and submit records through an agent. The “Use Last Yr’s Payment Records” option has been added to this report. Two additional files are used to track information for 1099 reporting: (1) the state file tracks state abbreviation postal code, minimal payment and magnetic media participation information and (2) the apparms file (1099 parameters) tracks the payer name control, TIN name, transmitter name, transmitter control code, transmitter address, and transmitter agent name and address.
3) Vend/Item and Cust/Item YTD *
This utility will reset the fields in the Vendor/Item Cross Reference (venditem) and the Customer/Item Cross Reference (custitem) fields to zero. The Vendor/Item fields reset are Ordered YTD, Received YTD, Rejected YTD, Avg Cost, Avg Lead Time, Avg Lateness, Avg Cost/Plan %, and Last Cost/Plan %. The Customer/Item fields reset are Purchases YTD, Ordered YTD, Shipped YTD, and Ordered PTD.
– Vendor
– Vendor Inquiry (or Vendor Maintenance)
– Utilities
– Purchasing Utilities
– Vend/Item and Cust/Item YTD (util/cvitem-y.p)
NOTE: This utility is located in both the Customer and Vendor modules but only needs to be run once.
================================
ADDITIONAL PROCEDURES
The following is a list of procedures by module which need to be performed periodically and may be convenient to run at Year End. Most of these procedures will delete information from the database. Once the data is purged, you will not be able to view or restore it. Depending on your company’s policy, you should keep a couple years of data for audit purposes. You can also archive the database (copy of the database) before you purge the data so you can access the information as needed. If you delete data, you should consider optimizing your database to relocate the disk space.
*********************************************
CUSTOMER (Order Entry and Accounts Receivable)
1) Delete History Orders
This utility will delete all Customer Orders with a status of History for the specified range.
2) Purge Packing Slip Register
This utility deletes records from the Packing Slip register. The Customer Order must have a status of Complete or History before the records are purged.
3) Purge Invoice History
This utility deletes records from the invoice history file posted. If the “Delete Line Items Only” option is set to Yes, only the invoice line item and progressive billing line items are deleted. If this option is set to NO, invoice header and tax records will also be deleted.
4) Delete A/R Posted Transactions
This utility deletes records from the A/R posted transaction file. You should run the Customer Statement before running this utility. For balance forward customers, it deletes all invoices up to the amount of the payment available and generates a balance forward entry for the first partially paid off amount. For open item customers, it deletes all fully paid invoices. Once the records are deleted, you lose the capability to review the details.
*************************************
EMPLOYEE (Payroll)
5) Delete Posted Payroll Transactions
This utility will delete records from the posted payroll file (prtrxp) for the date range specified. This utility should only be run AFTER printing W2’s and year-end payroll reports. You need to verify that the W2’s printed properly and the information on the W2’s is correct prior to performing this utility. Once this utility is performed, the records needed for the W2’s are purged. Therefore, running this utility prior to printing W2’s will result in either no information or incorrect information on the W2’s.
************************************
FINANCIAL (General Ledger)
6) Compress General Ledger Transactions
This utility deletes records from the General Ledger Posted transaction field. You should backup your database before performing this utility since transaction detail is lost. A financial summary is retained for each account depending on the “Compress by” option. If the “Compress by” option is set to D (Date), all transactions with the same date are compressed to 1 transaction for the selected accounts or reporting units. If the “Compress by” option is set to P (Period), all transactions in the same accounting period are compressed to 1 transaction for the selected accounts or reporting units. The date for the new transaction will be set to the period end date.
NOTE: General Ledger Transacions with a reference of “Income Summary” are never compressed.
*******************************
MATERIAL (Inventory)
7) Delete Material Transactions
This utility deletes material transactions records which is the audit trail for your inventory transactions (any changes to the quantity on hand or cost of the item). Once the records are deleted, you lose the capability to review the details. When a material transaction is deleted, reference to that transaction from any ledger or journal transactions will be cleared. If you try to view the detail on a ledger or journal previously referenced to the deleted material transaction, SyteLine will display a message that the record is not available.
8) Roll Current Cost to Standard Cost (only if using Standard Costing)
This utility creates or updates the Standard Routing/BOM for standard costed items. It also creates a material transaction and journal entries to reflect the change in inventory value at each stockroom location (journal transactions have a reference of INV STDC).
NOTE: The “Post Change” option must be Yes to post the changes. You can run this utility with the “Post Change” option set to No so you can review the report and verify the changes before posting.
**********************************
PRODUCTION (Shop Floor Control)
9) Job Status Change/Delete Utility
This utility changes the job status for a valid combination (see on-line help for the various combinations). You can also delete jobs with a status of “History.
10) Delete Job Transactions
This utility deletes job transactions (jobtran) records which is the audit trail for your labor transactions (Job, Production Schedule, JIT and Work Center). Once the records are deleted, you lose the capability to review the details.
11) Review M-Day and Holiday Calendars
You might need to change the MDAY start and end fields on the Planning Parameters screen to create the new mday records for the next year. You will need to manually add the Holiday records for the next year.
******************************************
VENDOR (Purchasing and Accounts Payable)
12) Delete Purchase Orders
This utility deletes all Puchase Orders with a status of History. If the PO has a current Change Order with a status of Open or Final, it will not be deleted.
13) Purge Voucher History
This utility deletes records from the voucher history file. All vouchers prior to the specified Invoice Date and less than the specified Voucher Number are selected. Voucher headers associated with unposted AP transactions or a Purchase Orders with a status of Planned or Ordered will not be purged.
14) Delete A/P Posted Transactions
This utility deletes records from the A/P posted transactions for all fully paid vouchers. Once the records are deleted, you lose the capability to review the details.
Recent Comments