home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / sasl / 5564 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.6 KB  |  62 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!auvm!COMPUSERVE.COM!71020.1025
  3. Message-ID: <930109013722_71020.1025_EHC54-1@CompuServe.COM>
  4. Newsgroups: bit.listserv.sas-l
  5. Date:         Fri, 8 Jan 1993 20:37:23 EST
  6. Reply-To:     William Kahn <71020.1025@COMPUSERVE.COM>
  7. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  8. From:         William Kahn <71020.1025@COMPUSERVE.COM>
  9. Subject:      SAS for accounting
  10. Comments: To: sas-l@ohstvma.bitnet
  11. Lines: 49
  12.  
  13. Mark Schildhauer writes:
  14.  
  15. . . . <stuff deleted>. . .
  16.  
  17. >   Is anyone out there successfully using SAS, particularly
  18. >on Unix servers networked via TCP/IP, to provide a complete
  19. >administrative solution for an organization with thousands of
  20. >employees and clients?
  21.  
  22. . . . <stuff deleted>. . .
  23.  
  24. We asked a similar question a year ago--when we were just starting the
  25. design for moving our corporate accounting off of our mainframe.  Three of
  26. us visited SI for a day and were given a very nice dog&pony show--clearly SI
  27. wanted our business.  As we all know the SI adhoc analytic tools are superb.
  28. The main weakness, and what killed it for us, was that SI is not a database
  29. system.  Really important stuff like multi-phase commit and rollback is not
  30. part of the system--you have to write all that stuff yourself which is
  31. actually quite difficult (ideas aren't to bad but to actually make it work
  32. in a complicated environment is tough).  My current belief is that you will
  33. need a real database, not SAS.  If you discover otherwise I would love to
  34. talk further.
  35.  
  36. If you use SAS to interface to a Sybase type back-end, will it do so
  37. efficently?  If you end up just writing all your own Sybase code and sending
  38. it to the back-end using SAS, what's the value of SAS?
  39.  
  40. Another weakness was the lack of standard prewritten accounting reports.
  41. Accounting reports (payables, receivables, fixed assets, inventory,
  42. taxes, payroll, benefits . . .) are actually complicated because of the
  43. level of detail.  You are talking a bunch of money to write these modules
  44. yourself.  Further, these functions are very standard--the IRS and CPAs
  45. don't permit much innovation.  Buying these functions from a company who can
  46. amortize the programming is much cheaper.  There were alot of companies
  47. with accounting tools for standard database backends.
  48.  
  49. We plan to use SAS as a adhoc query tool for the data, but not the
  50. day-to-day work.  The fact that SI uses SAS as their accounting tool (true?)
  51. doesn't mean it is the tool of choice.
  52.  
  53. Good luck Mark--downsizing is a big project.
  54.  
  55. Bill Kahn <71020.1025@compuserve.com>
  56. W. L. Gore and Associates
  57.  
  58.  
  59.  
  60. Distribution:
  61.   >INTERNET:sas-l@ohstvma.bitnet
  62.