Sage 100

Has anyone run into an issue where Sage 100c 2016 PU3- SO entry -> shipping -> invoice = apply a CC during the SO creation and click off pay balance -- invoice prints fine - zero balance (which we expect) but the journal updates - we go look at the AR Aging report and it shows that customer still owes freight on the invoice. Yet the invoice printed shows $ 0 balance. After the original cc is applied and we check ""pay balance"" there are changes to the freight amount which is where the discrepancy seems to be occurring. Invoice shows $0 (paid in full by CC) as we want it to. The posting to gl and aging seems to only use the original authorized CC amount which leaves a balance. **TL;DR:** v2016.3 - If you are NOT integrated to a credit card processor and are entering credit cards manually (after the fact) you will find that if you change the total $$ on the invoice after entering the CC authorization then the invoice prints with the full amount of credit card deposit, posts to the GL and AR Aging with the authorized amount of the credit card. Sage denies this is a problem and ""we don't support manual credit cards"".

Not integrated with CC - entering CC info after the fact

Looking further - some applied in full , some not. Unsure if this may be data entry problem on our end.

I think the problem is we have ""Pay Balance"" checked. This immediately creates an authorization amount. If you subsequently add freight which ups the invoice $$ it is showing the same authorization amount which seems to only factor in when updating to the aged invoice report and shows the invoice balance incorrectly (balance due vs fully paid). When we send the invoice the total is shown correctly at $ 0. We are not integrated to CC processing so the authorization amount is not meaningful to us.

At the least this is a bug with the form (happens on Standard) - however I think if you flag the invoice to pay balance on credit card there should be a mechanism to pay the entire balance.

I opened a case with Sage - I suspect they may deem it a bug in their form since that might be the easiest to correct

Sage says they can't test because they don't have a system that isn't connected to credit cards. Despite showing them the paperless documents they still want to shadow my customer instead of test on their end. This after spending 30 minutes showing the tech in detail what the issue is.

Are the invoices in history correct? I had a similar issue and it seems that in a few instances a month the deposit amount on the sales order wasn't populating the invoice. The end user uses shipping data entry. We put a developer mod in to check the sales order during invoicing (both SO Invoice Entry and Shipping data entry). If there is a deposit on the order and not on the invoice then write it to the invoice. That seemed to solve it. I wrestled with that one for a couple of months and never did determine what the root cause was.

The history does appear correct. I haven't gotten back to the office to try to test on my version of Sage 100. I was a little disappointed that Sage couldn't (wouldn't) test a vanilla - no modes - report of a possible defect given that I also was able to provide documentation on. My expectations of Sage are so low that they met them in this case.

Could be a problem with the work file that Sage generates for printing the invoice.

Prediction: I won't see a ""were you satisfied"" survey.

There is nobody left to review the survey results anyway. The only results management cares about are this quarter's financials.

I tested this on my Sage 100 v2016 PU3 and get the same results. if you enter in an invoice directly to invoice data entry - pay it by credit card on the totals tab and enter the authorization code (you cannot save without doing so), then go back into invoice and change the freight from say $10 to $60 - Sage pays by credit card all but the $50 difference in freight increase. That amount goes to the AR however the printed invoice shows that the entire invoices was paid off. Once you enter in the authorization no. Sage seems to use the Auth Amount for DTR/Sales Journal but the full amount for invoice printing. (yes, I do understand the concept of auth -- and am questioning why there's also a ""pay balance"" button although maybe that's there just to easily fill in the totals for the cc) The fact that the invoice shows $0 balance yet the DTR updates only the pre-auth amount seems to hint that it's some type of bug in Sage. It appears that the workaround is: a. Enter credit card info at the very end just before updating -- not at sales order entry time (this seems to only impact people who enter the card BEFORE finalizing the invoice) b. Prior to updating the invoice check and uncheck the ""pay balance"" in the credit card area - this will require that you re-enter the authorization number NOTE: This customer is NOT connected to credit card processing - they are entering the card after the fact (when it has been manually charged on their terminal ) so I do not know if this same issue is present for people who are fully integrated to credit cards. Natural question ""So Wayne, why wouldn't your customer implement credit cards integrated to Sage 100 since it works beautifully?! "" ME: Customer has an existing merchant account at local bank where they are extremely happy. From what I've seen there is no practical way to fully automate credit cards without (a) switching merchants or (b) paying a higher rate for the ""bring your own merchant"" option. (I would LOVE to be proven wrong on this and if I am please provide details of how to bring your own merchant without paying some type surcharge)

Silly me. But isn't this working as designed, especially when not using integrated credit cards? The ""final payment"" needs to be applied in Cash Receipts. The invoice will show it as paid, just as the original deposit shows as a payment before you process the Cash Receipt to the Deposit Account. Let's say this entire payment was paid at invoice time. The invoice would show the payment (paid in full); then you have to do the Cash Receipt against the invoice to show the invoice as paid.

I think that's what Sage is going to argue however a review of the help file seems to indicate that checking the pay balance automatically applies the balance during the update. Why the functionality would be different integrated/non-integrated is probably something we could debate without ever reaching a conclusion. I will say that printing an invoice with $ 0 balance yet updating a balance to the AR Aging is in my view a bug. I know Sage is only interested in selling more stuff so I fully expect that they are going to push back on this and I'm advising the customer to devise a workaround.

My understanding is the sales journal program compares the deposit on the sales order the invoice total and then creates an entry to adjust for the difference. For example, some end users charge the card for the order amount (a deposit). The freight is added to the sales order and the card is either manually charged, or automatically charged during the sales journal update for the freight. The appropriate journal entries are created.

My opinion is that if I'm manually entering a card and click ""pay balance"" that it should, in fact, pay the balance. This is definitely a bug but the exact nature of the bug is either: - The crystal work file is populating with the wrong $$ and should only be given the authorized $ (probably the easiest fix but I disagree with this methodology). - The invoice printing/work file is good and the Sage GL and AR posting is wrong and should be using the full amount of the credit card deposit and not the authorized $ since with a manual credit card posting there's really no use for the authorized field.

but... how do you handle depositing the payment for the final payment? If it is a Check, or Cash, or Credit Card, it still needs to be deposited to the bank. Until Sage changes that process, and supports a Cash Receipt directly from SO Entry (kind of like Business Works)...

I think Sage should directly deposit the prepayment (credit card or check). As of now it's a confusing two step process where: 1. We create a ""Credit Card Holding"" or ""Prepaid Cash"" type account 2. Use cash receipts to move it from either of the two accounts into the regular cash (and also onto BR). The above is the same whether credit cards are integrated or not. Customers - especially younger people - look at you as if you are wearing a martian costume when you explain this procedure to them. It's one of the things Sage should have been fine tuning with regular product improvements beginning 5-10 years ago. Today's world -- at least for many distributors -- involves prepayments and wire transfers often in advance of the order shipping. Sage hasn't kept up with the times. The procedure they have for these credit card payments was probably pretty good back in 1985 but it's 2017 now and people more and more expect that this will be second nature.

For now I am using this report to show where the authorized <> total invoice amount by batch / invoice. The customer goes into each invoice and unchecks, re-checks the ""pay balance"" button and then re-enter the auth number. This corrects the issue and the auth will then equal total invoice and everything posts as expected.

You could probably do the check with a pre-write script, to validate the amount and present a pop-up is the amount doesn't match...

I completely expected this. However - wasn't manual credit card entry available prior to Sage introducing their credit card integration?

Not to mention that I believe her reply is factually incorrect on several levels: - Sage accepted credit cards manually prior to or alongside credit card integration. I actually think the manual method came first - Her explanation of manual credit cards not being an option conflicts with what my customer has been doing the past three weeks - namely entering credit cards manually. We have not had to use a fix button - nor have I seen a place to use one. There is however an apparent product defect with manual entry as noted above. Remind me again what the subscription a customer pays goes toward? Is the Sage Foundation or the Davos busting videos that Sage UK creates?

Sage 2013 training specifically included a vault only cc payment type.

New theme music for Sage https://www.youtube.com/watch?v=OWUZwkSa4eQ

Turns out this is partially a form issue - appears that using a form code base upon anything except preprinted laser causes the printing issue, however, there appears to still be an issue with incorrect GL and AR posting. Turned it over to Sage for further review. Pretty sure that's the last I'll ever hear of it. I still do not agree with how Sage handles manual credit cards but I do not think that is a battle I can/will win so I just reported the discrepancy in what prints and what posts.

new related post: https://90minds-com.socialcast.com/messages/33242934?ref=stream