Question for Sage Import experts

[Tom McClelland]

Our software produces a nominal journal file that can be imported into Sage Instant or Sage Line 50 using the audit trail import option.

We've just had a message from a user with Sage Line 50 2010 who says that our file doesn't work any more. Basically we've been leaving the tax code and tax amount columns completely blank and the new release doesn't seem to like that. The user filled T9 and 0.00 in to the file manually between the commas that we'd supplied for zero-length entries and straight away the import worked worked.

Can anyone confirm if Sage have "enhanced" the import and if there is a way of requesting the old behaviour? I guess that 12Pay wouldn't be the only software producing import files that might now be broken by this change.

[johndon68]

Sage have changed the import routine in v2010 to be a lot more flexible than it was previously - instead of a completely fixed format for the import, it is now done by 'mapping' columns in an XLS or CSV file to the fields in Sage.

They do still support the old format from previous versions but, as this is now done via a default mapping that Sage supply, although I haven't tried it, I suspect that it is now mandatory to have values in the two columns you mention.

HTH

John

[alexandrajames(uk)ltd]

What john don is saying, when importing into 2010 sage will prompt you to allocate columns in the file (A, B, C, D....) to the corresponding field on 2010 (Nominal Code, etc...) easy peasy....

[Tom McClelland]

easy peasy....

Easy peasy for you or I perhaps, or for anyone else who knows what they're doing.

For people who previously just clicked a button to do the import, and who have no idea what the layout of the import file is (that probably describes 99% of the users of this kind of soluion, indeed they don't even understand the question) a huge leap backwards, turning something that used to be easy peasy into something that now requires arcane knowledge. And that kind of "pick our data elements that match your file columns" interface is such a '90s solution to identifying csv file layouts. There are far, far better ways of handling that problem.

And as I explained up above, files that worked using the old mechanism fail using the new one because the data requirements have changed as well as the import mechanism being made clunkier. Previously the tax code and amount columns could be blank, and this caused no problems at all. Now it is compulsory to nominate those columns, and they must contain valid data. Blank isn't enough any more. A cardinal rule of software enhancements is that you don't break things that used to work.