If your implementation is simple without customizations and historical data migrations it is very unlikely that you are reading this publication. Likely that in your situation you either are trying to force through massive historical data export from legacy accounting and import into Business One or maybe got complex SDK programming project in limbo and over budget. Generic consulting firm which is typically located in neighboring town has so-called sales engineers and functional consultants. These professionals are good in such areas as standard business logic executive presentation, user training, setup GL account balances. But what they likely do not do very often are complex data migration and software development. Several regional consulting organizations might have to share the same SDK programmer or technical consultant on the subcontracting agreement. But when you do such human error sensitive job as programming subcontracting model might be too loose to provide reliable quality assurance and bug fixing. If your project went into limbo stage let's review the way out:
1. Consulting firm revenue structure. You need to understand how consulting industry works. The revenue typically splits fifty to fifty to software license selling margins and billable consulting hours. If you already paid for the software through your original reseller and decide to switch to nearby competitor for fixing up failed implementations these new people may say something like this: "Thank you very much for calling our company. However there is no software licenses revenue part and we have to deal with the C# SDK code which was not written by our programmer. We probably are OK if you continue shopping in the area"
2. Regional or Nationwide consulting firms with remote support model and specializing in technical consulting to existing customers. These firms typically have the following motto. We do not have salaried functional consultants and sales engineers to pretend on high initial software licenses margins. However we are specializing in customization, integration, data conversion, complex reporting. We have so-called SAP Business One Software Development Factory or in other words group of dedicated Microsoft Visual Studio VB and C# programmers who are certified in SB1 Software Development Kit, Crystal Reports, ODBC sources import via Data Transfer Workbench
3. Second Opinion. It is important to have a trust in your original VAR however there should be balance between this trust and the feeling that their experience should be questioned as the project goes South. As SAP B1 customer you have to have official VAR at the time. Corporate ERP software vendors do not like the idea of having several certified consulting firms to serve you at the same time without central coordination of the VAR of record. If you decide that it is the time now to sign the contract with new SAP B1 partner to be ready to do it officially with SAP. Let's now take a look at typical failure reasons
4. Historical data conversion. General advise: it is not recommended. Try to consider the following idea. Why don't we just keep our legacy accounting for inquiry only and closed for new data entry? If you do not have this option due to the fact that your legacy software was based on subscription licensing model or another reason consider exporting its data into MS Access database or maybe even text files. Historical data migration project is typically complex and Data Transfer Workbench CSV templates might be too primitive for entering millions of rows in Excel. Here you might need professional SQL programmer who is also experienced in SAP BO business processes and objects structure
5. Complex Customizations. SAP B1 SDK openness to generic Microsoft Visual Studio programmer might be misleading. In mid-size firms we often hear the initiative from IT department folks about programming SB1 SDK internally. Well, it is possible however in the learning curve you might expect such underwater rocks as poor performance (being very slow in custom user interface), issues with table structure and inability to feed or update records directly via SQL insert, update statements and stored procedures
6. Data Export Puzzle from Old Accounting. If you are migrating away from really old accounting package then the data connection technology might be not really known to modern generic programmer. Good example is Great Plains Accounting DOS 9.5 where single Btrieve file may share several relative tables. Even if you were successful in generating DDF files required for ODBC data connection the issuing select statement in Pervasive SQL Control Center you are getting strange rows and have no clue