** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
The original message was received at Tue, 15 Sep 1998 04:38:15 +0200 (IST)
from walnut.iea-software.com [126.96.36.199]
----- The following addresses had transient non-fatal errors -----
----- Transcript of session follows -----
<Emeraldfirstname.lastname@example.org>... Deferred: Connection timed out with main.nmt.co.il.
Warning: message still undelivered after 4 hours
Will keep trying until message is 3 weeks old
Reporting-MTA: dns; mail.barak.net.il
Arrival-Date: Tue, 15 Sep 1998 04:38:15 +0200 (IST)
Final-Recipient: RFC822; Emeraldemail@example.com
Remote-MTA: DNS; main.nmt.co.il
Last-Attempt-Date: Tue, 15 Sep 1998 08:38:48 +0200 (IST)
Will-Retry-Until: Tue, 6 Oct 1998 04:38:15 +0200 (IST)
Received: from walnut.iea-software.com (walnut.iea-software.com [188.8.131.52])
by mail.barak.net.il (8.9.1/8.9.1) with ESMTP id EAA11643
for <Emeraldfirstname.lastname@example.org> Tue, 15 Sep 1998 04:38:15 +0200 (IST)
Received: from walnut.iea-software.com (walnut.iea-software.com [184.108.40.206]) by walnut.iea-software.com (NTMail 4.00.0020/NT6651.00.c89adb95) with ESMTP id za000593 for <email@example.com> Mon, 14 Sep 1998 19:16:29 +0100
Received: from [220.127.116.11] by walnut.iea-software.com (NTMail 4.00.0020/NT6651.00.c89adb95) with ESMTP id rigaaaaa for <firstname.lastname@example.org> Mon, 14 Sep 1998 19:16:24 +0100
Received: from calypso (aquarius.com.au [18.104.22.168])
by triton.aquarius.com.au (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with SMTP
id MAA00322 for <email@example.com> Tue, 15 Sep 1998 12:21:43 +1000
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 15 Sep 1998 12:21:42 +1000
To: "firstname.lastname@example.org" <email@example.com>
From: Glen Harvy <firstname.lastname@example.org>
Subject: Accounting periods
Content-Type: text/plain; charset="us-ascii"
X-ListMember: Emeraldemail@example.com [firstname.lastname@example.org]
I charge my customers as at the 15th monthly. That is, for the period
starting at 0000 on the 15th and until 2359 on the 14th of the month.
I have my accounts set to expire on 09/15/98 on the Billing cycle in the MBR.
I ran Call Consolidation on the 15th expecting the call data from 08/15/98
to 09/14/98 to be consolidated and placed in the History table. The
previous time I ran Call Consolidation was on 15th August.
To explain my problem and as an example, on 09/14/98, one of our customers
record showed TIME ON from 08/15/98 to 09/15/98 as 53 hours. After Call
Consolidation on 09/15/98, TIME ON was calculated by Emerald for the same
period as 27 hours.
What APPEARS to have happened is the data from the period prior to 08/31/98
has been consolidated. The data from 09/01/98 remains in the Time On section.
When I ran call consolidation I entered 09/15/98 as the Invoice Date.
Examining the Call History for the above example customer, the Start Date
shows 08/15/98 and the time is 45 hours.
Can you explain or elaborate on these two issues:
A. Can the Calls Table be consolidated on the basis that it will always
include the data from the beginning of the current billing cycle to
whenever Call Consolidation is actually ran. Alternately, can the Calls
Table always contain the current billing period's data. This is of some
importance to me as I use SQL queries to enable my users to access details
of all calls for the current period.
I realise that some ISP's call data may be substantial and consolidation
may need to be ran more frequently. I would therefor like to see what I
propose as at least an option.
B. What was the actual time used by my client from 08/15/98 to 09/14/98 in
the example I have used above?
AQUARIUS Communications for all your Internet<>Fidonet needs
<>Full ISP services<>FrontDoor Commercial<>TransX Internet/FTSC Mailer
http://www.aquarius.com.au <> mailto:email@example.com