Does anyone know what the Customer.“Balance Due” field is supposed to be in version 4.0? It appears to be summing all the detailed cust. ledger entries where the inital due date is within the date filter applied. So far so good, as that would give you the debt currently outstanding which was due in the period specified by the date filter. However there is an additional filter applied to the posting date field which ensures only entries posted up to the end of the date filter are included. This now means it gives you the amount of debt due in a period which was outstanding at the end of that period, rather than outstanding now. Although that could be a useful number to someone it is not what the field gave in earlier versions of Navision (specifically version 2.01) and it is not what the help files suggest. This field is used on the Customer / Sales option from the customer card and means that in most cases the numbers shown bear no relation to what is currently outstanding (which is what I think it is supposed to be showing). Am I losing the plot or is something wrong here? I’m off to use code instead.
Hi Paul, as far as I can see it is the same as it was in 3.70. i.e. the sum of the DETAIL cust. Ledg. Endtries table. NOT the CLE table. Since this is in the developer forum, I assume you mean from the developers point of view. if you had asked as an enduser, then I could understand this, since ont he Customer Card form, a differnt set of code is used for the drill down, and this could cause confussion. in terms of 2.01, yes it is totally different. Note that since balance data is not available in the 4.00 Cust Ledg entry, you may not be able to get he same numebrs in 4.00. Better is to train your users to use the new field, it does work a lot better, and gives more usefull information.
Thanks David, I am looking at it from both a development and end-user point of view. I think an example will highlight my concern: Say you have a client with the following postings: Invoice Posting Date Due Date Amount 100 01/08/05 01/08/05 1000 101 01/09/05 01/09/05 2000 The balance due field will correct show the following Date Filter Balance Due 01/08/05…31/08/05 1000 01/09/05…30/09/05 2000 Now if I post cash on 05/10/05 for 3000 and fully allocate it against the two invoices then the balance on the customer is zero. However the balance due fields remain unchanged because the date filters applied are excluding my cash allocation, which was posted in October. In version 2 the balance due fields would change to zero. You rightly say that the drill-down on the customer/sales form has been changed to ignore the definition of the balance due field. This means that when you drill-down on the balance due of 1000 (August) you get a blank screen. Surely the transactions shown in the drill-down should be consistant with the value of the field? In any event I have removed use of the balance due field and have used coding and the detailed cust. ledger entry table. The customer/sales form and the balance due field is a small part of the overall application and in the great scheme of things it is unimportant however when upgrading from version 2 to version 4 it makes a big difference because the functionality of the field has changed dramatically, namely: Version 2: Balance Due = total debt due in the date filter period which is still outstanding as of today. Version 4: Balance Due = total debt due in the date filter period which was outstanding at the end of the date filter period, regardless of whether it is still outstanding today. I should probably get out more.
Logically the value int he 4.00 field is correct, and the 2.01 is wrong. If you are filtering prior to October, then October payments should not be inculded, thus the value you are seeing now is correct, but your client is used to seeing the wrong number for so long they are used to it. As to the drtill down, it a complete nightmare. The first time I installed this for a client, I deleted the code off the form, so that at least the Number would match the drill down. But it wasn;t my client, and I could not convince them or their NSC, that tit was better, so in the end just put the code back. If I had designed it, then I would have left the drill down as is, and added Assist Edit as the drill down to the customer ledger entry. In the end though, the 4.00 balance field is much more usefull than 2.01, you must need to get used to it. (BTW I keep saying that about the menu “pain”, and haven’t convinced even myself of that one yet.).
David, Thanks for the reply, I don’t want to take up too much more of your time on this issue. However, I want to get things clear in my head. As far as I can see, the field in version 4.0 is wrong but the drill-down is correct. Clearly one is wrong and the other is correct. I think that the field should be showing the amount currently outstanding (as of now) which was due in the period specified by the date filter - (this is what the drill down shows) - and this is a very useful value as it effectively shows my current debt aged by the period in which it was due. This The field is, however, showing how much debt due in the period was still outstanding at the end of that period. This figure was useful at the end of that period but is now fairly useless. In the client I gave as an example earlier, which now has a balance of zero, I am getting the following screen: Period StartPeriod Balance Due (LCY) Sales (LCY) 01/07/05 July 0.00 0.00 01/08/05 August 1,175.00 1,000.00 01/09/05 September 2,350.00 2,000.00 01/10/05 October 0.00 0.00 The account is currently clear so the invoices due in August are no longer due, which is what the drill down shows. The values 1,175 and 2,350 are of no use, why would I want to see how much of the August invoices were outstanding at the end of August, and how much of the September invoices were outstanding at the end of September. I don’t see what credit control process would use these numbers as I am interested in what is outstanding now. I think I should be seeing: Period StartPeriod Balance Due (LCY) Sales (LCY) 01/07/05 July 0.00 0.00 01/08/05 August 0.00 1,000.00 01/09/05 September 0.00 2,000.00 01/10/05 October 0.00 0.00 as this shows me that the invoices due in August & September are no longer due as they have been paid. This is what I get in v2 (when life was much simpler if a little duller). What I suspect has happened is that they have amended this field because it means the “Customer - Summary Aging Simp.” report can reproduce the debt as it was at a point in time (like the “Aged Accounts Receivable”) report, however the change they have made (adding the “posting date” filter) has invalidated the field’s use in other places. Unfortunately I don’t have the documentation from the version when this change was made. Perhaps someone has a copy and can reveal the thinking behind this. I consider the menu to be a little like a stone in your shoe. You can ignore it and still carry on, but it will be a blessed relief when it’s gone. Paul.
Steffen could you please reply to this. (You don’t need to say anythng, I just need your signature [:D] ) As a Freelancer, I have helped a lot of NSCs do Upgrades, and by far the number one issue I find, is that the end user is told about all the great new features that will help them and their business, but unfortunately they are not told about all the great new things that they don’t need, and quite honestly just don’t want. Paul as a Freelancer, I am sure you know this feeling. I wrote an addon that used a seperate table to store dollar amounts of Item ledger entries in Navision, that was BC (Before Cronus), and then also did the same for Customer ledger to make it possible to do Partial payments. So to me it seems the correct way to do this, but if a user has finally gotten used to single level entries, then they may not want to move to the detailed entries system. On the other hand clients that need it, “need it”, and there is no way around it. I think that the way Navision did this is the correct way, and it satisfies the needs of more users than the old way, definitely I have never heard of an AD (After Detail) user that would want the old system. Paul, in terms of your current issue, it is not a lot of coding to carry the dates through the ledgers, and create flow field to gve you your numbers, BUT I would really recommend wokring with the client first to see if you can get them to retrain to the new way. It will be the best in the long run. If not, then its not too hard to bring the Invoice Posting date onto the detail entries, add a key, and do the math.
Thanks David.