Payment tolerance (Creditors) disfunction

Using Payment tolerance in for Payment suggested creditors: Obviously ready for use fields somewhere in creditor/payment setup, make (e.g. german) users believe that they have possibility to arrange payments on a not daily base and get Skonto. FALSE: Functionality was planned and fields where incorporated but Functionality was not programmed out. Even our NSC brought it to us as a good new functionality. And we setup the parameters together, because it is really a need for us. [:0] We lost a lot of money - thanks Navision [:(].


Please Navision, no further invest in marketing - invest in true solid useroriented programming I have a dream: Navision system does, what Navision tell me, that it is able to do. Our often question: Are we the first one coming through these problems ? And there are much more… We are one of the first PPS-users in Germany, first version 2.01 now 3.70. Slim systems are one thing, disfunctional are another ! ...S T I L L..F I G H T I N G...!

Sorry, I really don’t get it. What do you mean with “Functionality was not programmed out”? What specific problem have you found that leads to this conclusion? Can you give us an example?

Sorry…Never heard of this problem[?]. As Nelson says, please could you give us an example of the problem & where the functionality is (allegedly) not complete? Thanks

Hi both of you and thank you, sorry for my late reply, I was out of office… Payment tolerance, seem not common in the worldwide versions and a more or less local german adaption. Our nsc told us, it is wished functionality of many german users - incorporated by the danish programmers, but not usable in the end. What bothers me is that acc. the programmers it “should be” of manual help, but we cannot see any help of it. If you have paymentaim “10 days 2%, 30 days net”, you are allowed to shorten the payment about 2% within the first 10 days. These function works exactly on the 10th day. But think of situation, that on the 10th day your business is closed like on saturday, sunday or holiday. Before the 10th day, you get no paymentsuggestion, after it the same. For that reason a lot of people where keen on that new functionality of payment tolerance. Not even days like sundays should be tolerated even the usual method of weekly payment instead of daily payment would be possible. That is what isn’t working. If you do not catch the exact day (10th), you do not earn the Skonto (2%)… On the other hand, think of your customers payments, they deduct skonto eg slightly after the skonto-timerange, instead of accepting within your agreed payment tolerance time, you have to adapt manually the skontopayment date to get the payment done right. Even if it comes one day after - would you blame your customer for it ? No! but it would reduce costs to have the problem solved easily and automatically. I hope this makes it a bit more clear know - Pascal

So, are you talking about “Payment Discount” or “Payment Tolerance”? They’re 2 different things. It seems you are interested in “Payment Discount”. Anyway I have to tell you one thing. From your description of the problems you have with Navision, it is very clear where the source of the problems resides: your NSC sucks. I’m sorry if that hurts someone’s feelings but it sure looks like that’s what’s happening.

Hi Nelson, it is the payment tolerance, which means that the Payment discount can be deducted in spite of having missed the last Payment-day of Skonto-period. “NSC sucks”: In case of bringing us a feature without knowledge that it wont work, you are right. But we have seen emailconversation which blames the danish developers for unproper solution from german MS-support side. I think many NSC failed on that issue… And here I am back at my signature…

I have to follow up: Another guy - same nsc: if you use in options a future date for the payment, eg you have the friday 14th and want to realize skonto for payment on saturday and sunday put the 16th. And it should work. The logic is different from our and peoples view in our nsc and ms germany but ok … We cannot test it out, after opening one of the lines and set skonto to later date for trial caused an error. After starting paymentsuggestion again it fails, with comment, that we do not have the permission… :frowning:

Hi Pascal, I certainly don’t want you to keep thinking that Navision is just a child of Microsoft’s marketing machine. These are the simple steps I’ve performed on a standard 3.70 CRONUS database: 1) Using Vendor 35225588 Husplast HF (since it is the only one with Payment Terms 1M(8D)), I posted a Purchase Invoice for 10 Bycicles at 100 each for a total amount of 1000. The fields I watched out for were: - Posting Date: 2001-01-01 - Payment Terms Code: 1M(8D) - Due Date: 2001-02-01 - Payment Discount %: 2 - Pmt. Discount Date: 2001-01-09 - Document Date: 2001-01-01 2) If I now go to Payment Journals, I can test the various options for posting a Payment against this Invoice. I’ll try to display it as a table using the Courier New font:

Posting Date | Document Date | Amount
2001-01-25   | 2001-01-25    | 1.000,00
2001-01-07   | 2001-01-07    |   980,00
2001-01-25   | 2001-01-07    | 1.000,00
2001-01-07   | 2001-01-25    |   980,00
2001-01-09   | 2001-01-09    |   980,00

What does this mean? The Invoice was posted on January 1st, which according to the Payment Terms, means it should be payed up until February 1st. However, if the Invoice is payed during the first 8 days (until January 9th), there’s a 2% discount on offer (Skonto, in German). When posting a Payment for this Invoice, Navision will look at the Payment Posting Date to decide whether or not the Payment Discount (Skonto) should be calculated. You can easily see this happening on the table above. Whenever the Posting Date is January 9th or before, the Payment Discount is calculated. I think this clearly states the functionality does exist and is fully implemented. Are you sure you have run this through with your NSC in a proper way? I find it very hard to believe that a good NSC would blame Navision HQ for not developing something which is actually developed. It just sounds like a very poor story, sorry.

I think that here what we have is a misunderstanding on how this functionality is working. If you use a posting date after the payment discount due date you won’t get any discount. If you can’t suggest the payments to the vendor on the program on the date (because is a non-working day), you have two options: 1) Not taking the discount (as the date where you’re able to take that discount has already passed). 2) Using as posting date for the payment that friday’s date instead of the actual business date. The payment will be applied as done on that date and, so, allow you to take the discount allowed. Sorry, but the functionality is FULLY working. An improper use of the feature will cause an unproper result.

I just wish we could get a new reply.

Pascal, I have a customer, who has the same problem you have. For him I solved the problem in the austrian version of the add-on “Zahlungsverkehr”. But it should be possible to modify R393 too, to handle payment discount tolerance. Best regards from Austria Karl