SytelineMaster

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.

An invoice from the vendor for $10000 is received and entered into AP.

The Open Payment is reapplied to the posted voucher.

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..

Why MRP Failed with Low Level error?

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.