Method Community

If I check the "Assign Ref Numbers in Method?" box on the QB sync page, does Method check with QB before assigning a number or will there be numbering conflicts between Method and QB?

Hey pdirect,

Method does keep the ref numbers in sync, or rather Method maintains an understanding of the maximum number already used in QB before adding a new number to initialize the increment and to avoid conflicts.  Paul has mentioned in his blog that when using this configuration of Method assigning the numbers it is best to be making entries 100% in Method to avoid conflicts.

The support folks at Method are a more authoritative source, but I've recently asked questions about this, see my posts from the last couple of days.

I'm still currently trying to understand how to get Invoice Ref Numbers assigned quickly as we might be using the old configuration of having QB assign the number for a short time and I am having a hard time getting the Invoice to update predictably such that I can enter an Invoice and then print the Invoice from within the same session.  It seems to require that the invoice screen is closed and then re-opened for the assignment in QB to update, but there's still a lot of tests that I need to make.

Cheers,

James

Hi pdirect,

It looks like Method_Paul answered your question HERE in the comments section of our blog.

-Michael

Thanks . . . but it doesn't seem like that "feature" is too helpful then since I can't imagine that it's very common that transactions are only created in Method.  And if transactions were only created in QB (as Paul mentioned), then I don't see a need for this feature at all.  It only seems helpful if your ONLY creating transactions in Method . . . again a very rare thing.  Sometimes it seems like Method development spends time on features that don't benefit the "whole" very much.

My two cents.

I think this feature is broadly beneficial and very consistent with good development strategy for Method.

QB is great for accounting functions, and in many cases it would be the only tool anyone would want to use.  But, for order entry, production planning, invoicing and shipping it has a rather limited feature set.  A good decision by Intuit in my opinion.

Enter Method as a customizable solution and we can create custom workflows for specific areas of our business.  Once we convert something like Order Entry or Invoicing to a Method solution I think there are a lot of good reasons to go in 100% for one platform or the other, not the least of which is the technical issues of having potentially multiple users accessing the same data table simultaneously.  For example two users entering Invoices at the same time.

We are a very small business and I can easily imagine two of us entering an Invoice at the same time or converting an Order to an Invoice while entering an invoice etc.  The technical challenges to making sure this happens without corrupting the data are not trivial by any means and often it is the RDBMS that does the work of managing the record locking etc.  While this can work easily with a good RDBMS doing the heavy lifting for data integrity it might be nearly impossible to accomplish with two disparate RDBMS's (QB SQL and Method SQL) held in synch by a third party (Method).

While I am impressed with the Method Synch Engine performance so far, as a user and Sys Admin I am very aware of the potential for data corruption if I start to do some weird things in the system.

As for using one system or the other, why bother entering Orders, Invoices, or other specific functions in BOTH Method and QB.  That would mean that I would need to maintain two sets of screens and reports (for which QB will not be able to do what Method will be doing for me) and train my users to use both.

The advantage of having ref numbers assigned instantly in Method will be a huge benefit for me and will essentially be a 100% or more effective improvement in the overall SPEED of Method.  Imagine entering an Invoice and then wanting to print it with an Invoice number in the same session, we will do this every day.

We will always reserve the use of QB for maintenance tasks, Admin fixes, etc., but it is a good idea to plan to run a business process in one system or the other 100% for a lot of reasons and I think this is a very reasonable limitation.

IMHO.

Cheers,

James

We're not talking simply about your business, we're talking about the majority of businesses.  I've been managing IT for small businesses since 1998 and I can attest that your experience is not the norm. Most businesses will either use QB or both QB and Method.  And my point was that Method development should focus first on improving/adding features that would apply to the majority of its users instead of a small niche. 

I'm glad it works for your business ... I just don't see the benefit for most.

I'm not thinking about only my business either and with extensive engineering, business, and IT experience in businesses of all sizes from the very largest to the smallest I can say with confidence that I believe improving the performance and stability of key field updating and synching should be a priority for Method development and I applaud the Method development team for continously refining the synchronization logic, particularly in the face of requests for more "features".

The live syncing of Method with QB is the single most important differentiating technology offered by Method followed by the web based development tools.  There are a bunch of other folks offering third party application bolt on's to QB, but none with live synchronization and web based customization tools like Method.  While there is a ton of built in functionality in Method, it is really the stable implementation of a mirror of QB's database in Method and the reliable synchronization between them that is truly fundamental to Method's benefits.

Maybe we are the only business which intends to use Method to enter AND print Invoices, but I don't think so, and if you have ever tried to enter an invoice you will notice that you do not get the Invoice number update back from Quickbooks instantaneously.  You must save the invoice and then reselect the invoice from the refreshed Grid to get the Invoice number to update for printing, assuming the real time synch is running smartly.  Maybe we are also the only business who wants to enter an Invoice and then immediately print the invoice, but I don't think so.  Maybe we are also the only business who wants to enter an Invoice and then print the Invoice AND a Packing List because we want to ship something, and maybe we're the only ones who want to do all of these things quickly because we've already called the truck, again, I don't think so.

Having Method update the refnumber internally without going to QB to get the number assigned will benefit anyone who wants to enter an Invoice and then print the Invoice, Packing List, BOL, and Shipping Labels quickly. 

With all confidence and much more experience I can say, this is an improvement that will benefit many of us using Method.  I'm sorry you're missing some "feature" you would like to have, but you're barking up the wrong tree to complain about this core technology improvement.

Silly. I'm not barking up the wrong tree. We just have different perspectives and differenet business needs. As I said previously, I'm glad it works for you, but for most people, I don't see the benefit.

Hey Michael,

When this box is checked, it looks like it looks at the old numbering sequence in QB. My last number sequenced in the estimate list in Method is 'Q144-675'. After creating a new estimate and clicking save, Method auto populated the ref number with 456457. It does that whether I have 'Wait for sync Approval' checked or not. 

I would like to make a request to enhance this feature to sequence the Method numbering whether alpha, numeric or alpha numeric. 

Lance,

There might be some really good reasons why Method auto indexes ref numbers in the way it does since QB does some weird things with automatic indexing of ref numbers.  For example Quickbooks uses the same ref number index for Invoices and Credit Memo's.  So, for example if we add some alpha characters to the Credit Memo number to make it different (don't ask me why) for example DMR32112, the next Invoice number in QB would be DMR32113, even though the last Invoice number was 67212.  But, when Method assigns a new ref number for an Invoice it will index from the last Numeric number for example 67213.

If QB maintained seperate index streams for Invoices and Credit memos there might be a way to make everyone happy, but with a shared index stream the number of permutations of use cases where people could potentially include alpha characters in either or both QB and Method and then the different business decisions of whether to begin a new index become untenable, IMHO.

The current logic of Method using the last numeric number appears to be a graceful failure in some ways, or at least I have found it manageable.  I always get a number number in Method for a new invoice even if someone has entered some weird alpha character for the Credit Memo.

I'm not saying that all use cases could not be modeled and coded, I'm just not sure it's worth it, but if you want a change, please try to be aware of all the potential functionality it will impact.  It's not as simple as it might first appear.

James