Support Alerts - Revision history

Pmorey at 21:02, 19 October 2025

2025-10-19T21:02:18Z

← Older revision		Revision as of 21:02, 19 October 2025
Line 1:		Line 1:
			==Keystone Relay Server fails to start - 10/19/2025==

			PROBLEM: Even though the Keystone Relay Server service is installed, it does not start when Windows is booted.

			EXPLANATION: At JDM it was observed that the service took longer than 30 seconds to start running. (This is likely due to some network protection service.) The default timeout for Windows to start a service is 30 seconds, after which time Windows will abort the service.

			SOLUTION: Increase the Windows service start timeout to 60 seconds.

			# Start PowerShell using Run As Administrator.
			# Type: <b>Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control" -Name ServicesPipeTimeout -Value 60000 -Type DWord</b>
			# Reboot the server

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

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

2024-12-05T20:31:37Z

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

← Older revision		Revision as of 20:31, 5 December 2024
Line 3:		Line 3:
	PROBLEM: An order with a pre-ticketed load shows the wrong Qty Delivered total.		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.)		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.)<BR>
			<i>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.</i>

	SOLUTION: The bug has not yet been identified.		SOLUTION: The bug has not yet been identified.

Pmorey at 19:51, 5 December 2024

2024-12-05T19:51:31Z

← Older revision		Revision as of 19:51, 5 December 2024
Line 1:		Line 1:
			==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.)

			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. <b><i>This query should be run AFTER the load appears in Loaded status or beyond.</i></b>

			<pre>
			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)
			</pre>

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

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

2024-10-10T14:49:34Z

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

← Older revision		Revision as of 14:49, 10 October 2024
Line 20:		Line 20:
	select iv.session_no, iv.trans_no, iv.cust_no, iv.job_po_loc, iv.invoice_date, iv.invoice_no		select iv.session_no, iv.trans_no, iv.cust_no, iv.job_po_loc, iv.invoice_date, iv.invoice_no
	from artinv iv		from artinv iv
	where (iv.invoice_date >= :start_date) and (iv.void_flag = 'N') and		where (iv.invoice_date >= :start_date) and (iv.void_flag = 'N') and (iv.ticket_invoice = 'N') and
	(debit_amount = 0) and		(debit_amount = 0) and
	(credit_amount = 0) and		(credit_amount = 0) and

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

2024-10-10T14:48:43Z

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

← Older revision		Revision as of 14:48, 10 October 2024
Line 16:		Line 16:
	inner join artslshd sh on (sh.ar_session_no = iv.session_no) and (sh.ar_trans_no = iv.trans_no) and		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, '')))		((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')		where (iv.invoice_date >= :start_date) and (iv.void_flag = 'N') and (iv.ticket_invoice = 'N')
	union		union
	select iv.session_no, iv.trans_no, iv.cust_no, iv.job_po_loc, iv.invoice_date, iv.invoice_no		select iv.session_no, iv.trans_no, iv.cust_no, iv.job_po_loc, iv.invoice_date, iv.invoice_no

Pmorey at 10:39, 10 October 2024

2024-10-10T10:39:10Z

← Older revision		Revision as of 10:39, 10 October 2024
Line 1:		Line 1:
			==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:

			<pre>
			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')
			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
			(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)
			</pre>

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

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

2023-07-17T16:22:16Z

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

← Older revision		Revision as of 16:22, 17 July 2023
Line 153:		Line 153:
	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:		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:

	[[File:DevAggMultCos2.png\|800px]]		[[File:800px-DevAggMultCos2.png\|800px]]

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

WikiAdmin: 1 revision imported

2023-07-14T13:00:37Z

1 revision imported

← Older revision

Revision as of 13:00, 14 July 2023

Intra>Pmorey at 13:25, 9 July 2020

2020-07-09T13:25:15Z

Show changes