Is that a typo? Fictive???? Not sure I have ever heard that term…..

Not a typo, related to this I believe

/ifsdoc/documentation/en/Accrul/frmEntryVoucher.htm

Ok, translating the help here basically means, at the point of loading the file, the application will put in a placeholder value and then during the translation into the target transaction table it will convert this placeholder value and put in a real value. It gives the example of COMPANY as a value, and then replaces with the actual company ID #. 

Fictive in this case refers to fictional, e.g. made up value in order for the process to work.

You may see this in other areas of the system where IFS needs a value when first creating a record (such as on supplier record, payment authoriser usually shown as * meaning IFS Application Owner) - you can change this later but in order for the process to work it needs a value in there so one is put in for you.

Hope that clarifies it for you.

If you set up a custom event on logical unit VoucherRow, the voucher number on a new record will be a negative number. After the transaction commits, you won’t find that voucher number any more. This means if you want to fire a background job to go do something with this new record, you won’t be able to find it.

That negative voucher number shows up inside the transfer ID on the new record. The transfer ID is a dollar-sign-delimited string containing things like the user, company, and voucher type. The code calls the last entry of the transfer ID the “fictive” voucher number, and that happens to be the voucher number you’d see inside the event action.

From a technical perspective, if I want to create a background job against a new voucher, I have to get the fictive voucher number from the event, then later when I’m looking in the voucher table, I have to look for transfer IDs that end in that number.

Where this technical view crosses into the business view is where my understanding ends. What is going on from a financial standpoint? Why can’t a voucher be created with its final voucher number up front without this intermediate step? I don’t know what I don’t know, and I want to be sure some custom code I’m writing doesn’t have any unintended side effects.

Other areas of the system pick up numbers from the Enterprise series IDs, and when you trap their values inside custom events, you won’t be confused by some number that will go away once it commits.