markup rounding --

[raymond]

because CommitCRM can't do proper $ markup on a per piece basis (I have complained about this for years!), I have decided to try using markup by % -- we just discovered that when we do this, invoices are created with cents going out 3 digits... this is not good. If you are going to force us to use % for markup, then CommitCRM needs to round DOWN to the closest penny (in ALL situations)... we can't have something showing up on the invoice as "$145.132" and we certainly can't have the total not equal the price times the quantity. This simply needs to be fixed ASAP... can't believe I'm the first one to notice this bug...

thanks --

//ray

[Support Team]

Re: markup rounding --

Ray, we have your original request for this and evaluate it over and over again. Unfortunately it wasn't popular and this is why we haven't gotten to handle it yet.

RangerMSP Charge based markup/discount are applied after the Item Price X Quantity are calculated.

We will be looking at what you've just mentioned. Thank you for posting this.

Thanks,
Dina

[Support Team]

Re: markup rounding --

Hi Ray,

Please find an update on this -
We pass to QuickBooks the total amount and the quantity. We do not pass the Item Price/Rate. Therefore, the entire rounding happens at the QuickBooks end and by QuickBooks. As far as we can tell there is nothing we can do in order to control QuickBooks rounding to 2 digits.

Hope this helps.
Dina

[raymond]

Re: markup rounding --

Again, this is why CommitCRM needs to change how it's doing the math... percent needs to apply on a per piece basis, NOT ON THE TOTAL!!! I just don't understand why this is such an issue and why the markup/discount is done this way... simply stated, it's technically wrong and now is causing problems with bookkeeping. If the percentage is applied at the per piece level and rounded to the neatest penny then this problem goes away. Again, ALL these issues go away if you apply the markup/discount directly at the per piece level... it's a simple fix and should have been applied a long time ago; apply the $ and % markup/discount at the piece level, not on the total!

The bottom line is that everyone uses CommitCRM to track and handle charges for work and product. Having a system that doesn't do this very basic function correctly is a serious problem... I'm very much getting tired of having to manually adjust markup/discount every time something is processed. Please, (please) have a more detailed discussion internally and get this fixed. We've been waiting years to get this problem resolved.

//ray

[Support Team]

Re: markup rounding --

Ray, we will discuss this internally again. Just note that (1) It's QuickBooks that does price/rate calculation not RangerMSP (I'm referring to the last part of this thread) and that (2) the system is designed to have discount/markups on the Total of each Charge record. It is currently not designed to set the adjustment at the single unit price when charging several items in the very same charge (for this you can successfully use Custom Pricing instead of discount/markup adjustment on the Charge record level, with Custom Pricing you can set a specific discounted/marked up price/rate at the single unit level).

Everything referred here, as far as we can understand anyway, goes back to the request that RangerMSP will also offer an option to apply the Charge discount/markup adjustment at the single Item price/rate level and not on the Charge total (Qty X Price) value. As said, we will reevaluate it.

Call for the community -
In case Ray's request here is something that is important to you too and you need to have this method supported and the adjustment calculated as suggested please post your support for this option in this thread. We need more feedback to see the popularity of this change in comparison to other requests so we can better prioritize our tasks. Thank you!

Thanks again for all your feedback.

Dina

[lpopejoy]

Re: markup rounding --

I rarely use the markup, so not sure I really care. Ray sounds annoyed enough that I'm starting to agree with him though, lol!

What DOES annoy me is that on about 50% of my invoices, the total created by CommitCRM is one penny different than the total in Quickbooks. So someone comes in, pays from the invoice printed from CommitCRM, and then I create the invoice in QB, and receive the payment in QB... The customer has paid an amount that is one penny lower (never higher), and thus I have to give a one penny discount on about half of the invoices.

Not sure that it matters, but with the QB API (according to http://dev.developer.intuit.com/qbSD...ndex-QBFC.html), you can specify a item rate (instead of the "amount") and let QB calculate the "amount" (or line total) for you.

--Luke

[raymond]

Re: markup rounding --

Luke,

I think what you are experiencing is from the issue I describe. Because CommitCRM rounds differently than accounting software (i.e. QuickBooks), you end up with different numbers... and yes, I am getting frustrated -- the number of tickets and charges we are processing through CommitCRM is becomming overwhelming and having to deal with manual corrections is draining to say the least. :-)

Dina,

Yes, QB does the price/rate calculation but it's a case of garbage in/garbage out. If CommitCRM is passing a number that doesn't easily multiply/divide by two decimals, we end up with amounts going out 3 and 4 places. That fact alone should give everyone an indication that the way CommitCRM is doing the calculations is simply incorrect... when QB does the calculation, it rarely matches what CommitCRM calculates, that's a problem. You are correct in understanding what I'm saying; if we can default CommitCRM to calculate $ and % markup (discount) at the piece level, all these problems go away... all of them!!! For the record, I showed our accountant how CommitCRM does the markup and without prompting him, he immediately said "something’s wrong with how it calculates..."

thanks for listening... hopefully we can get a fix soon.

//ray

[AN-Tech]

Re: markup rounding --

I can't comment on the specific issues that Ray is having since I don't use markup. But I can say that I have the same issue that Luke has with things being off by a penny when the Quickbooks invoice gets created.