Heck, I'd kiss him too. This is an eminently sane idea.
Cheers,
Richard (who hasn't yet started inputting data into his 1.2.4 test
system, but will do Real Soon Now)
Quoting Charley Tiggs <[EMAIL PROTECTED]>:
> I have clients that would kiss you if they could have that 'un! :)
>
> Charley
>
On 4/26/07, John Hasler <[EMAIL PROTECTED]> wrote:
> Gerald writes:
> > Of course changing a transaction in this environment will become
> > impossible, making auditors very happy and end-users looking for ways
> > around the system.
>
> It is quite possible to create a reversing entry and mark it
Gerald writes:
> Of course changing a transaction in this environment will become
> impossible, making auditors very happy and end-users looking for ways
> around the system.
It is quite possible to create a reversing entry and mark it so that the
transaction appears to have been changed to the us
Hi David;
The model was a vague one with only minimal items shown for
illustration (hence the reference that the table model could be far
more complex than mentioned).
Most of the database design work is being done by Josh Drake, and he
is an expert in such things and if he doesn't do it, I am su
On Thu, 2007-04-26 at 19:36 -0700, Chris Travers wrote:
> On 4/26/07, Gerald Chudyk <[EMAIL PROTECTED]> wrote:
>
> > Are you planning total integration between accounting modules? I
> > designed a gl like this once. The issues with ar and ap are fairly
> > clear; each transaction is a db/cr to a f
On 4/26/07, Gerald Chudyk <[EMAIL PROTECTED]> wrote:
> Are you planning total integration between accounting modules? I
> designed a gl like this once. The issues with ar and ap are fairly
> clear; each transaction is a db/cr to a few well defined gl accounts
> with a reference to customer/vendor
On 4/26/07, Chris Travers <[EMAIL PROTECTED]> wrote:
> Hi all;
>
> I have been thinking a great deal about the data organization of
> financial transactions for 1.4 even though we are not there yet. I
> think we can all agree we need to have a central table which tracks
> every financial transacti
I have clients that would kiss you if they could have that 'un! :)
Charley
Chris Travers wrote:
> The other thing this would allow would be for a general journal report
> (a description of every transaction in chronological order of entry)
> with payments appearing in the proper places.
>
> Bes
The other thing this would allow would be for a general journal report
(a description of every transaction in chronological order of entry)
with payments appearing in the proper places.
Best Wishes,
Chris Travers
On 4/26/07, Charley Tiggs <[EMAIL PROTECTED]> wrote:
> Chris Travers wrote:
> > Hi a
Chris Travers wrote:
> Hi all;
>
> I have been thinking a great deal about the data organization of
> financial transactions for 1.4 even though we are not there yet. I
> think we can all agree we need to have a central table which tracks
> every financial transaction and which other tables may j
Hi all;
I have been thinking a great deal about the data organization of
financial transactions for 1.4 even though we are not there yet. I
think we can all agree we need to have a central table which tracks
every financial transaction and which other tables may join to. I
would propose that thi
--- Chris Travers <[EMAIL PROTECTED]> wrote:
> I have some ideas about preventing duplicate submissions but nothing
> definite yet.
>From past descriptions, the planned in-database business logic will return an
error for any invalid-action input, whether it comes from the browsers UI, a
resumbitte
On 4/26/07, John Locke <[EMAIL PROTECTED]> wrote:
> This is what REST is about--REpresentational State Transfer. All of the
> state information is kept in the request, so the server doesn't need to
> maintain state for each request. This has the benefits you're looking
> for--proper browser history
--- Ed W <[EMAIL PROTECTED]> wrote:
> Please show me an example. My point is that REST is irrelevant, it's
> just a different encoding for the same kind of interface. However,
> unless someone can show me a feature of cookies which makes them in some
> way browser window specific, I claim tha
Hi
> This is what REST is about--REpresentational State Transfer. All of the
> state information is kept in the request, so the server doesn't need to
> maintain state for each request. This has the benefits you're looking
> for--proper browser history, ability to have different sessions in
> diff
Ed W wrote:
> Hi
>
>
>> and to make matters worse, many of the
>> input forms do a really, really ugly hack where each time a new item is
>> added, instead of preserving state somewhere it's sent back to the client -
>> html and all - in a hidden field. This alone makes it nearly impossible
Hi
> and to make matters worse, many of the
> input forms do a really, really ugly hack where each time a new item is
> added, instead of preserving state somewhere it's sent back to the client -
> html and all - in a hidden field. This alone makes it nearly impossible to
> properly protect ag
> OK. What we could try out is to have the work area above, and the
> menu across the bottom. With CSS, the work area would be a fixed
> vertical size and scroll. Without CSS, the work area would drop down
> until it ran out. For the majority of forms, this would not be a big
> deal, but a lon
18 matches
Mail list logo
