tfB40_c

SESSION ERROR IDENTIFIED IN: tfcmg1257m000 "Post Payments"

tfcmg2112s000 "Maintain Anticipated Payment Status"

tfcmg2113s000 "Maintain Anticipated Receipt Status"

tfcmg2116s000 "Maintain Anticipated Payments (Details)"

tfcmg2117s000 "Maintain Anticipated Receipts (Details)"

tfcmg4130m000 "Send Trade Notes/Cheques to Bank"

tfcmg4257s000 "Post Direct Debits"

PROBLEM TEXT:

1-Reference error

I am using the direct debit procedure to select a purchase credit note, but the session Post Direct Debits aborts and gives an

error message:

Fatal Error: Error 606 (reference does not exits on tccom021812 in SELECT

We have check table tccom021 and the reference does exist but do not understand why it even references this table.

Fatal error: Can not continue in tfcmg4257m000

Error: tfcmg4257m000: a not terminated transaction is aborted

SOLUTION DESCRIPTION:

Program function was not filling the value for the supplier number and thereby attempting to save a record with an empty

supplier number, giving a 606 reference error. This programming error has be corrected with ID 92. This problem does not

occur in 3.1.

tf

VERSIONS:

3.1b, 3.1b1, 3.1b2

B40a, B40a1, B40a2

B40b, B40b1, B40b2, B40b3

SESSION ERROR IDENTIFIED IN:

Tfcmg1260s000 - Transfer Payments

PROBLEM TEXT:

An "Error 107" is being received while the system is attempting to transfer payments.

SOLUTION DESCRIPTION:

Report tfcmg1260l1000 is changed. Sort order for the fields is changed from 'Presorted' to 'Ascending' for all sort fields.

This change has been made with ID 57.

SITUATION IDENTIFIED IN: Print Statements of Account (tfacr3440m000)

SITUATION DESCRIPTION:

The problem was that the header would not align correctly when you printed the statement account. In customer

statements (accounts receivable), Maintain Statement of Account Letters, a header was entered that looked like it

was aligned. However, in Print Statements of Account, the header would not be aligned when it printed.

SOLUTION DESCRIPTION:

The problem cannot be totally eliminated. This is because the alignment is in the hands of the user and it also depends on the

size of the field defined in the header and footer. The comment attached to this defect gives the sizes of all possible fields.

Hence if layout of the fields is done using these sizes the result will be aligned. This solution solves defect 329.

tfB40_b3

SITUATION IDENTIFIED IN: Maintain Integration Relations (tfgld4123s000)

SITUATION DESCRIPTION:

This defect was fixed with PD ID 10240588; however, when we tried to complete

the delivery on Olympus, it only delivered in B40a.

SOLUTION DESCRIPTION:

The modified components for this ID were redelivered to B40_b4. This solution solves

defect 661.

VERSION(S):

tfB40L_b_glo0, tfB40L_b1_glo0, tfB40L_b2_glo0, tfB40L_b3_glo0

tfB40L_b_gls0, tfB40L_b1_gls0, tfB40L_b2_gls0, tfB40L_b3_gls0

SITUATION IDENTIFIED IN: Maintain Purchase Order LinesInvoices (tfacp1110s000)

SITUATION DESCRIPTION:

Entered a purchase invoice for $1200.00 using sessions tfacp1110s000 & tfacp1130s000. I left the invoice at a registered

status. Before matching, I changed the amount of the invoice to $1000.00. The field "amnt" in the acp200 = 1000, and

"amti" = 1200. When the invoice was approved, the approval document was out of balance. The debit was for 1000, and the

credit to registered invoices was 1200.

Changes made to an invoice amount in acp1110s000 do not update the amount in invoice currency in the acp200, therefore,

approval documents are out of balance.

SOLUTION DESCRIPTION:

The glo & gls VRCs were using old routines for storing and restoring data. It has now been replaced with the new routines

which take care of storing and restoring the whole table. Therefore now the new values for amount in invoice currency is

corrected. This solves defect 490.

tf3.1a2

tf3.1b7

tfB40_b4

tfB40_c1

SITUATION IDENTIFIED IN:

Close Year (tfgld6203m000)

SITUATION DESCRIPTION:

When you execute the session tfgld6203m000 the system will generate opening balances for the next year. Before generating

these opening balances the system will check if (only) the accounts have closing balances. It¦s a problem because you can

have accounts with zeros in the closing balances, and in other hand, you can have closing balances for the combination

Ledger Account/Dimension, and the system doesn¦t check it.

SOLUTION DESCRIPTION:

The zero balance check for ledger accounts is removed, hence even if the ledger account balance is zero, transactions will

be created now. The same change is done for tfgld6202m00 (Automatic Balancing of Profit and Loss Accounts). Transactions

will now be created if a non-zero ledger/dimension combination is found. This solution solves defect 690.

tf3.1_a, tf3.1_a1

tf3.1_b, tf3.1_b1, tf3.1_b2

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

SITUATION IDENTIFIED IN: Assign Credit Note to Invoices (tfacr2121s000)

SITUATION DESCRIPTION:

If you create an invoice for a CAD customer in CAD currency then create a credit for the same customer in USD currency, the

balance in tfacr2522s000 Display Sales Invoices changes after you link the two together. The ending balance is not even

correct. This was originally addressed with solution #849 and ID 10242895. The solution appeared to fix the problem but it

is happening again.

SOLUTION DESCRIPTION:

These are corrections to earlier fixes 10240386 and 10242895. These fixes updated the customer balances when a credit note is

linked to a customer invoice. Actually customer balances are not to be updated here unless there is a currency difference

between invoice and credit note exchange rate. When a customer invoice is entered the customer balance increases to show the

new balance. When a credit note is entered the customer balance decreases according to the amount of the credit note. If the

invoice and credit note having different exchange rates are linked, and a currency difference is noted between the invoice

and credit note then only this difference figure is now added to the customer balances. The same changes were done to

reflect supplier balances in Accounts Payable.

This solution solves defect 350.

tf3.1_b, tf3.1_b1, tf3.1_b2,

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3.

SITUATION IDENTIFIED IN:

Maintain Integration Relations by Ranges (tfgld4122s000).

SITUATION DESCRIPTION:

Connecting integration option "series" with relations is not possible, because the zoom session does not work in session

"Maintain integration relations by range" (tfgld4122s000) or in session "Maintain integration relations by element"

(tfgld4123s000).

SOLUTION DESCRIPTION:

When connecting an integration option with option "series", the zoom will now work in both tfgld4122s000 and

tfgld4123s000.

This solution solves defect 12656.

tf3.1_b, tf3.1_b1, tf3.1_b2

tf3.1L_b_glo0, tf3.1L_b1_glo0, tf3.1L_b2_glo0

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

tfB40L_b_glo0, tfB40L_b1_glo0, tfB40L_b2_glo0, tfB40L_b3_glo0

tfB40L_b_gls0, tfB40L_b1_gls0, tfB40L_b2_gls0, tfB40L_b3_gls0

SITUATION IDENTIFIED IN: Register Purchase Invoices (tfacp1110s000)

SITUATION DESCRIPTION:

The annual turnover is not updated in the table tccom021/011 even if invoices are registered (the invoice balance is

appearing normally in the supplier/customer open-entries).

SOLUTION DESCRIPTION:

After some discussion with development, it was decided that turnover should NOT be updated in finance, but rather, all

updates to turnover should take place in distribution. Therefore, the functionality to update turnover in finance has been

removed.

This solution solves defect 11407.

tf3.1_b, tf3.1_b1, tf3.1_b2

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

SITUATION IDENTIFIED IN: Maintain Dimensions (tfgld0110m000)

SITUATION DESCRIPTION:

I chose an existing dimension code(001) under dtyp 2 and created an identical dimension code(001) under dtyp 3. The

dimension code(001) under dtyp 2 has had transactions processed and history exists. The dimension code (001) under dtyp 3 has

no history, but I still receive the dimension in use. Cannot delete error (tfgld9078). I ran this in debug with Ajith and he

determined that the check in the code for tfgld206 has a bug. It does not recognize the dtyp associated with the dimension

code when checking history. Therefore it will not let me delete the code under dtyp 3 because history exists for the same

code under dtyp 2.

SOLUTION DESCRIPTION:

Users will now be able to delete a dimension code that exists in two dimension types, as long as it does not have any

transactions in the dimension type that the user is trying to delete it from.

This solution solves defect 797.

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3.

SITUATION IDENTIFIED IN:

Correct Company Number after Copying Company - tfgld9000m000.

SITUATION DESCRIPTION:

There have been several cases logged from the field regarding errors, during the running of the tfgld900[0-3]m000 session.

When the tests were performed, the following 2 errors were generated:

Assume the source company is 431 and the target company is 800.

Before running tfgld900[0-3]m000, in company 431:

tccom000 has one record: 431 (as expected).

tfgld000 has one record:

Financial company: 431 (as expected),

Logistic Company: 431.

After running tfgld900[0-3]m000 successfully without errors, when changing company number 431 to 800, in company 800:

tccom000 has two record: 431 (which should have been deleted (Error 1)) and 800 (as expected).

tfgld000 has one record:

Financial company: 800 (as expected),

Logistic Company : 431 (which should have changed to 800 (Error 2)).

SOLUTION DESCRIPTION:

A few tables, with references to the company table tccom000, were added.

Duplicate record creation, just in case a table that has both the financial and logistic company fields is corrected, so that only

one record is created.

The logistic company number is updated only if the financial company number is the same as the logistic company number. There

are more than 139 tables with references to the tccom000 table. Most references in the packages tt, tf, ti, td, tc and ts have

been corrected so that they point to the new company record.

However, it will not be possible to delete the old record from tccom000 until all the references to the old record (from

tccom000) have been replaced in the non-mandatory packages,.

Hence, the old record from tccom000 can be deleted manually if required. However, since the purpose of these programs is to

setup a working/testing environment and not a live environment, some of the anomalies (such as extra records that remain in

the tables) should not affect the testing work.

tf3.1_b, tf3.1_b1, tf3.1_b2

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

SITUATION IDENTIFIED IN: Display Payments on Purchase Invoice (tfacp2523s000)

SITUATION DESCRIPTION:

If you zoom and examine a particular document for a supplier in session tfacp2523m000, the fields amount and balance

amount towards the top of the screen always have zero in them.

SOLUTION DESCRIPTION:

The program was selecting anticipated receipts instead of anticipated payments when selecting invoices from the invoice table

tfacp200. This lead to unpredictable results as the select was actually a join between acp200 and acr200 tables.

This solution solves defect 846.

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

tfB40L_b_glo0, tfB40L_b1_glo0, tfB40L_b2_glo0, tfB40L_b3_glo0

tfB40L_b_gls0, tfB40L_b1_gls0, tfB40L_b2_gls0, tfB40L_b3_gls0

SITUATION IDENTIFIED IN: Update Integr Trans and Real Time Post to Finance (background) (tfgld4200s000)

SITUATION DESCRIPTION:

Need ID 10229978 in globalized objects of program tfgld4200.

SOLUTION DESCRIPTION:

The globalized objects were missed out in the delivered objects in ID 10229978.

This solution solves defect 860.

tf3.1_b, tf3.1_b1, tf3.1_b2

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

tfB40L_b_glo0, tfB40L_b1_glo0, tfB40L_b2_glo0, tfB40L_b3_glo0

tfB40L_b_gls0, tfB40L_b1_gls0, tfB40L_b2_gls0, tfB40L_b3_gls0

SITUATION IDENTIFIED IN: Match Receipts (tfacp1131s000)

SITUATION DESCRIPTION:

When completely matching a receipt line, the matched amount is getting increased for no reason.

When you partially match a receipt line, then tab through the invoiced amount field, the number registers in the 'matched

amount' field at the top. Now, when you save the current screen by clicking the disk button, the 'matched amount' field

increases again by the amount in the 'invoiced amount' field. This will keep on happening every time the invoiced amount

field is accessed or updated.

SOLUTION DESCRIPTION:

The "Matched Amount" field will now update only one time, with the correct amount.

This solution solves defect 829.

tfB40_b, tfB40_b1, tfB40_b2, tfB40_b3

tfB40L_b_glo0, tfB40L_b1_glo0, tfB40L_b2_glo0, tfB40L_b3_glo0

tfB40L_b_gls0, tfB40L_b1_gls0, tfB40L_b2_gls0, tfB40L_b3_gls0

SITUATION IDENTIFIED IN: Match Receipts (tfacp1131s000)

SITUATION DESCRIPTION:

In maintain transactions-tfgld1101m000, select match purchase invoice transaction type. Enter invoice and link to a purchase

order that has 3 or more recept lines. Select continue, link=no auto match=no, Takes you to session tfacp1131s000. At this

point, highlight one receipt line. Go to form 2, then back to form 1. Select another line/highlight. The system will

automatically take you to form 2 where it will hang and eventually you will have to kill the process.

SOLUTION DESCRIPTION:

The problem is in the standard program which is changing the current form. Currently, a workaround has been put in so that

the saved form number is restored after the mark operation. Even without this solution if one presses the

form 2 button when the hour glass is displayed the mouse pointer will be restored. Then one can press the form 1 button to

go to form1 without problems.

This solution solves defect 852.

3.1a2, 3.1b5, tfB40_a2, tfB40_b, tfB40_b_glo0, tfB40_gls0, B40_mcr0, tfB40_c.

SITUATION IDENTIFIED IN:

Match purchase receipts - (tfacp1131s000).

ATTACHMENTS:

Not applicable.

SITUATION DESCRIPTION:

When there is an order with a matched quantity equal to zero and a matched amount unequal to zero, no price difference will

be calculated. This is correct.

When the matched amount is changed, a price difference is calculated. When the amount is changed again, the new price

difference is added to the old price difference. So the price difference increases every time the matched amount is changed.

SOLUTION DESCRIPTION:

When calculating a new price difference for an invoice, the old price difference on the order is sub-stracted from the price

difference for the invoice and the new price difference on the order is added. The calculation of the old price difference

on the order went wrong when the matched quantity was zero. This caused the price difference for the invoice to increase

every time the matched amount was changed. This has now been corrected.

tf3.1_b, tf3.1_b1, tf3.1_b2, tf3.1_b4, tfB40_b1, tfB40_b2, tfB40_b3

SESSION ERROR INDENTIFIED IN:

tfacr2260m000 Remove Fully Paid Invoices

OTHER SESSIONS:

PROBLEM TEXT:

When you create a Sales Invoice and link an Unallocated Receipt to it, you can see in session tfacr2522s000 (via

tfacr2521m000) that the Sales Invoices is fully paid.

After you have done that you must run the session tfcmg3200m000 Update Customer Statistics. When you have done that

you can run the session tfacr2260m000 Remove Fully Paid

Invoices. After running that session you can see in tfacr2522s000 that the Sales Invoice is remove but not the Unallocated

Document. This is not right.

The same problem occurs for a Journal Voucher.

SOLUTION DESCRIPTION:

There is a modification done on the script of tfacr2260m000 Remove Fully Paid Invoices. Now the Unallocated Receipt which

is linked to an Invoice is deleted at the same time as

the Sales Invoice.

The problem mentioned in the problem text about a Journal Voucher cannnot be solved because a Journal Voucher has no

record in table tfacr200 'Open Items'.

tp3.1_b, tp3.1_b2, tp3.1_b5, tp3.1_b6, tpB40_a1, tpB40_b1, tpB40_b2, tpB40_b3.

SESSION ERROR IDENTIFIED IN:

tpppc2111m000 "Maintain Material Costs".

tpppc2151m000 "Maintain Equipment Cost".

tpppc2171m000 "Maintain Subcontracting Costs".

tpppc2191m000 "Maintain Sundry Costs".

PROBLEM TEXT:

You can change the document number for costs registered in Finance and split to Project. By default, the system will give the

invoice number. If you change this number (which should be possible), then the table is filled in differently (field cdoc) to the

way that it is for the default value. This causes problems with reports/queries.

SOLUTION DESCRIPTION:

The document number is by default aligned to the left. If the field is maintained manually then it is aligned to the right.

The leading zeros have no purpose. So, the field is now always aligned to the right. It has a length of 10 and the leading

zeros have been removed. The modifications to the software components have been marked with DF10803

3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

Maintain Bank Transactions (tfcmg2100s000)

PROBLEM TEXT:

It is possible to create a sales invoice for period 4 and to enter the receipt in period 3 using session tfcmg2100s000.

At least a message should be given that the payment date is before the invoice date.

SOLUTION DESCRIPTION:

The program gives a warning, when you are using Customer or Supplier Transaction and you choose an invoice with period or

document date later than the bank transaction.

3.1_b, B40_b.

SITUATION IDENTIFIED IN:

Print Reconciliation of Work-in-Process - tfgld5400m000.

SITUATION DESCRIPTION:

Session tfgld5400m000 prints all the projects, irrespective of whether the project has a value or not. When the customer

prints a report from session tfgld5400m000, he or she is faced with a large number of pages, including the pages from the

projects with a zero value.

Also, the total sum of the variances is not printed as expected at the bottom of the last page, and as a consequence it has to

be calculated manually. An extra field for the total value of the variance would be convenient.

SOLUTION DESCRIPTION:

The reports now have the choice as to whether to print the zero values or not. With report tfgld54001100 and tfgld54003100 a

grand total field is included.

For all the PVRCs a new label is generated for the question on form: "Suppress zero values".

For B40_b4 some labels need to be added.

tfB40_b4, tfB40L_b4_glo0, tfB40L_b4_gls0, tfB40L_b4_mcr0, tfB40L_b4_sch0,

tfB40_c1

SITUATION IDENTIFIED IN:

Maintain Integration Relations By Range ( tfgld4122s000 )

Maintain Integration Relations By Elememt ( tfgld4123s000 )

Maintain Integration Relations By Range ( tfgld4124s000 )

Maintain Integration Relations By Element ( tfgld4125s000 )

SITUATION DESCRIPTION:

When inserting in tfgld4122s000 data,zooming on Main item's warehouse wrong session arises. The normal session which

should arise is the warehouse's one and not

tcmcs0506s000:Display unit set.

SOLUTION DESCRIPTION:

The correct zoom session has been added to the include which determines the sessions zooomed to.

3.1_b, B40_b, B40_c.

SESSION ERROR IDENTIFIED IN:

tfacp1120s000 "Maintain Transaction Purchase Invoices".

tfacr1111s000 "Maintain Transaction Sales Invoices".

SITUATION DESCRIPTION:

The situation can be duplicated as follows:

1. Book a purchase invoice directly on a ledger account by using acp1110s000 and 1120s000.

2. Make a purchase invoice correction with session acp2110s000. Press Y - you will get session acp1120s000 for entering a

ledger account.

3. Instead of filling in this account, press E.

4. You will get the message 'still transactions to be entered'. After first pressing enter and then E you will be returned to

session gld 1101m000.

5. You will see that the document does not balance.

6. Go to the transaction type session acp 2110s000 again and press Y on the invoice that you have changed (step 2) - you

will NOT get session acp 1120s000 again.

It is not possible to make an adjustment in a batch after you have left it.

SOLUTION DESCRIPTION:

Processing the invoice correction to maintain the transaction must not be finished until the transaction is balanced. It has

to be done in this way because you cannot make an adjustment for this transaction type after leaving tfacp2110s000.

(Technical note: There is no record to operate on).

When you want to leave tfacp1120s000/tfacr1111s000, after you have made invoice corrections, the whole correction must be

posted.

SESSION ERROR IDENTIFIED IN: tfacr2121s000 "Assigning credit notes to invoices"

PROBLEM TEXT:

Assing credit-invoices with a currency rate factor of 100 to an invoices with currency rate factor of 1, the system calculates

a wrong amount which still must be assigned to an normal invoices. This calculated assigning amount by the system isn't

correct.

SOLUTION DESCRIPTION:

Now, the linked amount is calculated correctly, also when the currency of the invoice or the credit note has a rate factor

unequal to 1.

3.1_b, B40_b

SESSION ERROR INDENTIFIED IN:

tfcmg1240m000

PROBLEM TEXT:

Supplier : 1001

Invoices: ACP 94000174 - 94000176 with amount - 100,-

ACP 94000177 - 94000180 with amount +100,-

All reference strings filled with fifteen characters.

Composing option "characters", limit "50" , action "more"

Result:

1st payment ACP 94000179

ACP 94000178

2nd payment ACP 94000177

ACP 94000176

ACP 94000175

3rd payment ACP 94000174

ACP 94000180

This should be :

1st payment 3 invoices (179 - 177)

2nd payment 3 invoices (176 - 174)

3rd payment 1 invoice (180)

SOLUTION DESCRIPTION:

In case of composing option characters, number was increased two times for the first invoice.

That resulted in wrong composing

tf3.1b, tfB40b.

SESSION ERROR IDENTIFIED IN:

tccom2501m000 "Display Suppliers".

PROBLEM TEXT:

When a part of the invoice amount is written to a cost ledger account (in session tfacp1133s000) the supplier's turnover is not

updated for that amount. This is not correct.

SOLUTION DESCRIPTION:

When an invoice is approved, the part of the invoice amount that is booked on a cost ledger account (in session

tfacp1133s000) is now added to the supplier's turnover.

Order amount: 100 (Supplier's turnover is updated with 100)

Invoice amount: 120

Matched with order: 110

Price difference: 10 (Supplier's turnover is updated with 10)

Written to cost account: 10 (Supplier's turnover is now updated with 10)

3.1_b, B40_a, B40_b

SESSION ERROR IDENTIFIED IN:

tfcmg2100s000

PROBLEM TEXT:

The problem is that a currency difference occurs.

This may not occur because only amounts for discounts, late payment surcharges and price differences

were changed.

SOLUTION DESCRIPTION:

Currency difference amount was created because discount,late payment surcharge and price difference

were handled as amounts in HC.

SESSION ERROR IDENTIFIED IN: tdsls4102s000 "maintain sales orderlines"

SITUATION DESCRIPTION:

On inserting a process item on a orderline with issue type is components (form 2) error 606 occurs,

(reference does not exist) in session "maintain sales order lines" (tdsls4102s000).

This error comes from process. After inserting a formula in "maintain formulas" (tpfrm0110m000) automatically

material is linked to this formula in session "maintain materials" (psfrm0111s000). This process item is non stockable and

therefore has no warehouse. Leaving the warehouse empty will lead finally to an error 606 in salesorders.

SOLUTION DESCRIPTION:

When issue on components is used for a containerized process item the formula is always exploded to 1 level deeper than set

in the sales order parameters. Therefore the level that contains the actual non stockable process item is always exploded.

The changes have been marked by : DF 11016-1.

3.1_b,B40_b

SESSION ERROR IDENTIFIED IN:

tfcmg1120m000, tfcmg4120m000

PROBLEM TEXT:

The parameters of the used payment method are:

- Document received : Yes

- Document accepted/sent : No

When using this kind of payment method, it is possible to select invoices for payment again after process payments has

executed.

After Status Balance = Anticipated Balance Select possible

Select invoices for payment selected No No

Process payments empty No Yes

Reconciliation empty Yes No

SOLUTION DESCRIPTION:

A message will be displayed if for this document already an anticipated document is generated

B40_b, B40_c

SESSION ERROR IDENTIFIED IN: tfgld1506s000 "Display error log file"

PROBLEM TEXT:

Within the background procedure, "end-of-session"-update, always the message " 'ledger account' missing or deleted" is

generated in the errorlog-file.

SOLUTION DESCRIPTION:

Now, the message " 'ledger account' missing or deleted" is only displayed when necessary. The message "dimension missing or

deleted" was also always generated in the logfile. This has been corrected to.

3.1_a2, 3.1_b7, B40_b4, B40L_b4_glo0, B40L_b4_gls0, B40L_b4_mcr0, B40_c1, B40_c_mcr1.

SESSION ERROR IDENTIFIED IN:

tfacp1132s000 "Maintain matched receipts"

PROBLEM TEXT:

When an invoice is matched via session tfacp1132s000 "Maintain Matched Receipts" the price difference is not calculated

right.

Also the calculating of the default amount is based on the currency-rate of the purchase order in contrast with the session

tfacp1131s000 "Match Receipts". In the last named session the currency-rate, found via the systemdate, is used and not the

currency rate of the purchase order.

SOLUTION DESCRIPTION:

Two problems are mentioned in the problem text.

Wrong calculation of price difference and using different currency rates in tfacp1131s000 and tfacp1132s000. Both problems

are solved. The price difference is calculated right now and tfacp1132s000 now uses the same currency rate as tfacp1131s000.

This is the currency rate belonging to the transaction date.

3.1_a, 3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

tfgld3203m000

PROBLEM TEXT:

Some of the records updated by this program, were updated more then once.

After analysis of the program, we discovered that the statement "WITH RETRY" was not present in the select. So whenever a

lock is detected, the system goes back to his retry point and starts to reexecute the COMPLETE select.

SOLUTION DESCRIPTION:

Added "With Retry" to avoid double countings

SESSION ERROR INDENTIFIED IN:

Background Process for Real Time - tfgld1201m000.

Background Process for End of Session - tfgld1203m000.

PROBLEM TEXT:

This session runs at the end of a session. It aborts with the message 'Transaction is on, can't continue'.

SOLUTION DESCRIPTION:

Script rewritten to avoid "Transaction is on" error.

B40_a, B40_b

SESSION ERROR IDENTIFIED IN:

tfacr3410m000

PROBLEM TEXT:

When you have more invoices to remind for one customer and each particular

invoice has a different reminder number, in session tfacr3410m000 and

tfacr3420m000 the wrong reminder number is printed.

SOLUTION DESCRIPTION:

The session "print reminder selection" now prints the correct letter number

3.1_b, B40_b

SESSION ERROR INDENTIFIED IN: tfcal2403m000 "Print activity and cost object results"

PROBLEM TEXT:

On report "Detailed results by activity/dimension" the field "amnt/quantity" was not always calculated correctly.

SOLUTION DESCRIPTION:

The fiels total.amount and total.quantity were not always inittialized. This caused wrong values on the report. The error has

been corrected. Also now it is possible to zoom on the formfields year and period.

3.1_a, 3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

tfgld6201m000

PROBLEM TEXT:

Financial statements is not selecting the right values or

History data incorrect or

Opening balances are not made correct.

SOLUTION DESCRIPTION:

The opening balance of a year is build in two steps. First the program selects all accounts with an

opening balance of the book year, adds the financial transactions of that year and posts the results.

The second time it counts only the values of the financial transactions which hadn't an opening balance

in the book year. But if the total balance (= opening balance + debet - credit ) equals zero the first step skips

posting. Due to this the second step presumed that ther was no opening balance for this account and counted

only the financial transactions (debit - credit). This was wrong and is solved now.

E.G.

OLD NEW

Account 1996 1997 1996 1997

00100 Opening Balance 100 -100 100 0

00100 Debet 50 50

00100 Credit -150 -150

tfB40_b4, tfB40_b4_mcr0, tfB40_c1.

SITUATION IDENTIFIED IN:

tfacp2535s000 (Display supplier invoices in a company).

SITUATION DESCRIPTION:

The Session takes a long time to be activated.

SOLUTION DESCRIPTION:

Performance improvements done.

SITUATION IDENTIFIED IN: Approve invoices (tfacp1140s000)

SITUATION DESCRIPTION:

The customer has a multi-site structure. Yet, after complete approval purchase invoice with a price difference, the accounts

for the purchaseresult booking are taken from the wrong company.

SOLUTION DESCRIPTION:

There was no company switch done before writing integration record.

3.1_a, 3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

tfgld1206m000 Close periods

PROBLEM TEXT:

An error message " Depreciation for year %d period %d not calculate" occurs when closing the reporting period of gld.

Fixed asset transactions are not based on reporting periods but on fiscal periods. This problem only occurs when there

are more reporting periods defined than fiscal periods

SOLUTION DESCRIPTION:

Fixed assets transactions will only be checked in closing fiscal period of the gld-module.

3.1_b, B40_b.

SITUATION IDENTIFIED IN:

Reconciliation of Receipts/Payments - tfcmg2103s000.

PROBLEM TEXT:

When in cmg2103s000 when setting the status of a completely reconciled document back to <open>, the status of the fields

<scrn> in cmg204 and srcn cmg111 remain as "processed". Also, the field <ramt> in cmg111 has a value.

This is most likely the reason why the system generates an error message (cmg2123), when trying to delete a de-reconciled

document.

SOLUTION DESCRIPTION:

Status now correctly updated within function itfcmg2000, for tables tfcmg204/tfcmg111.

tfB40_b

SITUATION IDENTIFIED IN:

tffbs0103m000 ( Maintain Budget Master data )

SITUATION DESCRIPTION

When new data is inserted in tffbs0103m000, the dimension descriptions disappear

SOLUTION DESCRIPTION:

The dimension descriptions are in tact now even when new data is inserted

SITUATION IDENTIFIED IN:

SITUATION DESCRIPTION:

When issueing standard items for a PCS production order (Production SFC-Inventory transfer), the integration is looking in

session tipcs8150 Maintain project transaction accounts, for accounts.

In this session it is not possible to post by warehouse.

This means that material for all PCS production orders must always be issued from one and only one warehouse pr. cost

component/project.

SOLUTION DESCRIPTION:

This solution solves defect DF 12144

tfB40a1,tfB40_b1, tfB40_b2, tfB40_b3

SESSION ERROR INDENTIFIED IN:

tfgld0113s000

OTHER SESSIONS:

tfgld0112m000

PROBLEM TEXT:

Performance is very poor when accessing the session 'Maintain Payment Schedules'

SOLUTION DESCRIPTION:

Performance improved

B40_b

SESSION ERROR INDENTIFIED IN:

tffas2200m000 Process Periodical Depriciation Calculation

PROBLEM TEXT:

Due to programming purposes, weird messages were given after pressing 'Continue'

message 'Dit is een Test'.

SOLUTION DESCRIPTION:

Weird messages are removed from the source.

This solution is marked with defect 12572.

3.1_a, 3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

"Print Payment Advice List(tfcmg1401m000)"

PROBLEM TEXT:

The field original company is not always printed on the report.

SOLUTION DESCRIPTION:

The field 'orignal company' was only printed when a new supplier was printed. However, a supplier can have invoices/standing

orders with different original companies. So now, the original company is printed every time it changes.

B40_b

SESSION ERROR INDENTIFIED IN:

tfgld1212s000 Finalization Process

PROBLEM TEXT:

Some db.retry.point's are introduced and one db.lock is converted to delayed.lock to avoid locking problems.

Object not aviable, with latest ID 10241205

SOLUTION DESCRIPTION:

Delevered object with id 10241205

3.1_a, 3.1_b, B40_b, B40_c,

SESSION ERROR IDENTIFIED IN:

tfgld6202m000 "Automatic Balancing of Profit and Loss accounts".

PROBLEM TEXT:

The transactions have only a debit sign. The batch is unbalanced.

SOLUTION DESCRIPTION:

Debit and credit booking are possible in automatic balancing of profit and loss accounts.

tf3.1_b, tfB40_a, tfB40_b, tfB40_b_glo0, tfB40_b_gls0, tfB40_b_sch0, tfB40_b_mcr0

SITUATION IDENTIFIED IN:

Maintain Transaction Types ( tfgld0111m000).

Maintain Last Used Document Nos by Transaction Type Series ( tfgld0114s000 ).

SITUATION DESCRIPTION:

It was possible to enter a lesser number of digits for the default series ( in tfgld0111m000 ) than was specified in the number

of digits for series. The same was possible in tfgld0114s000 when maintaining the actual series.

SOLUTION DESCRIPTION:

This solves the defect #12544. A check has been added to ensure that the user must enter the exact number of digits that are

mentioned in the field "Number of Digits for Series" when entering a Transaction type or when modifying an existing record.

A new message has been created to give information to the user about the lower limit of the range of acceptable data.

B40_b

SESSION ERROR INDENTIFIED IN:

tfcor0410

PROBLEM TEXT:

Correction Program must work sometimes based on the log date and not on the transaction date.

.

SOLUTION DESCRIPTION:

Session is now working on log date

tf3.1_b7, tfB40_a2, tfB40_b4, tfB40L_b4_glo0, tfB40L_b4_gld0, tfB40L_b4_mcr0.

SITUATION IDENTIFIED IN:

Approve invoices - tfacp1140s000.

Match invoices to receipts- tfacp1132s000.

SITUATION DESCRIPTION:

1. The status of the dummy invoices (=quantity <>0 and amount=0) was not set correctly.

2. It was not possible to close the projects with such dummy invoices.

3. It was not possible to update the purchase price of the customized items.

SOLUTION DESCRIPTION:

Now it is possible to match receipts with dummy invoices.

The question as to whether to change the purchase price of the customized items is asked now as well.

SESSION ERROR IDENTIFIED IN:

tfacp1433m000 "Print Registered Invoices"

PROBLEM TEXT:

The session tfacp1433m000 produces a report that includes registered purchase invoices with the statuses "Registered",

"Matched" and "Approved". "Approved" invoices should not be included, and were not in previous versions.

SOLUTION DESCRIPTION:

In previous versions invoices could be printed until a fiscal year/period. Functionality was added by adding a from fiscal

year/period parameter. Although the program was rewritten, the form was not changed. Besides that a change was made because

of a bug when creditnotes were assigned to invoices. After fixing this bug all invoices were printed, which was not correct.

Now on the form de field "fiscal year/period from" is added and the program is changed so that all transactions that influence

the amount of the interim account within the interval of periods are printed. These are:

1. All registered and NOT matched/approved invoices within the interval of periods.

2. All matched/approved invoices which are not registered within the interval of periods (with negative amounts).

3.1_a, 3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

""Post Integration Transactions to Finance(tfgld4201m000)"

PROBLEM TEXT:

Some integration transactions cannot be posted to finance. The system gives the message <<Cannot define ledger account

(tdinv850)>>, but there is a ledger account defined in session tdinv8150m000.

SOLUTION DESCRIPTION:

There was an technical error in the program which posted the integration actions to finance. As a result of this, some

integration transactions could not be posted to finance and a message was generated in the logfile : <<Cannot define ledger

account (tdinv850)>>, although this was not the case. The error has been corrected.

tf3.1_b, tf3.1_b1, tf3.1_b2, tfB40_b, tfB40_b1

SITUATION IDENTIFIED IN:

Maintain Bank Transactions ( tfcmg2120s000 )

SITUATION DESCRIPTION:

In Bank transactions when the category of the transaction is a Journal and a ledger account which had an integration with

Project Sales was given as the input the system would not accept the ledger account. If a Ledger account with integration to

Project costs was used the system would accept it.

SOLUTION DESCRIPTION:

This solves Defect 11322.An unnecessary check was being done on the Ledger Account which has now been removed.

3.1_b, B40_a, B40_b

SESSION ERROR INDENTIFIED IN:

tfgld1101m000 Maintain Transactions

PROBLEM TEXT:

When inserting an new batch with different user at the same time. The system generates a message 'Record already exists'.

SOLUTION DESCRIPTION:

There is build in a check ont the batchnumber just before the tables tfgld100 'Batch Status and tfgld101 'Transaction Type

Batch Status' are update. These tables caused the duplicate records.

tf3.1_b7, tf3.1L_b7_glo0, tf3.1L_b7_jit0, tf3.1L_b7_nl10, tfB40_b4 , tfB40L_b4_gls0, tfB40L_b4_glo0,

tfB40_b4_mcr0,tfB40_c1.

SITUATION IDENTIFIED IN:

tfgld1420m000 (Print Tax analysis).

tfgld1401m000 (Print non-finalized transactions).

SITUATION DESCRIPTION:

The VAT lines are shown twice on the above mentioned reports.

SOLUTION DESCRIPTION:

Error rectified. Under some circumstances records were added twice, so they were printed twice.

B40_b

SESSION ERROR INDENTIFIED IN:

tfacr3440m000

PROBLEM TEXT:

Needed formdumps and report source for tfacr3440m000

SOLUTION DESCRIPTION:

Needed objects delivered

3.1_b, B40_a, B40_b

SESSION ERROR IDENTIFIED IN:

tfacr4220m000 Post Sales Invoices

PROBLEM TEXT:

When entering a manual Sales Invoice via sessions tfacr4100m000 and tfacr4101s000 and using quantities. These quantities

cannot be seen in session tfgld3508s000 'Display Transactions not Finalized and tfgld3509s000 'Display Transactions

Finalized'.

SOLUTION DESCRIPTION:

The session tfacr4220m000 Post Sales Invoices is not writing the quantities in the table of Non Finalized Transactions

(tfgld102).

3.1_b, B40_b

SESSION ERROR IDENTIFIED IN:

tfacr3440m000 "Print statements of Account"

PROBLEM TEXT:

Session tfacr3440m000, Print Statements of Account, does not reflect sales corrections at all; however, session

tfacr2420m000, Print Aging Analysis by Customer, does print the sales corrections accurately.

SOLUTION DESCRIPTION:

The sales corrections will be taken into account now.

tfB40_b4, tfB40L_b4_mcr0

SITUATION IDENTIFIED IN:

tfacr2415m000 ( Print control account checklist )

SITUATION DESCRIPTION:

Customer name not being printed for identical customers

SOLUTION DESCRIPTION:

The report displays customer name now, for identical customers

SITUATION IDENTIFIED IN:

Maintain Receipts (tdpur4120m000, tdilc4113s000)

Approve Purchase Invoices (tfacp1140m000)

SITUATION DESCRIPTION:

The financial transaction date in table tfgld410 stays empty at the moment a transaction of type "Purchase Result" is

inserted. The consequence is, that the system can't determine the right financial period that should be used.This problem

occurs both at maintain receipts and during approving of purchase invoices.

SOLUTION DESCRIPTION:

Due to modifications in the session "Maintain Receipts" (tdpur4120m000) the DLL used to insert the financial transactions of

type "Purchase Result" (tdpurdll0020) isn't compatible anymore. To solve the problem the latest object of this DLL should be

installed. This object is available. Also a few new objects which make use of the dll should be re-installed.

You can download the solution 11900 to correct the already existing records in tfgld410. The field Transaction Date will be

update with the log date.

3.1_b, B40_b, B40L_b_mcr0

SITUATION IDENTIFIED IN:

Assign Unallocated/Advance Receipts to Invoices - tfcmg2105s000.

SITUATION DESCRIPTION:

When the invoice currency and the bank transaction currency are the same, the program is still trying to convert the

unallocated amount into the invoice currency through the home currency. When the currency rate is changed, the new amount

in the bank currency may be different from the amount in the invoice currency. Thus, the batch remains unbalanced and the

status is not changed to "ready".

SOLUTION DESCRIPTION:

If the bank currency is the same as the invoice currency, then the related invoice amount is calculated directly from the

unallocated amount without having to translate it into the home currency.

SITUATION IDENTIFIED IN: Maintain chart of accounts (tfgld0108m000)

SITUATION DESCRIPTION:

When inserting new records in the financial company (not used as logistic) the field logistical company is filled default with

the financial company.

SOLUTION DESCRIPTION:

The field is now filled with the logistic company

SITUATION IDENTIFIED IN: Maintain Subcontracting Invoice Data ( tfacp3160m000 )

SITUATION DESCRIPTION:

In tfacp3160m000 when the "No. of Hours" is changed, the amounts in fields "Amount to Tax" and "Amount to I.A.B." do

not change correspondingly.

SOLUTION DESCRIPTION:

The values have been properly assigned to the fields "Amount to Tax" and "Amount to I.A.B."

tfB40L_b_mcr0, tfB40_c1

SESSION ERROR INDENTIFIED IN: Maintain Bank Transactions (tfcmg2100s000)

PROBLEM TEXT:

When entering bank transactions, it is possible to leave the field <transaction type> empty. Program does not give an error

message.

SOLUTION DESCRIPTION:

Source has been fixed and now the message "Transaction type not filled" gets displayed when the field is left blank.

3.1_b,B40_b

SESSION ERROR IDENTIFIED IN:

tfgld1410m000 "Print Journal Report"

PROBLEM TEXT:

Duplicate printing of finalized transactions because there are no tables in one or more companies defined in table tfgld001

("Financial Companies by group company")

SOLUTION DESCRIPTION:

If the check on whether the company exists or not comes with an error code, the company will be skipped.

SITUATION IDENTIFIED IN : Receive Purchase Invoices (EDI) (tfacp1250s000)

SITUATION DESCRIPTION:

In a multisite companystructure with multiple finance companies, you are alllowed to enter a purchase invoice in finance

company 001 , and match it with purchase receipts that were integrated to finance company 002. If you use this option in EDI

purchase invoice matching, then the purchase receipts are found and matched, but the transactions that are created for invoice

approval are not balanced. The debit transaction on ledger account "registered invoices" is made, but the credit transaction on

"invoices to be received" is not made.

SOLUTION DESCRIPTION:

While matching the purchase invoice with the purchase receipts, the field "Finance Company" in table "Purchase Invoices

linked to Purchase Orders (tdpur046)" was filled with the Finance Company of the Purchase Receipt. When the multisite

structure is Single Logistic - Multi Finance or Multi Logistic - Multi Finance this field must be filled with the Current

Company wherein the Purchase Invoice is maintained.

This solution solves DF 14201.