invoice number generator

, ,
1

Hello all,

our invoice number is sequential (i.e. new invoice number = previous invoice number + 1). A simple subprogramm (running for many years) does the job as an invoice number generator.

get counter-view #ISN
add 1 to counter-view.counter
update

The calling program has to do the end/backout transaction. And that’s the problem. Not every calling program ends the transaction immediately. Sometimes that leads to deadlocks, NAT3009 etc. To do the end transaction inside the subprogram won’t work because it influences the transaction logic of the calling program.

So the question is: How to solve the problem?

Adabas/Natural is not able to handle nested ETs or something like that.
One idea is to call the invoice number geneator as a RPC-Program (btw: is it possible to call a local Subprogram via RPC?). It has a different Adabas-Session and so we could to an ET inside the subprogram without influencing the calling program. Any other ideas?

Regards

Matthias

2

Hi Matthias;

Instead of using a field as the counter, how about using the ISN itself as the invoice number.

Basically you would have an Adabas file devoted to nothing but keeping track of the invoice numbers.

Or, assuming you have a Master Invoice file, you could use a two step process.

STORE an invoice record
MOVE *ISN to ISN-COUNTER (field in the record)
UPDATE the invoice record.

In both cases, of course, the file would have to have non reusable ISNs.

steve

3

Hi Matthias,
According to the doc, “…The Natural RPC facility enables a client Natural program to issue a CALLNAT statement to invoke a subprogram in a server Natural. The Natural client and server sessions may run on the same or on a different computer”, your idea seems to be very “productive” :slight_smile: to me. Of course, there`s another “simple and stupid” solution: to force any calling program to issue ET (end transaction) just after after calling that generator to make sure that it (the calling program) got its own unique INVOICE NUMBER.

Like many shops we are also using the same logic (with the same drawbacks :-(; I`d be very interested in knowing about your progress in solving such a problem.

Best regards,
Nikolay

4

The first and most important question is:

Do the invoice numbers have to be sequential or are “gaps” allowed ?

5

Hi Steve!

Not a bad idea, but not every invoice number is numerical.
We got several number ranges and one of them begins with “F” or “B”.

Matthias

6

Gaps are allowed. Otherwise you couldn’t handle generate number, store invoice, backout transaction…

7

Ok, I don’t see the problem then, allocate the next invoice number independently of
the actual invoice, i.e. the subprogram does the GET - UPDATE - ET, no nested transactions.

8

… called via RPC.

So I’ll try it out.

9

A plain subprogram should do, no RPC required when you allocate
thet invoice number before any other updates have been issued.

10

And that’s the point. As I wrote above:

11

The code I suggested for using the ISN as the invoice number is easily modified since it is a two step process:

Instead of:

STORE an invoice record
MOVE *ISN to ISN-COUNTER (field in the record)
UPDATE the invoice record.

you simply:

STORE an invoice record
MOVE *ISN to ISN-COUNTER (field in the record)
IF prefix required
compress #prefix isn-counter into isn-counter leaving no space
end-if
UPDATE the invoice record.

Where #prefix has the required value (F or B)

steve

12

And what I tried to say was:

When the user invokes the invoice generation transaction the first thing done
is get the invoice number generated, before any transaction has been started.

If this is possible depends on the context, of course, when a transaction has
already been started when the invoice generation program is invoked then
that won’t work, of course.

13

Just some news:
We’ve implemented an RPC-Solution for the counter-problem. It’s just a simple subprogram in a special libary. Only the rpc-server knows this libary as a steplib.

Works good so far. :slight_smile:

14

Thank you for letting me know that, Matthias
(just got back from vacation in Andalusia: no NATURAL at all, but the nature itself was so beautiful! :slight_smile:

Best regards