Hi all.
I wonder if anybody can tell me what is happening with issue 2935 (not working record status handling) in Dynamics. The issue has been assigned, but there seems to be no decision on how it is going to be processed (the issue is still NEW)
I am especially interested on this one, so I'd be glad to hear from somebody at least about what's planned.
Best regards,
Andrzej Olszewski
Issue 2935 is flagged as a P3 and assigned, so it will get fixed at some
point but is not flagged as a high priority. If you need this more
urgently, you need to contact Progress support and escalate the issue.
This is functionality that came across from the Astra days - the
framework used as the basis for Dynamics, but has never been fully
implemented into Dynamics as yet.
Let me explain what the status stuff is all about. I pulled these notes
from a very old doc I had lying around...
The actual valid status codes are set-up in the category table. For
example:
related entity mnemonic = GSMST for gsm_status
category type = ACT for Account transaction
category group = INV for invoices
category subgroup = UNP for unposted, POS for posted, etc.
The category subgroup represents the actual status. The categories of
status will always be system owned and mandatory. The category mandatory
flag will be used to indicate whether an object at this status may be
modified.
At least 1 record must exist in the gsm_status table for every category
subgroup that has a related entity mnemonic of status (GSMST). This
record will be system owned, have a sequence of 0 and may not be
deleted. It will always be the default status for this category
subgroup.
This status table allows users to modify the narrative of the status,
and add extra status's within the same category subgroup to represent
their internal business processes.
From a business logic point of view, when the status changes within the
same category, we do not need to do anything and the user may do this
manually via a combo box. The change of status from 1 category to the
next within a category group however will usually be done via a business
logic process.
We will always need to join back to the category table to determine what
status an object is at from a business logic point of view.
The status an object is at effective from a specific date is determined
by an entry in the status history table, which means the status does not
need to be added to every table it is used for. However, in some cases
we have linked objects directly to the status table to show the current
status for performance reasons.
In summary, system owned records will be added to this table
automatically with a sequence of 0. System owned records may not have
the system owned flag or sequence modified, and may not be deleted. It
is not possible to add records to this table from the UI that are system
owned - this must be done by the take-on program.
Records added to this table must be for a system owned status category.
Once a record has been added, the category may not be modified.
HTH
Anthony
Anthony D Swindells
Lead Architect, Progress Dynamics
Progress Software Corporation
aswindel@progress.com
-Original Message-
Sent: October 15, 2002 1:10 AM
To: dev@icf.possenet.org
Subject: issue 2935
Hi all.
I wonder if anybody can tell me what is happening with issue 2935 (not
working record status handling) in Dynamics. The issue has been
assigned, but there seems to be no decision on how it is going to be
processed (the issue is still NEW)
I am especially interested on this one, so I'd be glad to hear from
somebody at least about what's planned.
Best regards,
Andrzej Olszewski