FACTS version 7.8.5 is certified to run with the following the third party product versions:
Visifax 6.2 Certification for any FACTS 7.8 version
(Visifax 6.1 also remains certified.)
Storefront 2.0.300
Refer to the FACTS Compatibility Matrix document for details on using third party products with FACTS.
FACTS 7.8.5 release contains a new Auto Sign-In (ASI) enhancement. ASI allows FACTS users to automatically access the FACTS main menu and bypass the Sign-on screen without having to sign-in in each time.
System Administrators control whether ASI is allowed and which users are permitted to auto sign-in.
Auto Sign-In Process
After specifying the domain, user name and default company (in User Preferences), when a user who is permitted to auto sign-in first signs-on to FACTS (entering the proper user code and password), the successful login is recorded, and subsequent FACTS sessions for that domain and user will be automatically signed-in.
The net effect is that any initial login will require the user to enter the proper user code and password. Having successfully entered the user code and password, users will subsequently be signed in automatically.
Command line arguments have been added so that users who are authorized to auto sign-in can create desktop shortcuts directly to specific programs and specific companies.
The following System Management programs were changed:
System Control F/M (SMF950)
On the new Auto Sign-In tab of System Control F/M, a new Allow Auto Sign-In setting must be on for any user to be able to use ASI. The new tab also contains an IP Address Masks section for an optional list of TCP/IP address masks, which the user’s TCP/IP address must match to be allowed to use ASI. If no masks are entered, there is no restriction on IP addresses that can use ASI. If the Allow Auto Sign-In setting is unchecked and the record is saved, the system essentially “forgets” that every user has previously signed in and forces them all to provide log-in credentials at the next attempt to access FACTS.
Company Control F/M (SMF920)
The Security/Settings tab of Company Control F/M now contains an Allow Auto Sign-In setting which must be selected for any user to auto sign-into that company. If the Allow Auto Sign-In setting is unchecked and the record is saved, the system essentially “forgets” that every user has previously signed in and forces them all to provide log-in credentials at the next attempt to access FACTS.
User Code F/M (SMF410)
In User Code F/M, a new Auto Sign-In tab contains settings that control whether a user has ASI privileges. The Allow Auto Sign-In setting in Company Control F/M must be on for any user to utilize ASI. The system administrator can pre-establish the user’s domain, user name and default company, but these values can also be entered by users themselves on the Auto Sign-In tab in User Preferences F/M. Either the system administrator or the user must specify the default company that the user auto signs into, the user’s network domain and user name (required), and optionally the IP address masks that users are allowed to auto sign-in from.
If the Allow Auto Sign-In setting is unchecked and the record is saved, the system essentially “forgets” that this user has previously signed in and forces the user to provide log-in credentials at the next attempt to access FACTS. If the User Name or Domain is changed and the record is saved, the system essentially “forgets” that this user has previously signed in and forces the user to provide log-in credentials at the next attempt to access FACTS.
User Preferences F/M (SMF440)
In User Preferences F/M, a new Auto Sign-In tab contains new fields for the user’s domain, user name and default company. The user name and domain can only be entered by clicking the F1 button/key to pull in the user’s current domain and user name.
Setup Information for Auto Sign-In (ASI)
Complete the following to set up the Auto Sign-In feature:
1 On the Auto Sign-In tab of System Control F/M, select the Allow Auto Sign-In setting.
(Optional) In the IP Address Masks section specify a list of TCP/IP address masks which the user’s TCP/IP address must match to be allowed to use ASI. If no masks are entered, there is no restriction on IP addresses that can use ASI.
2 On the Security/Settings tab of Company Control F/M, select the Allow Auto Sign-In setting to allow users to auto sign-in to that company.
3 In User Code F/M, on the Auto Sign-In tab, select the Allow Auto Sign-In setting to indicate a user has ASI privileges,
—or—
have the user access the Auto Sign-In tab in User Preferences F/M and click the F1 button/key to pull in the user’s current domain and user name.
During the upgrade process, if a BOM is also a component of another BOM, the usage was set with a PC (production credit) and an MC (manufacturing credit), which zero each other out, there by setting usage to 0. The UPLAYERS process now builds a list of component items during the data conversion. If a finished item is used as a component, the usage and hit is recorded. Also, if the finished item is used as a component, the usage credit for the finished item is not recorded to offset the original usage.
In the FACTS 7.8.5 incremental release, serial/lot processing no longer allocates cost layers for committed quantities. FACTS 7.8.5 serial/lot processing allocates cost layers only for shipped quantities. Prior to FACTS 7.8.5, serial/lot cost layers allocation occurred for both committed and shipped quantities.
In the FACTS 7.8.5 release, turns were removed from the usage displays because the calculations were not accurate or meaningful in those contexts. The Turns View was added back to Item Inquiry (ICI610), and the Inventory Turns Report (ICR725) was updated to accurately calculate and display information.
The Turns Report (ICR726) program has been enabled with a “debug” mode, which can be turned on in the code line. The variable, debug_it, can be set to 1 in the turns_setup procedure to cause the procedure to log to Excel® the details of the turns calculation. This option should only be used when running a single item, as it doesn’t clear the spreadsheet between items. When debug_it is in use, Excel should already be open with two blank worksheets available, called “Sheet 1” and “Sheet 2” (be advised Excel opens 3 blank worksheets as the default).
Note that inventory turns are only calculated on stocked items. Any item that is flagged as non-stocked or un-inventoried in the Item Master file is excluded from the calculation for turns.
The basic math is total cost of goods sold (or moved for purposes of serving customers) from stock divided by average inventory. The purpose of the turns measurement is to provide an indicator of how effectively a business is utilizing its investment in inventory to serve its customers.
When calculating the cost of good for a specific location, transfers to other warehouses and sales of goods to customers are included in the calculation. This value is not the same as the usage number, since usage includes transactions, such as lost sales, which are not relevant to turns. Also, some reductions of inventory are not included in the cost of goods number because they cannot be tied directly to serving customers, e.g. inventory adjustments and returns to a vendor.
The calculated daily inventory value includes all of that day’s receipts. Today’s inventory value is yesterday’s ending inventory value plus all receipts of inventory on that day. That inventory value is then used to calculate the average inventory, which includes items that were received and shipped on the same day in the calculations.
Today’s ending inventory value is yesterday’s ending inventory plus today’s receipts minus today’s inventory reductions (some of which will be used for the turns calculations and some which will not).
After determining each day’s inventory value, the values are totaled and the divided by the number of days on which there was inventory activity. Not always dividing by 365 days produces a more accurate reflection of average investment in inventory.
For example: If an item has a cost of $1 and on January 1st 1 quantity of the item was purchased, and then sold on January 1 and never bought again, the daily inventory value is determined as follows:
When looking at daily inventory values, there is $1 on 1 day and $0 for all of the other 364 days of the year. If the average inventory value were calculated by adding them up and dividing by 365, the average inventory would be 1/365 = .002739; the total cost sold would be $1, so turns would be $1/.002739, producing 365 turns. This is clearly not an accurate reflection of the inventory investment use.
Instead, the average inventory is calculated as the total divided by the number of days the inventory was carried. The average inventory would be $1 / 1 day = $1. With a cost of goods being $1, the turns = 1, giving an accurate reflection of how $1 investment in inventory was used.
In this example, it should be noted that this item is not really a stocked item, and probably should have been flagged as non-stocked, in which case it would not factor into turns at all.
Finally, the calculations for average inventory rely on accurate cost layers. Prior to running the Turns Report, you should be sure the Item Balancing Register (ICR795) has been run and updated.
In the Cost Layers Processing Routine (ICC070), processing for Manufacturing Control formulation items was modified. Previously formulation items were not showing as usage after data conversion for negative quantities.
In the Production Confirmation (MCE140) program, the finished item for a bill of materials was not created using the proper receipt quantity unit of measure. In FACTS 7.8.5, the finished item information is read during the receipt creation and applied prior to creating the cost layer record, using the correct receipt quantity unit of measure.
Previously, the vendor number was not being assigned during Bill of Materials production confirmation. Code changes now allow the primary vendor number from ICMAST to be assigned during Bill of Materials Production Confirmation (MCE140) for the receipt cost layer.
In FACTS 7.8.5, the setting that controlled whether to wait for vendor action before issuing a customer credit or replacement was divided into two separate settings, one to control waiting for vendor action before issuing a customer credit and another to waiting for vendor action before issuing a customer replacement.
The wait for vendor functionality within FACTS remains the same as in prior releases but the settings location has moved.
Customer Returns Entry (SOE810)—Quick Entry Screen
In CRS Quick Entry the single 'Wait' column assigns both checkboxes to whatever is set in the grid.
Customer Returns Entry (SOE810)
In CRS Entry the Wait column was removed from the main screen.
In CRS Line Entry, the existing CRS Control F/M setting for the Wait Vendor Action checkbox defaults the value of both checkboxes. The checkboxes in both sections behave the same way as when only one checkbox was used. However, until either an invoice (having a credit price) is entered in the Line Entry or a Credit Price is entered in the Line Entry screen, the Wait Vendor Action checkbox in the Customer Return section will remain unchecked and disabled. When selection is made that disables either the Customer Return or Customer Replacement sections, the checkboxes will disable accordingly.
Customer Inquiry (SOI610)—Customer Returns View
The "Wait" column has been replaced with two columns "Cr Wait" and Rpl Wait", which correspond to the Customer Credit Wait and Customer Replacement Wait checkbox values. The filter option drop box has both 'wait' options available.
CRS Status Report (SOR820) and CRS Return Analysis Report (SOR830)
New options for Credit and Replacement have been added beneath the Wait Vendor Action/Repair heading on both the CRS Status Report (SOR820) and the CRS Return Analysis Report (SOR830). The values for the options are All, Yes, and No.
Additionally the Status section of CRS Status Report was expanded to include an additional option, Returns Waiting on Vendor Action/Credit.
The printed output for both reports now also includes the selections indicated for Credit/Replace.
In Order Entry and Direct Invoice Entry when entering an item with multiple FIFO layers, the calculated total cost was the first layer cost, which was chosen for the detail line cost display. This occurred when the Post Actual Total setting on the Inventory tab of SO Static Control was set to post actual total of LIFO/FIFO, not the weighted average. A message was displayed indicating that the cost was below GM minimum, which was set to zero. Issues were discovered when calculating the total cost (costing method is FIFO) when using for the GMPER calculation. The cost related issues applied when more than one receipt of a different cost is used to fill a disbursement.
The code correction can be summarized as:
SMC999;val_z4" to "prog/SO/SOF980;val_cost_method"
Program changes, detailed as follows, have corrected this issue:
Cost Layers Processing Routine (ICC070)
Fixed Get_Cost routine to convert to desired UM when supplied
Updated all calls to ICC070;Get_Cost to pass in proper UM in disbursement_params.qty_um$
Corrected issue with adjustment disbursements consuming multiple receipts will have incorrect quantity.
Transfer Processing Routine (ICC322) for Shipment Register (ICR320)
During sales order entry, the last cost is used and the quantity passed to ICC070; get_cost is in stocking, but the UM is not specified. For example, this would allow the value of 1 BX to not be interpreted correctly as 10 EA by ICC070 as an example for GET_COST. When the item is confirmed and the layers allocated, the proper conversion and cost is now returned and the line is updated.
Note: This change is for the COST_OUT$ on the transfer and does not impact GL for transfers.
Adjustment Entry (ICE210)
The incorrect cost was passed back to the line. This results in the incorrect cost going through the Adjustment Register (ICR210) program. The corrected Get_Cost routine now retrieves the proper cost for the adjustment. The issue in ICC070 was that an incorrect amount written to ICRDST when more than one ICRCPT is used.
Item Repackaging Entry (ICE220)
The new cost was not written to new receipt (The cost was used from the old receipt, and was not the correct average.) The incorrect cost pushed through the Adjustment Register (ICR210) program as the Adjustment Register does not recalculate the cost. This was corrected.
Quick Transfer Entry (ICE350)
The incorrect cost pushed through the Adjustment Register (ICR210) as the Adjustment Register does not recalculate the cost. This was corrected.
Transaction Cost Processing Routine (ICI663)
The Cost Layers view, available from the programs which currently support a Line Detail option to allow viewing of the Receipts used to fill the disbursement for documents, was corrected to convert to the proper costing UM display, not using the ICRCPT.Item_Num$.
Physical Inventory Discrepancy Report (ICR521)
The incorrect cost was pushed through the Adjustment Register (ICR210) program as the Adjustment Register does not recalculate the cost.
Stock Status Report (ICR711) and Surplus Stock Report (ICR716)
The incorrect cost could be returned when stocking unit of measure (UM) was not smallest UM. The stocking UM is now correctly set.
Capture Physical Counts (ICU511)
The incorrect cost was returned because the stocking unit of measure (UM) was not set correctly. The stocking UM is now correctly set.
Bill of Materials Inquiry (MCI614) and Formulation Inquiry (MCI625), Cost Views
The stocking UM was added to the cost look up.
MCR112 Processing Routine for Production Register (MCR110)
Removed unused code at line 8610.
MCR211 Processing Routine for Production Register (MCR210)
The issue with packaging cost extension not passing in the costing conversion factor and item number was corrected.
MCR711 / MCR712 Processing Routines for Bill of Materials Listing (MCR710)
Corrected call to ICC070;get_cost by passing in UM and proper warehouse variable.
BOM Cost Change Analysis (MCR740) / MCR741 Processing Routine
Corrected call to ICC070;get_cost by passing in UM and proper warehouse variable.
MCR751 / MCR752 Processing Routines for Formulation Listing (MCR760)
Corrected call to ICC070;get_cost by passing in UM and proper warehouse variable.
Formulation Cost Change Analysis (MCR780) / MCR781 / MCR782 Processing Routines
Corrected call to ICC070;get_cost by passing in UM.
POU931 Processing Routine for Manual Cost Change Update (POU930)
Corrected call to ICC070;get_cost by passing in UM.
The issue occurred when the cost was updated to Standard; other cost change methods were not impacted.
Bill of Materials Component Update (SOC135) Processing Routine
Modified mapping.
Expanded call enter list to include new variables needed by ICC070.
SOC503 Processing Routine
Leave quantity in selling UM and pass selling UM in via disbursement_params.qty_um$.
VAL_SHIP now calls DISBURSEMENT to allocate the layers and utilize the cost returned.
POST_WRITE_LINE now checks the cost when updating a disbursement and rewrites the line as needed.
CHANGE_WHSE now de-allocates and allocates versus just retrieving the cost.
In Direct Invoice Entry, creating a line now passes the proper quantity to ICC070.
SOC504 Processing Routine
Canceling out of editing a line performs the layer allocation to revert the quantity back to the original state.
This is based on the new change to VAL_SHIP and is not an issue with the current layer allocation.
SOC505 Processing Routine
GET_COST now initializes and uses disbursement_params$ when calling ICC070.
SOE513 / SOE514 Bill of Material Component Entry Processing Routines for Direct Invoice Entry (SOE510)
Updated the call to ICC070;get_cost to include the selling UM.
SOP321 / SOP322 Processing Routines for Counter Sale Print (SOP320)
Updated the call to ICC070;get_cost to include the selling UM.
Corrected the warehouse being used from INIT to SHIP warehouse.
SOU321 Processing Routine for Post Recurring Documents (SOU320)
Modified to use the selling quantity and selling UM. The program was as previously converting to smallest UM.
SOP311 / SOP312 / SOP313 / SOP314 / SOP321 / SOP322 Processing Routines for Daily Sales Register (SOR310)
The get_cost_of_existing_disb routine now updates the line item per unit cost of different and writes the changes to SORSOL.
SOE611 / SOR314 Processing Routines for Daily Sales Register (SOR310) and Process Pending Transactions (SOU610)
Expanded the call enter list for SOC135.
In the Sales Order Entry (SOE210), Order Confirmation (SOE320), Direct Invoice Entry (SOE510) and Credit Memo Entry (SOE330) programs the Exceptional Sale option is checked for an item that has an entry in ICWHSE, but is not flagged as Replenish = "Yes" on the Restocking view of Warehouse/Item F/M (ICF920). In FACTS 7.8.5 the default setting of the update_usage$ flag during the order entry process was updated to default to "Yes", unless the item is un-inventoried or flagged as an exceptional sale.
Previously in FACTS, ‘on-the-fly’ Bill of Materials components were not updating usage in the Sales Order Entry process. In FACTS 7.8.5, the usage update flag for bill of materials items is set to "Yes” by default for the component items during the Order Entry process to record hits and usage.
Order comments from SO documents were not displaying properly on the order confirmation displayed in Storefront. Code changes in the FACTS API no longer strip spaces from order comments so that the comments display correctly when reviewing orders in Storefront.
The Storefront Integration Layer was returning blank dates on the Review Orders and Paid Invoices screens.
In the FACTS API, fields were added in the PastInvoices metadata for ‘from’ and ‘to’ invoice dates. The use of a procedure for validating dates was removed, and instead, program ATC015 is now relied on to check, and convert, and filter dates, based on ATC012.
Previously, the encrypted credit card data from Storefront was not being handled by FACTS. The workaround for this issue was to turn off the option in the facts.properties file.
To correct this, the code that was checking for one of two variables to indicate that credit card data from Storefront was being sent encrypted (by default, it is being sent encrypted) was removed. One variable was set by the facts.properties file (api_cc_info_encrypted$="true"), but the other variable, got_cc_info_encrypted was never called anywhere in FACTS. The routine at 26300 of SOC508 sets the variable to 1, but the routine was never called.