I’m trying to print an aged A/R report to file, as I need to import it into a program which only accepts ‘fixed length ASCII text files’. I’ve tried sending the report to a Generic\Text printer but this doesn’t seem to work as if any of the amounts are bigger than 1000, then they appear on the .prn file as *****. Also checking the print to file option in the print options doesn’t send the correct info to the print files. Any Ideas? Many thanks.
You have to re-design the report - change the width of the amount-field(s).
I think it’ll be easier if you have your NSC modify the report to be exported to a text file. Printing to text file doesnt give satisfactory and consistent results as to my experience, not mentioning the fact that the resulting file will have all header info and some additional stuff in it, which wont be easy to handle in the other program, when importing.
The best option is using a Dataport to export the data. But for this you will need a development license. Or you can ask your NSC/MBS Partner to do it for you if you don’t have one.
Maybe, but in the case given, what you need is to export the results from running a report. If you have to design a dataport, you should repeat all the processing and calculations done into the Aging report “…and this aint easy” :).
Thanks everyone for your suggestions. I have some ideas to try out now.
Hi Nikola, Can you explain better how a Report can be “modified” to produce a fixed length text file? I’m listening… and learning 
Hi Have a look at Report 10550 “BACS Export” This should help you.
Hi Stephen, The Report you mention must be from the UK version, correct?
Hi Nelson Yes its a GB Localised report.
Nelson, use a File variable, set it to textmode and write to it.
Hi Randy, But do you think that’s easier/faster than to copy the processing into a Dataport? Sorry to keep pushing my point of view but, after all, what are Dataports for if not this? Maybe I’m wrong [:I]
It is definitely easier, because with the dataport you have to MODIFY and TEST what you’ve copied. It won’t be a simple copy/paste. Plus you’ll use additional object from the very precious custom range …aaaand Dataports are much slower … /As you can see I definitely prefer the FILE/Report approach :)/ BUT whatever floats your boat. If you think that the dataport will suit you better then go with it.
Hi Nikola, First, I’d like to say I find this discussion very interesting [:)] It is true that it is not only a matter of copy/paste, mostly because Dataports cannot have indented DataItems, which makes the logic of Reports completely useless. You have to adapt the processing by converting any idented DataItems into Record variables. In my opinion, this is not “very” hard. It’s only a matter of paying close attention, as with anything else, mind you! Then the speed. I have to say that after testing Reports against Dataports a few times, I don’t agree. Try to use both a Report and a Dataport to run through all Records in a very big table and modify one field. A Dataport always finishes in less time than a Report. And I find it logical, since a Report has much more functionality (TotalFields, GroupTotalFields) which slows it down. Well, my conclusion is: If someone asked me to do something similar, I would use a Dataport. [:p] Regards
As I said earlier whatever floats your boat. I won’t bother to repeat the whole report logic in a dataport, mostly because you should “pay close attention”, which means develop and then test test test,develop and test test test And the question is why having to do this, instead of using ready and tested report with just minor modifications to export data to a file /whether fixed length or not, and the first one is not that hard to program as well/ As far for the speed it is all matter of design. I had a lot of headaches with the dataports since v2.0 of Financials and I must say that this feature, although improved in the future versions, is one of maybe most inconsistent in terms of performance from version to version, mainly on importing data. Exports are fine, though. But I stated my arguments on this particular case above. p.s. Simple codeunit will outperform both Report and Dataport… Nevertheless, what we are discussing here are general recommendations, based on some specific experience. Every specific/custom case,although dependant on the general application programming logic and rules in Navision, has its own specific solution, based on complexity,experience of the designers/developers AND cost!
OK, Nikola, thanks for also sharing your thoughts. It’s always good to compare different opinions and experiences.