STMT.NOS IN FUNDSTRANSFER EQ "VAL"

HI,

THE CREATION OF A TRANSACTION IN THE FUNDS.TRANSFER APPPLICATION FROM A VERSION WITH TRANSACTION.CODE EQUAL ACTC THE FIELD STMT.NOS IS EQUAL TO "VAL" AND NOT THE VALUE OF THE KEY IN THE STMT.ENTRY TABLE WHY.

THANKS.

Hi
version need an other person to do authorize it. If you don't want in version set no.of.auth = 0

Hi,

ACTC not releated to cheque.collection is a copy of AC transaction.


Thanks.

When Accounting Entries are raised at Input Stage the STMT.NOS field will be set to VAL only. At this stage the Entry ID is not formed. This entry is temporarily written into the ENTRY.HOLD file and once the Transaction is Authorised these entries are deleted and written onto the respective STMT.ENTRY, CATEG.ENTRY or SPEC entries...Only after the entries are written into the Accounting Entries related files the ID is generated and written back on to the Transaction.

Hi,
The STMT.NOS is equal VAL after authorisation of transaction.

Thanks.

Seems like Accounting was raised incorrectly.. Can you post the screen shot of the Transaction and also the Code ( If it is Local subroutine) that does the Accounting. Also screen shot of the ENTRY.HOLD record of the Transaction

Hi, Please see attached file.

Thanks.

Attachment ???

Thanks

hi, please find attachement
*File FBNK.FUNDS.TRANSFER , Record 'FT1501535349'
Command->
0001 ACCT
0002 00078810100000A1
0003
0004 1
0005 TND
0006 50.000
0007 20150115
0008
0009
0010
0011 00078834800000A1
0012 1
0013 TND
0014
0015 20150115
0016
0017
0018 20150115
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0029
0030
0031
0032 TEST
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045 WAIVE
0046
0047
0048
0049 WAIVE
0050
0051
0052
0053
0054
0055 2
0056
0057 NO
0058
0059
0060
0061
0062 NO
0063 TR
0064
0065
0066
0067 ]]]]]]]]]]]]]]]
0068
0069
0070 TND50.000
0071 TND50.000
0072
0073
0074
0075
0076
0077
0078
0079
0080 D20150522595623267000-900.1.1 DEBIT ADVICE
0081 TN0010001
0082 TN0010001
0083
0084
0085
0086
0087 50.000
0088 50.000
0089
0090
0091
0092
0093
0094 5
0095 2
0096 2
0097
0098 Y
0099 NO
0100
0101 2
0102
0103
0104
0105
0106
0107
0108
0109
0110
0111 0
0112 0
0113 0
0114 0
0115
0116
0117
0118
0119
0120
0121
0122
0123
0124
0125
0126
0127
0128
0129
0130
0131
0132
0133
0134
0135
0136 NO
0137
0138
0139
0140
0141
0142
0143
0144
0145
0146
0147
0148 0
0149 0
0150
0151
0152
0153 20150115
0154
0155
0156
0157
0158
0159
0160
0161
0162
0163
0164
0165
0166
0167
0168
0169
0170
0171
0172
0173
0174
0175
0176
0177
0178
0179
0180
0181
0182
0183
0184
0185
0186
0187
0188
0189
0190
0191
0192
0193
0194
0195 VAL
0196
0197
0198 1
0199 92520_AAAA-BBBB
0200 1505220904
0201 59562_AAAA-BBBB2[A
0202 TN0010001
0203 1

You already said the FT transaction has Stmt nos field set to VAL. But please post the relevant details like the subroutine that is attached in the Version you use to input the FT. The screenshot of ENTRY.HOLD record.

HI,

Effectively there is a problem in subroutine attached, Key length problem during creation of a record on the template, thank you the problem is resolved.

HI,

Effectively there is a problem in subroutine attached, Key length problem during creation of a record on the template, thank you the problem is resolved.

Hi,
I come back to you with the same problem at the level of some applications STMT.NO EQ VAL transaction authorized without accounting entry, TT FT DC LC, have you experienced the very delicate case and cause inconsistency problems, is there a native report T24 which could indicate a similar situation to us.

Hi,
I come back to you with the same problem at the level of some applications STMT.NO EQ VAL transaction authorized without accounting entry, TT FT DC LC, have you experienced the very delicate case and cause inconsistency problems, is there a native report T24 which could indicate a similar situation to us.