Support Alerts

From KeystoneIntranet
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Dispatch Schedule order shows the wrong Qty Delivered - 12/5/2024

PROBLEM: An order with a pre-ticketed load shows the wrong Qty Delivered total.

EXPLANATION: There is some as yet unknown issue where the pre-ticketed load never gets "released" when the truck comes back to the plant on it's previous load. (The DEPART_DT for the pre-ticketed load is NULL.)
A potential cause is running Beginning of Day between the time the pre-ticketed load is generated and the time the truck returns to the plant from it's previous load.

SOLUTION: The bug has not yet been identified.

Here is a query that can be used to set the DEPART_DT in the pre-ticketed load. This query should be run AFTER the load appears in Loaded status or beyond. 

UPDATE DITPRJLD PJ
 SET PJ.DEPART_DT = 
  (SELECT PH.BATCH_START_DT FROM ARTPTKHD PH
   WHERE (PH.ORDER_SESSION_NO = PJ.ORDER_SESSION_NO) AND
         (PH.ORDER_TRANS_NO = PJ.ORDER_TRANS_NO) AND
         (PH.ORDER_LOAD_NO = PJ.LOAD_NO))
WHERE
 (PJ.DEPART_DT IS NULL) AND 
 (PJ.STATUS_COL IS NOT NULL) AND
 (PJ.STATUS_COL <> 14) AND
 (PJ.STATUS_DATETIME BETWEEN :beg_date AND :end_date)

Tickets may be associated with the wrong invoice using Print Invoices in Keystone 4.7 and 4.7.1 - 10/10/2024

PROBLEM: When printing invoices, tickets may be associated with the wrong invoice or the invoice may not have a debit amount.

EXPLANATION: A bug exists in the ARP_GENINV procedure where the initial query on Z$ARTGENINVSORT is missing an ORDER BY clause. This can cause tickets to be processed out of the sequence in which the records were originally written to the Z$ARTGENINVSORT table, which can cause the two problems listed above.

SOLUTION: This bug is fixed in Keystone 4.7.1.7.

It appears that the invoices that were generated incorrectly can be voided and then re-billed. However, it is important to re-run the identification query below to make sure that the re-billing worked correctly (until the customer is updated to Keystone 4.7.1.7 or higher.)

Here is the query which can identify the invoices with "mis-matched" tickets or invoices that were never fully updated: 

select distinct iv.session_no, iv.trans_no, iv.cust_no, iv.job_po_loc, iv.invoice_date, iv.invoice_no
from artinv iv
inner join artslshd sh on (sh.ar_session_no = iv.session_no) and (sh.ar_trans_no = iv.trans_no) and
 ((sh.cust_no <> iv.cust_no) or (coalesce(sh.job_po_loc, '') <> coalesce(iv.job_po_loc, '')))
where (iv.invoice_date >= :start_date) and (iv.void_flag = 'N') and (iv.ticket_invoice = 'N')
union
select iv.session_no, iv.trans_no, iv.cust_no, iv.job_po_loc, iv.invoice_date, iv.invoice_no
from artinv iv
where (iv.invoice_date >= :start_date)  and (iv.void_flag = 'N') and (iv.ticket_invoice = 'N') and
(debit_amount = 0) and
(credit_amount = 0) and
(due_date is null) and
(ums_1 is null) and
(job_po_loc is null) and
(plant_no is null)

Batch weights cannot be seen in A/R Ticket Maintenance or A/R Ticket History Inquiry - 7/9/2020

PROBLEM: Plant tickets with batch weights seem to lose the batch weights once they are imported to the office.

EXPLANATION: A new field (BW_RECKEY) was added to the ticket header tables in Keystone 3.6.11.1. This field links tickets and batch weights together. The A/R Ticket Maintenance, A/R Ticket History Inquiry and Dispatch Batch Weights Report options all use this field to lookup the batch weights.

Due to a bug the "commit" logic in A/R Import Tickets does not copy this new field from the temporary table (Z$ARTPTKHD) to the office table (ARTTCKHD) when the user completes the import ticket process. (Note that the batch weights exist in the batch weights tables, it is just this new link field that doesn't get copied.)

SOLUTION: This bug is fixed in Keystone 3.6.14.5.

Here are three queries that can be run to re-link tickets with their associated batch weights:

Plant Tickets 

UPDATE ARTPTKHD TH SET TH.BW_RECKEY =
   (SELECT MAX(BH.RECKEY)
     FROM DITBWHD BH
      WHERE (BH.PLANT_NO = TH.PLANT_NO) AND (BH.TICKET_NO = TH.TICKET_NO) AND (CAST(BH.LOAD_DT AS DATE) BETWEEN TH.TICKET_DATE AND TH.TICKET_DATE+7))
   WHERE (TH.VOID_FLAG = 'N') AND (TH.BW_RECKEY IS NULL) AND EXISTS
   (SELECT 1
     FROM DITBWHD BH
      WHERE (BH.PLANT_NO = TH.PLANT_NO) AND (BH.TICKET_NO = TH.TICKET_NO) AND (CAST(BH.LOAD_DT AS DATE) BETWEEN TH.TICKET_DATE AND TH.TICKET_DATE+7));

Office Tickets 

UPDATE ARTTCKHD TH SET TH.BW_RECKEY =
   (SELECT MAX(BH.RECKEY)
     FROM DITBWHD BH
      WHERE (BH.PLANT_NO = TH.PLANT_NO) AND (BH.TICKET_NO = TH.TICKET_NO) AND (CAST(BH.LOAD_DT AS DATE) BETWEEN TH.TICKET_DATE AND TH.TICKET_DATE+7))
   WHERE (TH.VOID_FLAG = 'N') AND (TH.BW_RECKEY IS NULL) AND EXISTS
   (SELECT 1
     FROM DITBWHD BH
      WHERE (BH.PLANT_NO = TH.PLANT_NO) AND (BH.TICKET_NO = TH.TICKET_NO) AND (CAST(BH.LOAD_DT AS DATE) BETWEEN TH.TICKET_DATE AND TH.TICKET_DATE+7));

Invoiced Tickets (this may take a while) 

UPDATE ARTSLSHD TH SET TH.BW_RECKEY =
   (SELECT MAX(BH.RECKEY)
     FROM DITBWHD BH
      WHERE (BH.PLANT_NO = TH.PLANT_NO) AND (BH.TICKET_NO = TH.TICKET_NO) AND (CAST(BH.LOAD_DT AS DATE) BETWEEN TH.TICKET_DATE AND TH.TICKET_DATE+7))
   WHERE (TH.VOID_FLAG = 'N') AND (TH.BW_RECKEY IS NULL) AND EXISTS
   (SELECT 1
     FROM DITBWHD BH
      WHERE (BH.PLANT_NO = TH.PLANT_NO) AND (BH.TICKET_NO = TH.TICKET_NO) AND (CAST(BH.LOAD_DT AS DATE) BETWEEN TH.TICKET_DATE AND TH.TICKET_DATE+7));

Keystone sends the same ticket to a batch control more than once - 11/7/2018

PROBLEM: Keystone sends the same ticket to a batch control more than once because the Device Aggregator takes too long to respond to the "send ticket" command from the client program.

EXPLANATION: When Keystone Dispatch/Ticketing sends a ticket to the batch control (more correctly, to the Device Aggregator) it expects a response to the “send ticket” command within one (1) second. If it does not get a response in this timeframe, it will pause for 250 milliseconds and then re-send the ticket to the Device Aggregator. It will do this up to three times before giving up.

Normally this should never be an issue. The Device Aggregator is always running on a server on the local network, and it should never take more than one second to respond to the Keystone client programs.

However a situation was discovered at Vitale that caused the Device Aggregator to be “tied up” for about 4 seconds. During this time if a ticket was received the Keystone client program would timeout and re-send it.

Vitale has three Keystone companies. After the last Keystone update (which required a database upgrade) only one of their companies was upgraded, the other two were not (because no one had logged into them.) One of those two companies was “Practice” which is ignored by the aggregator. The second of the two companies was “Mix Import Testing” which was used for their install but which the customer does not login to. This company was *not* flagged as a Practice company. Therefore the aggregator was trying to process any devices in this company, but could not because the company database had not yet been upgraded. This actually causes an error within the aggregator which will force the aggregator to retry loading all the devices from all the companies again one minute later. Each time the aggregator reloads the devices it takes about 4 seconds to complete. During this time “send ticket” commands from Keystone clients cannot be processed. This is what led to the aggregator taking too long to respond to the client.

SOLUTION: After a Keystone update, be sure to login to ALL the companies (even the “Practice” ones!)

The next release build of Keystone (3.4.7) will handle this issue by increasing the client timeout value from one second to ten seconds. The aggregator will also respond immediately to the “send ticket” command instead of waiting until after it was able to send the command out to the device server (where the delay was happening.)


When changing the number of licensed InterBase users, you must edit CCWIBSV.INI - 10/2/2018

PROBLEM: When the number of licensed InterBase users is increased/decreased, Keystone 3.x does not recognize the change.

EXPLANATION: Keystone 3.x performs a calculation ONCE to determine the number of licensed InterBase users. It stores the result of this calculation in CCWIBSV.INI.

SOLUTION: Perform this procedure AFTER changing the number of licensed InterBase users:

  1. Start Notepad, making sure to select “Run As Administrator.”
  2. Open the ccwibsv.ini file in the folder “C:\Program Files (x86)\GivenHansco\Keystone\Settings.”
  3. Delete the entire line that begins with “MaxConnections=” as shown below:
  4. Save the file.
  5. Reboot the server.

Exception EOleException violation of FOREIGN KEY constraint "Z$ARTINV_FKY_CUST_NO" on table "Z$ARTINV" when running Print Invoices - 1/17/2018

PROBLEM: When running Print Invoices, you get the following error:

Error creating thumbnail: /bin/bash: /usr/bin/convert: No such file or directory Error code: 127

EXPLANATION: There is a field in the customer table called STMT_CUST_NO (Statement Customer). There is no integrity on this field -- the user can type whatever they want in it. At Invoicing time, the system checks to see if the STMT_CUST_NO exists, and issues the error above if it does not.

SOLUTION: Use Customer Maintenance to fix the Statement Customer field so that it contains either nothing or a valid customer number.

A/P and Payroll ACH Export no longer export valid files in Keystone 3.0 thru 3.1 - 1/16/2017

This issue has been fixed as of Keystone 3.1.1.

NOTE: Not all ACH export files require a security record. If the first column of the first line of the ACH file is a '1', there is no security record and the export file should be accepted.

PROBLEM: When generating an ACH export file in A/P or Payroll in Keystone 3.0 thru 3.1, the ACH file is rejected by the bank.

EXPLANATION: Keystone 3.x is developed on a newer version of Delphi that uses Unicode strings. Each character in a Unicode string is 2 bytes instead of 1. The "security record" at the beginning of the ACH file needs to be output as the older Ansi string style (1 byte per character.) In Keystone 3.0 thru 3.1, this string is output as a Unicode string (2 bytes per character.)

Here is an example of what the security record should look like in the export file: 

$$ADD ID=WARUSXXX BID='NWFACHXXXXXXXX'

Here is an example of what the security record looks like when exported with Keystone 3.0 thru 3.1: 

$ $ A D D   I D = W A R U S X X X   B

WORKAROUND:

  • Start IBCONSOLE.
  • Go into the company database and open the 'CMTACCT' table.
  • Locate the correct ACH bank account and scroll to the 'DD_SECURITY_REC' field.
  • The field will display as '(MEMO)'. Double-click the field to open the memo editor.
  • Select the *entire* field and copy it to the clipboard using CTRL+C.
  • Open the ACH export file in Notepad.
  • Select the *entire* first line and press CTRL+V. This will replace the incorrect header with the correct one.
  • Save the ACH export file and resubmit.

SOLUTION: Upgrade to Keystone 3.1.1.

Updating to Keystone 3.x gives message that your Windows version is not supported - 12/17/2016

PROBLEM: When starting a Workstation after the Server has been updated to Keystone 3.x, the workstation attempts to install the update but issues an error saying that your Windows version is not supported.

EXPLANATION: The Keystone desktop shortcut has been configured for compatibility with Windows XP SP2 (see image below.) This "tricks" the update installer into thinking it is running on Windows XP instead of the actual version of Windows, and refuses to run since Keystone 3.x requires Windows Vista or higher.

SOLUTION: Open the desktop shortcut properties, go to the "Compatibility" tab, and un-check the box that says "Run this program in compatibility mode." Restart Keystone and the update will install normally.

Backup/Restore when upgrading InterBase versions - 11/5/2016

When upgrading InterBase from one major version to another (for example, IB 7/2007/2009 -> IB XE7) you must backup and restore the Keystone databases (*.IB) as part of the process. You must backup prior to upgrading InterBase, then restore after the upgrade.

There was a time when you could just upgrade InterBase and use the same *.IB file without doing this, but it was never recommended. Now it seems that bad things can happen (such as indexes getting corrupted which results in very slow Keystone performance.)

The company database(s) can be easily done from the Keystone menu using the backup/restore options on the System Maintenance menu.

The document imaging (CCWDOC.IB) and system databases (CCWSYS.IB) must be done manually as outlined at the wiki page below (NOTE: you can skip the company databases when you follow the wiki procedure and instead use the normal Keystone backup/restore options for them.)

InterBase XE Update

Device Aggregator and Multiple Companies (including Practice) - 8/1/2006

This issue has been fixed as of Keystone 3.0 -- duplicate devices will be ignored by the Device Aggregator.

A very bizarre issue occurred at Environmental. For some unknown reason, status messages from GPS would suddenly cease to be processed by Keystone Dispatch.

After digging through the logs, Craig and I discussed the issue and discovered this when looking at the Devices setup on their system:

Error creating thumbnail: /bin/bash: /usr/bin/convert: No such file or directory Error code: 127

Environmental has their main company as 001 and their Practice company as 002. Looking into the company database configuration table in the Keystone system database, we see that BOTH companies are setup as “Normal” companies:

The Device Aggregator by default will ignore Practice company types, which would have prevented this situation, had their company 002 been properly configured as a PRACTICE company.

Installers should add this to their checklist: ALWAYS configure practice companies as “PRACTICE” company type when adding!

Keystone 2.9.17 and Keystone Mobile (On-Demand) Server - 6/22/2016

Due to a combination of circumstances customers who use Keystone On-Demand and are not yet on Keystone 3.x will need to update to Keystone 3.x in order for Keystone On-Demand to work correctly.

Customers who are still on 2.x but have not updated to 2.9.17 should continue to work normally. Once they update to 2.9.17, Keystone On-Demand will not function properly.

My suggestion at this point would be to get any remaining customers who are using Keystone On-Demand but are not yet on 3.0 updated as soon as possible.

Keystone Updates and "Run As Administrator" - 2/26/2016

While getting Silvi updated today, Jeff mentioned that GH support had told him that if a Keystone update failed to install that he should right-click the Keystone icon and select “Run As Administrator.”

First point: You should NEVER have to do this. The update is designed with Windows security in mind, and automatically starts itself with the necessary permissions.

Second point: When installing a Keystone update, if you double-click the Keystone icon and the update fails to install, this is an indication of a Windows security configuration issue. If you right-click and select “Run as Administrator” to get the update installed, it will likely lead to problems down the road when users try to run Keystone.

The bottom line is – if there is a problem with a Keystone update install, do not do the “Run as Administrator” shortcut, but work on getting the core Windows configuration issues resolved. In Silvi’s case, once we realized what was going on, it took their IT guy about 10 minutes to straighten this out.

See also this item for another potential issue with Keystone Updates.

Keystone 2.9.7 - Exception when starting Plant Maintenance - 2/19/2016

This issue was fixed in Keystone 2.9.8.

PROBLEM:

When opening Plant Maintenance in 2.9.7, you may receive this error:

EDBException: cdsLookup3: Field ‘BILLING_PLANT_NO’ not found

ANALYSIS:

Note that it is difficult to re-create this in-house, because it requires that someone have started up one of the Dispatch/Ticketing options that also opens the plant lookup. The issue occurs because the office plant lookup query was changed to include the new BILLING_PLANT_NO field, but the Dispatch/Ticketing plant lookup queries were not. All three of these lookup queries share the same “cache key.” So if the Dispatch/Ticketing lookup is cached first, it does NOT contain the new BILLING_PLANT_NO field. When office Plant Maintenance is started, it determines that the plant lookup query does not need to be refreshed and uses the cached version instead. Unfortunately, the cached version does NOT have the new BILLING_PLANT_NO field, leading to the error.

SOLUTION:

This will be fixed in the next build of Keystone. As a workaround, you can check the “Disable Cache Datasets” option in the Keystone Application Server configuration page. (Please keep track of these if you do this as we will want to re-enable cache datasets when the fix is implemented.)

Trying to issue UPDATE/DELETE query in the XE7 version of IBConsole gets error - 2/11/2016

A change was made by Embarcadero to the XE7 version of IBConsole. When executing queries within IBConsole, by default only SELECT queries are allowed. Attempting to issue an UPDATE or DELETE query gives the following error:

Please see this topic for the solution.

Keystone 2.9.2 Installer Issue with InterBase XE7 64-bit - 1/7/2016

This issue was fixed in Keystone 2.9.3

A problem has been discovered in the Keystone 2.9.2 installer. The situation that occurs is this (assuming a new install on a clean machine):

  1. InterBase XE7 64-bit installed
  2. Keystone 2.9.2 installed
  3. After Keystone license screen, an error message appears indicating that the “ISQL.EXE” command could not be executed.

The cause of this is that both InterBase XE7 and Keystone 2.9.2 rely on a shared Windows DLL (MSVCR120.DLL.) There are two versions of this file installed by InterBase XE7 64-bit: the 32-bit version installs into C:\WINDOWS\SYSWOW64 and the 64-bit version installs into C:\WINDOWS\SYSTEM32. After Keystone 2.9.2 is installed, the 32-bit version of MSVCR120.DLL remains but the 64-bit version of MSVCR120.DLL no longer exists. This causes the InterBase “ISQL.EXE” command to fail.

To prevent more customers from experiencing this issue I have pulled the Keystone 2.9.2 update. I’ve got a fix in place and tested and am working on a Keystone 2.9.3 release build. Once this is ready I’ll send another email.

If you encounter this issue on an existing customer after they update to Keystone 2.9.2, please contact me and I will implement a fix. (NOTE: If an existing customer has this problem and installs Keystone 2.9.3 it will NOT fix the issue.)

Double-click to edit items on-the-fly in Keystone - 8/13/2015

As of Keystone 2.8.2 there is a new system option (in the System-Wide section) called “Edit On The Fly”.

This option defaults to True.

You can set it to False, which will not allow that user to double-click a lookup item (e.g. Product Code) to launch the file maintenance program associated with that item.

This will allow you to set this option to False for remote desktop users who get into trouble when they double-click a Product Code in Order Maintenance, but instead of double-clicking they triple or quad click.

Keystone Company Database Backup Fails - 4/9/2015

This issue was fixed in Keystone 2.6.7

An issue was discovered at Moritz Concrete that was causing backups of the company database within Keystone to fail with the following error:

Manually running the GBAK command from the command prompt worked fine.

When Keystone backs up the company database, it first uses the InterBase GBAK command to make a backup of the database to a temporary file. This temporary file is (normally) located in the following subfolder underneath the Windows temporary folder:

<Windows Temp Folder>\GivenHansco\Keystone

Because the “GivenHansco\Keystone” folder doesn’t exist on a new install, Keystone will create this folder the first time the user attempts to backup.

Prior to Keystone 2.6.7, Keystone would “auto-create” this folder *once* for each Application Server run. (In other words, if you reboot the server, causing the Application Server to restart, it would “auto-create” this folder on the next attempt to backup.) As part of attempting to solve the problem at Moritz, Don deleted the files and sub-folders within the Windows temp folder. Since the Application Server was still running, it did not attempt to “auto-create” the necessary folder and this caused Keystone backup to fail.

As of Keystone 2.6.7, this folder will be “auto-created” as needed for every attempt to backup the database.

Dispatch Schedule gets error "Multiple Rows for Singleton Select" at startup - 12/31/2013

This issue was fixed in Keystone 2.7.2

For customers that upgraded to versions 2.7.0 or 2.7.1, they may get the following error when they attempt to start the Dispatch Schedule:

“Multiple Rows for Singleton Select”

To fix this, run the following SQL commands using IBConsole: 

SET TERM ^ ;

CREATE PROCEDURE IBCO1249_FIX_VOIDLOADS
AS
DECLARE VARIABLE ORDER_SESSION_NO INTEGER;
DECLARE VARIABLE ORDER_TRANS_NO INTEGER;
DECLARE VARIABLE ORDER_LOAD_NO INTEGER;
DECLARE VARIABLE TEMP_CNT INTEGER;
BEGIN
FOR SELECT ORDER_SESSION_NO, ORDER_TRANS_NO, ORDER_LOAD_NO, COUNT(*)
  FROM ARTPTKHD
   WHERE (ORDER_LOAD_NO IS NOT NULL)
    GROUP BY ORDER_SESSION_NO, ORDER_TRANS_NO, ORDER_LOAD_NO
     HAVING (COUNT(*) > 1)
      INTO :ORDER_SESSION_NO, :ORDER_TRANS_NO, :ORDER_LOAD_NO, :TEMP_CNT
DO
  UPDATE ARTPTKHD
   SET ORDER_LOAD_NO = NULL
    WHERE (ORDER_SESSION_NO = :ORDER_SESSION_NO) AND
          (ORDER_TRANS_NO = :ORDER_TRANS_NO) AND
          (ORDER_LOAD_NO = :ORDER_LOAD_NO) AND
          ((VOID_FLAG = 'Y') OR (VOID_SESSION_NO IS NOT NULL));
END
^

EXECUTE PROCEDURE IBCO1249_FIX_VOIDLOADS;

(be sure to COMMIT after this command) 

DROP PROCEDURE IBCO1249_FIX_VOIDLOADS;

Print Invoices generates duplicate numbers when printing from the preview screen - 5/2/2013

This issue was fixed in Keystone 2.6.1

We have discovered a problem with Print Invoices (affects all reports but Print Invoices is the worst) when the user prints from the preview screen.

If the user clicks the PRINT button while previewing invoices by using the F12 key, and then immediately hits the F12 key again, this will cause two runs of Print Invoices. Unfortunately only some of the temporary information is cleared between the runs, which causes duplicate invoice numbers and missing tax & g/l transactions.

For now, users should NOT use F12 on the preview screen while previewing invoices. We are working on a fix for Keystone.

Extra products with strange descriptions appearing in Product Code drop-down list in Ticket Maintenance, Ticket Printing and Order Maintenance - 2/14/2013

This issue was fixed in Keystone 2.5.24

This was discovered at Twin Cities after updating to Keystone 2.5.23.

There is a bug in the new database procedure that returns the list of products for the Product Code drop-down list. However, as a workaround you can do the following query on the customer’s system and it will fix the drop-down list: 

UPDATE ARTPROD
SET LINK_PRICE_PRODUCT = null
  WHERE (LINK_PRICE_PRODUCT = '');

Dispatch Schedule gives never-ending Access Violation errors at startup - 12/17/2009

PROBLEM: When starting the Dispatch Schedule, you get a never-ending series of Access Violation error boxes. Also, Dispatch Order Maintenance does not start at all.

EXPLANATION: There are old versions of some Keystone libraries (*.BPL) in the Keystone BIN directory. Files with the '.BPL' extension should exist only in the LIB directory.

SOLUTION: Check the BIN directory under the Keystone root directory for the presence of any files with a '.BPL' extension. If any are found, delete them.

Sales Tax Calculation Problems Converting to Keystone 2.2

New Diagnostic Query: Keystone 2.2 Sales Tax Conversion Diagnostics

Performance problem when closing out of menu options as of 2.2.4 - 12/10/2008

Keystone 2.2.4 introduced a performance problem when closing out of menu options. Due to a faulty database trigger, customers with large amounts of historical data would notice that the EXE continued to run for up to 20 seconds after the program was closed. When chaining from one program to another (i.e., editing a vendor from A/P inquiry) the calling program would have to wait for this delay before user input would be accepted.

This performance problem has been fixed as of 2.2.15. It is highly recommended that all 2.2.x customers upgrade to this version as soon as possible.

Old Device Server (ccdevsv.exe) removed as of 2.2.4 - 10/14/2008

As of Keystone 2.2.4, the old device server (ccdevsv.exe) has been removed from the installer.

Any customers using the old device server with Keystone 2.2.x should be moved to the new device server/aggregator as soon as possible.

Going forward, there is no guarantee that the old device server will continue to work with Keystone.

Never copy IB database files between systems! - 10/10/2008

It is very important when moving Keystone database files between systems that you backup the database on the source system and restore it on the target system.

NEVER COPY .IB FILES BETWEEN SYSTEMS! If the source system is running IB 2007 and the target is running IB 7, the copied .IB file will not work!

Dispatch - Lose trucks for active orders when End of Day is run on live tickets - 04/30/2008

PROBLEM: Dispatch End of Day causes trucks to disappear from Schedule Screen.

EXPLANATION: End of Day removes tickets from ARTPTKHD. Data in the ARTPTKHD/DT is required for the loads to show correctly on the schedule screen. All loads for associated with missing tickets disappear. If a truck is in the returning status, it will still show on available truck. Any truck on a load that wasn't returning will disappear.

THE FIX:

View todays tickets that have been imported: 

select ticket_no,order_code,order_load_no,truck_no,return_plant_dt from arttckhd t
where ticket_date='4/30'

View the associated loads 

select l.* from ditprjld l
where
 exists (
select order_session_no,order_trans_no,ticket_no,order_code,order_load_no,truck_no,leave_job_dt from arttckhd t
where ticket_date='4/30' 
 and t.order_session_no=l.order_session_no and t.order_trans_no=l.order_trans_no and l.load_no=t.order_load_no)

Review Today's loads with no associated plant ticket (revised way to view - 11/10/08) 

select l.* from ditprjld l
where tgt_depart_dt>cast('today' as date) and
 not exists (
select order_session_no,order_trans_no,ticket_no,order_code,order_load_no,truck_no,leave_job_dt from artptkhd t
where ticket_date=cast('today' as date)
 and t.order_session_no=l.order_session_no and t.order_trans_no=l.order_trans_no and l.load_no=t.order_load_no)
AND DEPART_DT IS NOT NULL


Fix any loads that are not Status 8 

update ditprjld l
set return_dt=tgt_return_dt,status_col=8
where status_col<>8 and l.return_dt is null and 
 exists (
select order_session_no,order_trans_no,ticket_no,order_code,order_load_no,truck_no,leave_job_dt from arttckhd t
where ticket_date='4/30' 
 and t.order_session_no=l.order_session_no and t.order_trans_no=l.order_trans_no and l.load_no=t.order_load_no)

SOLUTION: An upcoming version of keystone will fix this problem.

A/R Void Invoices - Foreign key violation when using Automatic Reconcile option - 01/10/2008

PROBLEM: Foreign key violation exception when selecting the Automatic Reconciliation option.

EXPLANATION: The user running the A/R Void Invoice program has never run Print Invoices. The Void Invoice program looks at the A/R G/L account system option that is saved by Print Invoices to determine the A/R G/L account to use for the automatic reconciliation.

WORKAROUND: Login as the user who wants to void the invoice, and run Print Invoices in Preview mode. This will save the appropriate system option.

SOLUTION: Version 2.1 will include a fix which will get the A/R G/L account from the invoice that is being voided.

HIT User only for GivenHansco Staff - 01/04/2008

Never give customers the HIT user name and password. The HIT user has special function and security settings, including the bypassing of automatic backups when upgrading database versions.

Remote Ticketing Systems - Do Not Install by Backup up Office Data - 11/07/2007

PROBLEM: Remote Ticketing Systems created with an office backup expose the customers system to security risk. Sensitive data can end up at remote locations.

SOLUTION: Follow standard procedure for creating Remote Ticketing Systems. This starts with a clean database. We need to identify all remote systems that may have office data and provide an cleaning script.

Where are my Trucks?!?!?! - 10/16/2007

PROBLEM: Truck Disapears while dispatching.

EXPLANATION: The most common cause of this is caused when: a truck in returning status is assigned to a pre-ticket then the pre-ticket load is voided then the Return Truck to Previous order option is selected.

This combinition of events leaves pointers in ARTTRUCK pointing to a voided record, and leaves the load record in a quasi-delivered state.

SOLUTION: Development is redesigning the truck pointer logic to fix this. In the mean time, when possible these problems can be passed to development for further diagnosis.

NOTE: Manipulating Dispatch Data can have severe consequences. The following update will only help specific situations. It is presented here for only emergency cases.

The Fix Process: Note: Make sure this is the correct fix for the situation. If the load actually shipped you should try to fix it up. If the load hasn't shipped you can clear it as below.

Examine the truck record... 

select * from arttruck where truck_no='XXX'

Record the Current Order and Load and Last Ticket Information.

Reset the Truck pointers: 

UPDATE ARTTRUCK
SET LAST_TICKET_SESSION_NO=NULL, LAST_TICKET_TRANS_NO=NULL,CUR_ORDER_SESSION_NO=NULL,CUR_ORDER_TRANS_NO=NULL,CUR_ORDER_LOAD_NO=NULL
WHERE TRUCK_NO='91'

Examine the load. If the load is partially completed reset it: 

UPDATE DITPRJLD
SET STATUS_COL=NULL,STATUS_DATETIME=NULL,TRUCK_NO=NULL,DEPART_DT=NULL,RETURN_DT=NULL
WHERE ORDER_SESSION_NO=94019 AND ORDER_TRANS_NO=7 AND LOAD_NO=1
select * from gptstatus where truck_no='91' order by seq_no desc

Product Cost Rollup Doesn't seem to be working - 10/12/2007

PROBLEM: Customer will run product cost rollup, but many of the costs will not be accurately calculated.

EXPLANATION:

Product cost rollup gets the cost from a Cost transaction in the table artprtrx. For several versions of CompuCrete 1.6.x there was a bug where cost changes where not triggering the cost record to be written to Artprtrx. The result is that cost changes were not updated for existing products, and never written at all for older products.

As far as we know, there is no actual bug in Product Cost Rollup. If one is found please advise support. The problem that we see is that even though the product maintenance bug has been fixed for a long time, there will be some lingering products with incorrect or missing costs.

SOLUTION: Read through Identify and Fix Products With No Standard Cost Records and check for both missing and out of date costs. If only a few products are problems, you can fix them by changing the cost to a lower cost, then resetting to the current cost. If several products are wrong, then you will need to run the fix query.

Restore Database leads to Stream Error - 09/13/2007

PROBLEM: When attempting to restore a company database backup, an error indicating "Stream Read Error" occurs.

EXPLANATION:

The database restore code prior to version 2.0.16 would not properly handle a database size > 2GB. The database would backup correctly, but when attempting to restore will incorrectly state the size of the original database, causing the error.

SOLUTION: Upgrade to Keystone 2.0.16 or later.

System Lockup after Logging off Server - 05/01/2007

PROBLEM: After logging off the server while KEYSTONE users are active, the following may occur:

1. Users can no longer log in. The splash screen appears and then hangs.

2. Users who were logged in cannot start additional menu options. The selected option never starts.

3. Users who were logged in cannot log out of KEYSTONE. The message saying that KEYSTONE is ending hangs.

EXPLANATION:

The KEYSTONE Application Server is a DCOM server application. When the server is logged off, the Application Server is sent a message notifying it that the server is logging off. Shortly thereafter, a termination code is sent to the application, which is only partially processed. The Application Server continues to run and service any existing connections, but no new connections are accepted.

PREVENTION:

Once a user logs in to the server, they should never log out. The alternative is to use the "Lock Computer" function in Windows for security.

SOLUTION:

The only solution is to tell the currently logged in users to get out of KEYSTONE as much as possible. Then:

1. On the server where the KEYSTONE Application Server is running, issue the DOS command: 

TELNET 127.0.0.1 6600

2. You will see a message from the Application Server. Type: 

KILLSERVER

3. You will see a warning message asking you to terminate the Application Server. Type: 

Y

4. Now you need to check the Windows Task Manager and verify that the "ccasib6.exe" process is not running. If it is still running, repeat from step 1 until you have verified that the Application Server has terminated.

5. Stop and Restart the Borland Socket Server service through Control Panel->Administrative Tools->Services.

Classic Conversions - 12/1/2006

Since the 1.8 classic conversion program has not been (nor will be) updated, the procedure going forward when upgrading a Compucrete classic customer will be to upgrade them from classic to 1.6, then web update to 1.8.

Web Update Problem - 11/30/2006

In builds 1.8.14 and 1.8.15, there is a problem with Web Update.

Some symptoms are:

1. The customer previously updated to 1.8.14, they successfully download 1.8.15, release it, restart CC, but it never installs.

2. On multi-user systems, the clients may see "Application Server is older than client" or "Application Server is newer than client" depending on the order they installed the update.

The correct solution is:

1. Open IBConsole

2. Open the CCWSYS.IB database

3. Open the CCTUPD table

4. Verify/change the UPDATE_VERSION field to the correct value

5. Verify/change the PENDING_FLAG field is set to "Y"

6. Commit the change

CompuCrete 1.8 Upgrades - 11/26/2006

As a precautionary measure, the following procedure should be done immediately prior to releasing the 1.8 upgrade.

For each company database:

1. Login to the company.

2. Backup the company to hard disk. If any errors occur, STOP!!!

3. Restore the company from the hard disk backup just created.

Once this has been done for each company, release the 1.8 upgrade and login to each company, verifying that the company database upgrade completes without error.

Interbase fails to accept network connections - 11/3/2006

PROBLEM: There is a potential issue with Interbase 7.1 refusing to accept incoming network connections.

SYMPTOMS: When the user starts CompuCrete, they see the Activation dialog.

A message in the interbase.log file says:

Unable to complete network request to host "(servername)".
Error while listening for an incoming connection.
An attempt was made to access a socket in a way forbidden by its access permissions.

SOLUTION:

This problem appears to be prevalent in Windows Server 2003. You need to modify the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Look for a key named "ReservedPorts". If you don't see one, create a new multi-string value and give it this name.

Right-click and select Modify.

Add the following line to the end of the list (if there are existing entries):

3050-3050

Close the registry editor and reboot the server.

System Tables - 11/30/2005

It is VERY important that the CCTLIC and CCTUSER tables in the CompuCrete system database NEVER EVER be edited using IBConsole!

These tables contain encoded security fields that are (partially) based on the content of several other fields within the table. If any of those fields are edited with IBConsole, the encoded security fields are no longer valid, and the user will receive the 'User table corrupt' error when they try to log in.

If this happens, the only solution is to delete the affected user records out of CCTUSER and then use CompuCrete User Maintenance to add the users back in.

Retrieved from "http://in.compucrete.com/index.php?title=Support_Alerts&oldid=1036"