I posted a couple of proposals for new MV features on my little site:
http://www.tom-phillips.info/mv.proposals.index.html
I welcome any comments, improvements, criticism or other feedback.
Thanks in advance,
Tom

Unless I am misreading the requirements, QM can already do both of
these. We also have a variant on date conversions that produces ISO
week numbers which are certainly widely used in business on this side
of the Atlantic.

Martin Phillips, Ladybridge Systems.

Thanks for the reply Martin,
I see in the OpenQM docs a method to assign output to a hold file and supply
a item name. Thank you.
What I failed to find was a solution to the problem of accounting periods.
Specifically a method providing range selections and computing the number of
months between periods.
I'm assuming you do not have a data type where the "period" is stored a an
integer number of months, but are referring to the standard output date
conversions. As I stated in that proposal, I have gotten around this by
storing the "period" as a date where the day was the first of the month/year
used. But I found a better way was to store the "period" as an integer
months, but this required all kinds of pre-select and post-processing work.
Please correct me if I'm wrong.
Regards,
Tom

"None" <MartinPhillips (AT) ladybridge (DOT) com> wrote

Hi Tom,

Ok, maybe we don't quite have what you are after. If it is an "industry
standard" requirement, we would be very happy to add a code to do it.
Of course, QM also allows you to add your own conversion codes via
QMBasic subroutines so you could do it entirely yourself.

MartinPhillips, Ladybridge Systems.

Thanks Martin,
Yes - being able to create my own conversion codes would certainly work, as
is currently the case with calling a subroutine as part of output conversion
in a dictionary item.
My purpose with the proposals was to - in fact - get the vendors to
collectively add the features.
My guess is that they are all going to follow what you do, as you seem to be
out front in trying to widen the base of MV users.
RD's only interesting feature that I've noticed was their ease of accessing
files across machines with their "super Q" pointers, and file prefixes like
"dos:" and "unix:". Full pathing would only take them backwards (but I
digress).
U2's efforts seem to be in the xml arena.
My issues are directed to the core product.
I've accumulated lots of ideas and "work-arounds" over the years, and I
wanted to "publish" some of these to fuel some comments by others. A oconv
conversion code to "fold" data comes to mind.
Regards, Tom

"None" <MartinPhillips (AT) ladybridge (DOT) com> wrote

Suggest that wrap should fold on blank if possible.
uv has some obscure call !FOLD I think that does do this, the ! means it's
globally cataloged ot otherwise to be found in the bit caves.

Chandru Murthi

"Tom Phillips" <squash (AT) computer (DOT) org> wrote

Goo'day, Tom,

On Fri, 18 Aug 2006 12:58:42 -0400, "Tom Phillips"
<squash (AT) computer (DOT) org> wrote:

There is a further complication...

In my experience retailers (and some wholesalers, too) tend to use
either 13 periods in a year (13 x 4 discrete weeks) or a system of 4
or 5 full-week "months" working from Sunday (or Monday) to Saturday
(or Sunday). This, I'm told, permits them to analyse on a per-week
basis, overcoming, for them, the fact that months vary in length, and
they want to compare to a "standard" unit, and that a month may well
be too long a period where they're trying to catch trends almost on a
day by day basis.

If a user employs either 13 periods or 4 and 5 week periods, the
period start dates are bound not to be the first day of a calandar
mont, nor would the period end date be the last day of the calandar
month.

Which is why we use a CCYYPP (century, year, period) form of
accounting period, together with a parameter "NO.OF.PERIODS" and a
scale of "Period End Dates" which is maintained annually, and easily
accessed from dictionary items using subroutines.

That way, we really don't care what "standard" they use....... To the
extent that some smaller Oz businesses, now that GST reporting is
permitted quarterly, only want 4 General Ledger periods per year.....
combined with weekly "Sales" reporting......



Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

Thanks Bruce - very good point.
I'm wondering if a secondary value containing the number of months or units
in the period would do the trick?
You know - an optional sub value as part of the codes: Example J2-;13 on the
output side and J;13 on input.
In my accounting systems I use a calendar where the period and date range
are defined. That way I can take any date and query the calendar to get the
period. What I still need subroutines for is calculating the number of
months or units between periods.
In your schema a subtraction of 200601 - 200503 would require the period
base to complete the math.
It's an interesting problem. I just wish there was a generic way to handle
it in the OS so that we all are spared the coding.
It's like in the non-mv world where every shop has a zillion date conversion
routines and many don't work too well.
I suspect that there are a lot of not very flexible accounting packages
also.
Regards, Tom
PS - I added a couple more suggestions this afternoon.
http://www.tom-phillips.info/mv.proposals.index.html

"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote

As for D3, or D3/Linux for sure, you can already output the print job to a
file.

See the documentation for ASSIGNFQ. You'll see stuff about 'cat' to a file.

The only fly in the ointment here is that I have never found a way of
removing the assignment without rebooting, it can only be changed.

Regards,

Dale

"Tom Phillips" <squash (AT) computer (DOT) org> wrote

Tom:

Just making sure that you are you talking about following GAAP (Gneraly
Accepted Accounting Practices that publicly owned companies tend to
follow) rules on the first one. If I remember right, that rule allows
for artificial 30-30-31months that make into quarters like2006-1 2006-2
2006-3 and 2006-4 December being the variable depending on February.

Henry Keultjes

Tom Phillips wrote: