Archive for January 2011
A key tenant of many self-improvement strategies is that it is far more worthwhile to work on strengthening your strengths rather than working on your weaknesses (for instance: this one). You are much more likely to succeed working on your strengths, where you are talented and interested. You have a very good chance of progressing from good to great and being great has the most value. If you work on your weaknesses, you probably won’t be happy or motivated and improving a little bit will not be externally visible. Generally unless a weakness is a real show stopper, you are far better off working developing your strengths.
The same is true for Software Development. Customers realize far more ROI when you strengthen the strong parts of the program. That is why they bought the program and love it. If they cared about weaker features they wouldn’t have purchased it in the first place.
Many times software products suffer from trying to be all things to all people. Perhaps analyzing a competitor’s product and then working on filling in any gaps between the two. But then this is done at the expense of working on the product’s main features and strengths. And does broadening the product like this really benefit customers?
Within Sage we have many competing ERP and CRM products. Often we get criticized if we develop one product in a certain way, but not another. But do we receive any benefit from moving all the products together towards one shared end point? All our products have separate heritages and separate strengths and weaknesses, are we better off strengthening the strengths rather than filling in the weaknesses? For instance if a product has a strong Manufacturing module, but a weak Services module are we better off strengthening the already strong Manufacturing module or propping up the weak Services module?
After all with-in Sage we aren’t really competing one of ERPs against another, but against external non-Sage competitors like Microsoft, Epicor, SAP, NetSuite, Salesforce, etc. So aren’t we better off strengthening the Manufacturing in one product to compete more effectively for those sales and then strengthening the Services module in a sister product that already has a strong Services module to compete for those sales. Again it’s a matter of remaining externally focused rather than having all the Sage products chasing after the same deals.
Similarly our Business Partners have choice. For instance if you are a Business Partner operating in the USA specializing in Manufacturing and selling MAS-500, perhaps rather than branching out to more industries and carrying additional ERP packages, it is better to concentrate on manufacturing and stick with MAS-500. But if you do want to branch out, for instance say your customers are doing more manufacturing overseas then perhaps you would consider picking up Sage ERP X3 which is also strong on Manufacturing and supports multi-country installations. But when looking to grow, sometimes specialization can take you from good to great in one thing, as opposed to branching out and risking being average in a number of things. This is a very difficult decision for businesses and often a very crucial decision to make as you consider how to grow your business.
There aren’t any hard and fast rules about which is the best fit. It isn’t based strictly on company size or vertical industry. For instance a small company may have very sophisticated inventory requirements that are far beyond what Accpac can handle, and for that company X3 is the better fit. Similarly a very large company can have very simple operational requirements that don’t require the advanced features in X3, and there perhaps the simplicity of Accpac is the best fit. Plus all the mid-market products have advanced customization capabilities and large ISV communities allowing each one to compete in a very large variety of deals.
Basically our approach is to manage our products as a portfolio. As we look to fill gaps in our market coverage, we are looking to extend our portfolio to cover any missing elements, rather than all the individual products. So rather than each product trying to fill every gap, we will choose the product that is the best solution and then develop that product to serve the need. This gives us far greater market coverage since each product can be extended in a different direction and then benefit Sage, its partners and customer by providing the broadest solution possible by leveraging the entire portfolio. Again building on our strengths, including the strength of our product diversity.
Sage is unique among the ERP vendors in that we have a large range of products that spans from the owner-operator all the way up to the small enterprises (upper mid-market). This allows us to leverage our portfolio strategy and create a migration strategy where customers can move from one Sage product to another as their business grows. Generally we segment this into four markets as the diagram shows:
An owner-operator that choses Sage Spark or SageOne, when ready to move to the next level will be more likely to choose another Sage product that meets his needs such as Simply Accounting, Peachtree, Sage 50 or Pastel, than go to a competitor. Especially if they have received a great customer experience from Sage and we provide a simple way for them to migrate their data. In the same way when they grow further they will hopefully choose on of MAS-90, MAS-500 or Accpac next and then as they grow bigger still they will consider moving to Sage ERP X3. This also assumes that we have a selection that works well for their business, and by having a choice of complementary products, the possibility is much greater.
For mid-market ERP this is crucial, since the days of non-consumption are over. Everyone is already running some sort of ERP package. In fact, by far the most new sales of mid-market ERP that we get are people out-growing and moving up from a Small Business ERP whether one from Sage or one from one of our competitors. The second highest category is people moving off a home grown custom programmed system that has become too expensive to maintain. These studies show that doing migration well is a key enabler of new sales.
It would be nice if all our Business Partners carried and were expert in all our products. Then for each deal they could step forward with the best product to compete with the various external companies for a deal. It would be nice if all our Business Partners could shepherd our clients from one Sage package to another as the client’s business grew and their needs changed. We know we are a long way from this goal and that it can never be fully achieved, but we are working to develop our products within this framework and to put new programs into place to make this an easier process.
Connected services are a rather generic term that is used in many contexts. Often a connected service is a Web Site that offers a Web Services based API to access. Many times connected services are promoted as add-on services to some core application or service.
In our case we are going to consider the core application service as ERP (such as Sage ERP Accpac, Sage ERP MAS 90/200, Sage ERP MAS 500, etc.). Then we are going to consider various types of add-on services that received over the Internet, making them connected.
Disclaimer – This blog post isn’t meant to describe any specific products or services that are in the works, but to just talk about connected services in general. Anything mentioned is just an example not an indication of a future partnership or product offering. Of course some services like ERP integrations to Sage Payment Services are either already deployed (such as in MAS 90/200/500) or coming soon (April for Accpac).
iTunes is the first wildly successful connected service that got everyone excited. When the iPod first launched there were lots of other MP3 players, most cheaper than the iPod. What set the iPod apart was the iTunes store where you could very easily buy music over the Internet at quite reasonable prices. The end result was that Apple pretty much replaced the music player market with the iPod (including CD players) and further replaced the music distribution industry with the iTunes store. It could be argued that the real genius of t the iPod was taking a music player and connecting it to the Internet to buy music. Others might argue that as people acquired more music, managing it became unwieldy, some companies invented 100-disc CD changers, others MP3 players. After all you can play your regular CDs on an iPod. But even if the iPod had become popular just playing CDs copied from your PC, it became wildly popular due to the iTunes store, which is its connected service.
The iPod then developed, becoming the iPhone and then getting a bigger brother in the iPad. Meanwhile the iTunes store developed, offering music for sale, small applications that run on these devices, movies, TV shows, books and so forth. Now most people think more of the part of iTunes that sells applications (the App Store) than the part that sells music.
Branching away from the iPod family there is now an App Store for the Mac computer as a distribution method for Mac applications. Many other people have since copied the Apple App Store to some degree allowing various things to be sold from these Web Stores.
A key feature is that the object bought is immediately transferred to the device where it is run or played and is immediately available. There are many fake App stores where you select the item and then when you hit buy it indicates a sales person will now call you or a DVD will be shipped to you. These services miss the point.
The point is that when you buy, you get the product available to use almost immediately. You aren’t aware of any installation process, you just know it needs a bit of time to download and then away it goes. This really means that the cost of the goods really is the cost of the goods; no more money needs to be spent installing, configuring or otherwise messing around before using it. Of course this isn’t suitable to everything, but as technology improves it is suitable for more and more things. It’s easy to come up with examples that won’t work in this model, but this shouldn’t be an excuse not to do the 90% of cases that will work.
Keeping the size of the applications small, concentrating on volume and eliminating physical production costs has really lowered the cost of applications. But it has also really un-bundled applications. The previous trend was to buy one mega-application like Microsoft Office that supposedly comes with everything you need, but now the trend has reversed and now you buy a collections of smaller applications that combined do everything you need. This prevents buying things you don’t need, such as buying a very expensive package and then only using 10% of the functionality.
Transaction Based Services
Everyone’s dream is to skim some sort of small percentage off every transaction made in the world. This is the allure for things like Credit Card processing services. These are usually categorized as connected services since a Web Service call is made to the Credit Card processor to record the sale. However these aren’t simple add-ons to an ERP system, they are quite complicated integrations and require changes to document processing at several points. The Accpac integration to Sage Payment Services is covered here. A scary SciFi novel I once read (but don’t remember the title or author) had the world government running taxation this way, taking 50% of every transaction; hopefully we don’t reach that point.
Other transaction based services could include sales tax calculation and reporting, income tax reporting/filing, direct deposits and check printing/mailing.
So how can ERP and CRM packages incorporate some of these ideas into their products?
Incorporating Credit Card processing is fairly straight forwards. The goal would be to integrate as many payment methods as possible including Credit Cards, Debit Cards, Gift Cards, Mobile Payments, etc. Basically accept money anyway possible via any hardware device (dedicated, phone, etc.). Other transaction based services like tax calculation, direct deposit and tax filing can also fit this model quite well. Here the sales model is switching from an upfront sale and M&S to a transaction based sales model.
Does an app store make sense for an ERP or CRM package? A common complaint we get is that people would like to use more third party add-ons, but finding out about them, buying them, installing them, maintaining them is a hassle. We get the same complaint for our own extended solutions and options products. An App Store seems like an ideal way to make this all easier. It gives one place to shop for extended solutions, it provides a simple unified way to buy them and then they will download and install automatically. Plus this simplification usually leads to higher volumes and lower costs. TechCrunch published an interesting article on how the Mac App Store greatly increased sales for the EverNotes application: http://techcrunch.com/2011/01/19/evernote-mac-app-store/. This shows that an App Store can be more than a small incremental increase in revenue, but quite game changing.
The trend in our products recently has been to bundle many options or extended solutions products into the main product. Now we seem to be going through a period of unbundling. The interesting question will be if say we offered more Accpac dashboard widgets on an App Store rather than including them with the core product? Would this cause a lot of complaints? It wouldn’t if they are offered for free, but if we start charging how much can we charge? Will this make a profitable side business? These will be interesting questions and things move forwards.
Often connected services can be added to augment standard parts of a typical ERP process. For instance let’s consider a typical sales cycle and the some possible connected services that could augment each part of the process.
You could then do the same thing for other ERP processes. For instance in the HR module you could have various connected services that help with the whole hire to fire cycle.
Not all connected services have to be charged. For instance automatically drawing a Google Map by every address is a connected service, but thanks to Google, quite easy to integrate into applications and then available for free. Same thing for doing research via a web search and many other things. As we go forwards we will see many cases where ERP or CRM forms are supplemented with information gathered from the Internet.
How do Business Partners factor into these equations? Certainly the role as Business Advisor and Accountant are still as strong as ever. I hope as these sort of concepts move forwards that we do reduce the role of Software Installer and Data Converter. I tend to think that if our Partners are freed up from these sorts of roles they can concentrate on higher value activities like new sales, expanding the role of ERP/CRM in existing businesses and acting as Business and Accounting advisors. One of the big problems we have is that whenever we release a new version, upgrading the entire customer base, far exceeds the Partner channel capacity. We really need to ease this burden so that so much of our Partner capacity isn’t used performing upgrades.
Connected Services are an exciting area. The Web and Mobile worlds are becoming more and more interesting and applicable whether you are running locally installed Windows desktop applications or Web applications that live in the cloud. As ERP and CRM applications move forwards rather than adding all functionality into the core product, far more effort will be going into integrating in all these readily available connected services. The other key part is to work hard to reduce installations issues, so all these things can be installed very simply by a download and putting the files in the right places.
On to 6.1A
Last month we shipped Sage ERP Accpac 6.0A and started working on Sage ERP Accpac 6.1A. Accpac 6.0 introduced our new Web Based technologies with the new Portal, Dashboards, Inquiry tool and Quote to Orders. With Accpac 6.1 we are now looking to fill out the main Accounting functionality by offering Web versions of G/L, A/R, A/P, I/C, O/E, P/O, Bank and Tax (i.e. everything except Payroll, PJC and some options products). This blog posting will fill in a few more details of the plan that was outlined in the Product Roadmap posting.
There will be additional features beyond moving all the screens to the Web, but we’ll talk about those in other blog postings. This posting is going to concentrate on the logistics and process we will be taking to move all these Accounting screens to the Web. One of the other features we will be adding is support for additional Browsers including Chrome, Firefox and Safari. Below is a picture of Edmund Tong and Accpac Jack with the Portal running on an iPad in Safari and on a Galaxy Tab in Chrome.
Edmund is a key Accpac development manager and will be demoing these at the Sage Insights conference in South Africa in a couple of weeks. If you happen to be in the Drakensberg then, be sure to check out his sessions.
Remember that as we move these screens to the Web, we will leave the current VB screens in place. As the new screens are developed we will switch to running these from the new Web based Portal. But you will still be able to run the older Windows based Accpac Desktop like you did in 5.6A and run the familiar screens from there.
How to Move Thousands of Screens to the Web
The challenge we have is to move over one thousand screens to the Web quickly, but we want to do a better job than just moving all the VB screens unmodified. We want to add definite learnability and productivity enhancements in the process.
Many screens are already very simple to use, and many others are used very infrequently or are only setup by Business Partners once. We don’t want to spend much time on these screens but concentrate our effort on the screens the customers work with the most. So a lot of work has gone into categorizing screens and determining how much effort we need to put into them.
UCD Porting Guidelines
We have developed a set of User Interface guidelines that categorize our User Interface forms into a number of categories like: Setup Screens, Printing and Processing Screens, Inquiry Screens and Document Entry Screens. Then we have a set of guidelines for each type and a set of instructions on how they look currently in VB and how we want them to look in the Web.
Below is an example showing how some elements look currently and then how we want them to look now. Along with some instructions. Below is one of these from the rather long porting guidelines on our development Wiki.
We have also developed a “porting tool” which will read VB projects and interpret their screen layouts and then generate an Accpac 6 declarative layout based on the original VB screen, but trying to follow as many of the porting guidelines from the UCD document as possible.
This was a fairly challenging tool to write. Forms in VB are laid out using (x,y) co-ordinates; whereas, in the Web everything is laid out using layout managers. Plus we wanted to do transformations like from notebook tabs to disclosure panels. But the tool was quite successful and saves us a lot of work creating the starting forms with all the controls bound to the fields in the SData feeds. We are just in the process of adding this to the SDK so ISVs can make use of the tool to start converting their VB based forms to the Web in the same way.
We aren’t going to port all the screens in this way. We will select specific high usage screens where we want to target greater productivity and learnability and for these we will apply specific UCD treatments to work to improve these screens more than the others. Below is an early prototype of A/R Invoice entry that we are now using for user testing.
We will sit users down in front of this and observe them entering Invoices to see where they have trouble so we can tweak the design to smooth these out. Performing this sort of User Centered Design can be quite time consuming since we have to go through several rounds of this testing/refining before we get a design our users are most happy with.
We are starting to move all the forms for A/R and O/E first. Although we won’t be releasing the product until all the modules are done, we will be demoing and beta’ing the applications as they are completed so we can get early feedback from partners and customers early in the development cycle so in can still incorporate all good feedback into the product before it ships.
The development team is extremely excited with building on the results of 6.0A and now running with it to move all of Accpac to the Web. We are looking forward to an exciting and rewarding development cycle for 6.1A.
Accpac development is performed by teams at several locations, but the largest is the Richmond R&D Team:
Back in 2006 Sage acquired credit card processor Verus which is now Sage Payment Solutions (SPS). Previously Accpac only had built-in Credit Card processing through its retail Point of Sale solutions, the previous ePOS solution and the current Sage RMS solution (only available in South Africa and Australia). Other Credit Card applications were left to the ISV community. However Credit Card processing is becoming much more prevalent in today’s transactions (along with debit cards, gift cards and other electronic payment mechanisms) and customers are looking for an integrated out of the box solution with a very tight integration. Plus there are newer compliance requirements that apply to anyone taking Credit Card payments. This has all combined to lead us to develop a Credit Card solution built into Accpac, using Sage Payment Services that adheres to the new stricter regulatory demands. This new Accpac to Sage Payment Solutions will be released mid-year (2011). The name of the product from SPS that Accpac will integrate with is called Sage Exchange. Below is a block diagram showing the main components where the Sage Software Product is Accpac.
In 2010 we had new much stricter rules for credit card processing come into effect called the Payment Card Industry Data Security Standard (PCI DSS). One key aspect of PCI DSS is that any application that handles credit card numbers must be PCI DSS certified. SPS has developed a new PCI DSS compliant service called Sage Exchange. The key point of this integration is that Sage SPS will be the only application that handles the credit card numbers, Accpac never touches them. Hence Accpac doesn’t need to be PCI DSS certified; only Sage Exchange does (which it has been). There are other compliance regulations that companies need to adhere to, but these handle the parts to do with the Credit Card processing software.
We will be introducing this module as part of Product Updates for both versions 5.6A and 6.0A. After you install this Product Update, you will be required to perform a Data Activation to add fields to some A/R and O/E tables to track the Credit Card transactions. The Credit Card module itself will be included with Accpac at no extra charge; but, you will need to sign up with Sage Payment Services and use their service.
Historically Accpac has always left credit card processing to ISV products such as Iciniti or Paytelligence. These products will continue to offer complimentary and extended functionality to the Accpac solution. For instance offering the ability to interface to non-Sage Credit Card processors.
Credit Card Number Handling
What does it mean that Accpac will never touch the credit card numbers? It means that whenever a Credit Card Number is required, Accpac will invoke a Sage Exchange screen that will swipe the Credit Card and that this number will never be handled by Accpac. Sage Exchange runs as a separate process under Windows, so the credit card number never even enters an Accpac processes memory space. Credit Card numbers can still be stored, but not by Accpac, they will be saved in the Sage Exchange Vault on a secure server in the SPS data center. We’ll go through this process as we walk through the steps people will go through to remember credit cards for customers and how to charge them when making orders.
Scenario 1: Having some credit card numbers on file for a customer. A/R Customers will now have a notebook tab for credit cards numbers. Rather than one, this will be a table control where you can enter as many credit card numbers as you like. However for each credit card number entered, a Sage Exchange screen will come up to enter and save the credit card number, the number will then be saved in the Sage Exchange Vault which has passed a PCI DSS certification audit for data security. Accpac will then display some identifying info on the card, but won’t have ever seen the credit card number which will be represented by a bunch of X’s and the last 4 digits of the Credit Card number. In Accpac, there is an identifier that is used to reference the card inside the SPS Vault. Then later when doing an order, Accpac can issue a command to SPS saying something like show a charge screen defaulting it to the credit card identified by this magic identifier.
Scenario 2: Charging a customer’s credit card in Order Entry. The rules of the Credit Card industry is that you can’t charge a Credit Card until you ship the product. But there is a mechanism to pre-authorize a transaction at Order time, so you know the Credit Card should process when you ship. So at Order Entry time you enter the Order as normal in Order Entry, then once done, you press the Pre-Authorize button and a Sage Exchange screen pops up that lets you enter the Credit Card info to perform the pre-authorization (which will decrement the Credit Card’s credit limit). Then when you are in Shipment Entry and shipping the Order, you can charge the Credit Card and this should go through since the credit limit was reserved by the pre-authorization. Now O/E will generate a pre-payment for the amount so you can track that it was paid in Accpac. If you Invoice as part of shipping then the pre-payment is associated with the O/E Invoice. If you Invoice later then the pre-payment isn’t associated with the O/E Invoice, but will be matched up once everything hits A/R (since A/R is responsible for collecting money anyway).
Scenario 3: The customer returns the item and wants a refund. You then go into A/R Refunds and when you enter the A/R refund document, you can also popup a Sage Exchange screen to credit the credit card. We do have a restriction that then if you want to undo this, you can’t reverse the refund, but have to just enter a new Order.
For any transactions that our integration doesn’t support you can also use the Sage Payment Services Virtual Terminal to enter any other types of transactions and then enter matching documents or G/L entries into Accpac. There is also a reporting portal where you can get all sorts of reports for all the transactions you’ve made through the service, as well as things that happen on the back end like updating your bank account.
In version 5.4A we added a feature that let you reconcile Bank deposits by detail. Then as part of the effort to simplify the Bank Reconciliation process, we removed this feature in 5.6A. This turned out to be very unpopular. As part of this Product Update and partly because this is an important feature to reconcile deposits that include Credit Card info as well as cleared checks, we are bringing this feature back.
Basically when you clear a deposit you will have a new deposit status that you can set to “Clear by Detail” and then get a pop-up screen where you can clear (or not) the individual deposit detail lines.
To keep thing simple we won’t be re-introducing some of the write-off functionality. If you clear a deposit with say bank error then that will clear the whole deposit and write off the amount. There will be no write-off by detail and there will be no pro-ration of write-off over detail lines.
This particular feature will only be in a Product Update for 6.0A. It will not be re-introduced to 5.6A.
To use this feature you will be required to sign up with Sage Payment Processing and to use this service. We won’t support using non-Sage processors. Sage Payment Services only operates in Canada and the U.S. so we will only support CAD and USD transactions. SPS screens are currently in English only, however we will ensure all the Accpac strings are translated, so you will get translated screens once SPS releases a version with French and Spanish support.
This feature will introduce built-in Credit Card processing to Accpac. Here you will have one stop shopping for all your Credit Card processing needs.
This Product Update will automate and integrate A/R and O/E processes to the Credit Card processor (SPS) to reduce data entry and hence increase productivity and reduce errors due to duplicate data entry.
The goal of Sage Exchange is to eventually go beyond just Credit Card processing and to handle all forms of payment processing including all sorts of Payment cards, as well as handling check processing. Then to add integrations to the A/P side of things. Then potentially if you have two companies that do business using and use Sage applications for their ERP then the A/P of one will be able to automatically pay the A/R of the other through Sage Exchange with no manual entry or intervention required.
Update 2011/03/01: Sage Exchange now supports French (Quebec) and Spanish in addition to English.
Happy New Year everyone. Hope you all had a good holiday. Over the past year this blog has had quite a few postings to do with Sage ERP Accpac 6.0A and the new Web Based technology platform that it is based on. Sage ERP Accpac 6.0A has now been released. It has been available for download for a couple of weeks now. In this posting I wanted to address a number of questions I’ve been receiving as well as try to put to rest some misconceptions that seem to be out there (mostly to do with the transition from VB to Web).
Does Sage ERP Accpac 6.0A become a 100% full web based solution? No – this is the first step in that journey. With this release we have the technology foundation, the new web based portal, the new dashboard, the new Inquiry tool along with the web based screens that make up Quote to Orders. All the other accounting screens are still the VB screens similar to 5.6A.
When Will Sage ERP Accpac be 100% fully web based? Version 6.2 which is estimated for release at the end of calendar 2012. With this release the entire product will have a web based option, including all accounting modules and options products. However version 6.1 which is estimated to ship at the end of 2011 will have all the major modules Web based including GL, AP, AR, IC, OE and PO.
As Web Screens are released will the VB screens disappear? No. You will still be able to run the VB screen from the original Accpac desktop. As Web Screens are completed they will take the place of the VB screens in the new Web Portal, but the original VB screens are still installed, supported and accessed from the original desktop.
How long will the VB screens be supported? At least through 6.2A, beyond that it will depend on market demand. If everyone moves to the web quickly then that will be it. But if it takes time to move customizations and such, then you will have that time.
Is SageERP Accpac 6.0A SaaS? No. This is an on-premise installed product. You can install it in the cloud, but this is still essentially on on-premise install, just with a remote server.
When will there be a true SaaS version of Accpac? After we have a number of accounting modules Web based then we will look to do a SaaS deployment through AccpacOnline (ie after 6.1 or early 2012).
If I don’t deploy the web components, why should I upgrade to 6.0? There is the lock fiscal periods by module feature that is used by both. Plus there are many bug fixes.
Why should I deploy the Web components? You will get the new portal, dashboards and inquiry tool. Plus this will prepare you for 6.1A. If you get the web components going then installing 6.1A will be very easy since you will have the infrastructure all deployed.
If the product is web deployed why do I need workstation setup? Until the VB accounting screens are moved to the Web in 6.1 or 6.2, we are running the current VB screens from the Portal. The only data entry screens in the new Web technology for 6.0A are the Quote to Order screens run from inside SageCRM.
Why is there an ActiveX control in the new Portal? This is required to run the VB UI screens. This will be removed once all the VB screens are moved to the Web.
Can I run the Portal for remote users? Only for the new Web parts. The VB screens will not run remotely with this technology, Workstation Setup is required. This will be more realistic starting with 6.1A.
Can I use browsers other than IE? The only supported Browsers are Internet Explorer 7 and 8. You can use Firefox, Safari or Chrome but you can’t run the VB screens from these Browsers (since they don’t support ActiveX controls). The CSS (Cascading Style Sheets) are optimized for IE and will have many rendering glitches with the other browsers (this will be fixed for 6.1A).
Does the new Web Portal use a Lanpak? No. Logging on to the new Web Portal, seeing the dashboard, drilling down to reports from the dashboard, accessing help and using the Inquiry tool does not use a lanpak. However you will use a lanpak the first time you run an accounting screen. The idea is to promote the use of Accpac in the Enterprise outside of the accounting department.
Do the Quote to Order Screens use a Lanpak? No. You just need the SageCRM User count to sign onto SageCRM, then no further Lanpaks are required.
Do I require a new server for the web parts? Depends. Often people already have a good file server that is being under-utilized, you may be able to use this additionally as your web server. If you are already running SageCRM, then this server will probably be ideal as the Accpac Web server also. But if you are running local installs and Pervasive workgroup and have no server, then you will need to get one.
Where can I see a demonstration of Sage ERP Accpac V6.0? You can view a short 5 minute overview video on YouTube: http://www.youtube.com/watch?v=HYUErIxYiPg. You can also view short, detailed videos of each new feature at: http://www.youtube.com/user/SageAccpacDoc.
Where can I learn more about what’s new in Sage ERP Accpac V6.0? You can visit a dedicated website with details on the V6 release: http://sageerpaccpac6.com/.
In addition, Sage University (http://www.sageu.com/accpac) offers a FREE anytime learning course about “What’s New in Version 6.0”. Customers and solution providers can register (for free) and complete the online curriculum at their convenience.
This course provides an overview of all the exciting new features offered in our version 6.0 release of Sage ERP Accpac. You will find out about how each feature works and how it can improve and enhance your Sage ERP Accpac solution. Learn about our new Sage ERP Accpac Portal and other key enhancements that are now available in Version 6.0. This comprehensive course includes information on Extended Enterprise modules like SageCRM. To make the most of your investment with Sage ERP Accpac and learn all of the amazing new features and functions, you must attend this course.
Course Length: 1 1/2 hours
Course Level: Basic Course
Instructional Method: Self paced Internet-based
- Learn about the new Sage ERP Accpac Portal including navigating and security.
- Learn how to work with tasks, shortcuts, snapshots, and the Learning Center in the Portal.
- Learn the new quote to order workflow with SageCRM.
- Learn about Printing and Exporting Inquiries and Inquiry security.
What is involved in upgrading to V6.0?
Upgrading from 5.6 is a single step activation to upgrade to v6.0.
Upgrading from 5.3, 5.4 or 5.5 is a 2 step process – first to 5.6 and then to 6.0.
Upgrading from 5.3 or older is a 3 step process – first to 5.3, then 5.6 and 6.0
In general you will want to make sure the following are compatible with 6.0.
- Program Customizations, VBA Macros, Excel Macros that integrate with Accpac.
- Customized Crystal Reports
- 3rd Party programs that integrate with Accpac
- The appropriate version of MS-SQL or Pervasive database.
It is best to discuss your upgrade options with your Accpac Solution Provider as they are most familiar with your business requirements.
Blog Postings on Sage EPR Accpac 6
Now to use a trick of many blog posters who are lazy during the holidays and rather than write new content just reference previous content. Here is a directory of the various articles on Accpac 6 from this blog:
Sage ERP Accpac 6.x Product Roadmap
On Total Cost of Ownership
Accpac on the iPhone and Android
Sage ERP Accpac 6 Competitive Advantages
Sage ERP Accpac 6.0A Compelling Installed Base Value
How to Best Demo Sage ERP Accpac 6.0A
The Sage ERP Accpac 6.0A Portal
Sage ERP Accpac 6.0 Adhoc Query
Sage ERP Accpac 6.0 Quote to Orders
Sage ERP Accpac 6.0 Data Portlets
Sage ERP Accpac 6.0 – Locking Fiscal Periods by Module
Drilling Down from Crystal Reports in Sage ERP Accpac 6
Running Classic Forms in Sage ERP Accpac 6
Sage ERP Accpac 6 User Assistance
Declarative Programming in Sage ERP Accpac 6.0A
Sage ERP Accpac 6 Performance Testing
Sage ERP Accpac 6 Security
Sage ERP Accpac 6.x Mobility
Automated Testing in Sage ERP Accpac Development
How to Layout Forms in Sage ERP Accpac 6
Creating a Web Form for Accpac 6
Client Logic for an Accpac 6 Web Form
Writing Server Side Code for Accpac 6 Web UIs
Preparing for the Sage ERP Accpac 6.0A Launch
This posting is really just meant to tie up some loose ends from 2010 and to set the stage for 2011. Now that Sage ERP Accpac 6.0A has shipped, I will be starting to blog about Accpac 6.1A as it progresses through development as well as writing posts on topics for 6.0A as well as various topics on 5.6A.
If you have any questions or topics you would like covered in this blog, then please leave a comment. I read all the comments and especially appreciate topics for future posts.