We have two .NET apps used to import customers and transactions into our db.
One is "client" app running on QB user's side another one is a small web service to interact with web connector.
We save all custmers and their "base class" transactions / changes in our DB and display on a web site. Users can see their transaction information there. Problem is that customer's balance does not always get equal to Sum(Amount) for their transactions. We already know that a customer can have a job (sub level customer) and count those transactions too. Still it appeared that a customer can get payment discounts and we needed to count that too.
What is a reliable way of counting customer's balance which always coinside with to their balance ?
I read a post about using Balance Detail Reports but I'd like not use it.
Thanks,
Vlad
It's hard to give a exact answer as there's a lot of little pieces that you may be missing, we don't know how you are calculating your totals so it's just guess work here. Here's a list of the transactions that I know of that effect a customer's balance, along with some things to look for.
Invoices can have a subtotal and sales tax which should both increase the balance.
Receive Payments can have discounts which should also reduce the balance along with the payment amount.
Journal Entries against Accounts Receivable for the Customer will either increase or decrease the balance depending on if it's a debit or credit to the AR account.
Credit Memos should reduce the balance.
Keep in mind there may be more than one Accounts Receivable account, so you need to make sure you don't filter for all A/R accounts on Journal Entries.
Your best bet to figure out what you are missing is to find a customer who has a different balance than what you calculated and review your detailed transactions vs. the detailed transaction for the customer in QuickBooks.
Related
I am working on a project where I need to capture one time payments from an account. For a bit of background: The account has many users, where users are part of teams as team_members. I have another model we can call projects where teams are affixed to the project. It is on these individual projects that I would like to have a checkout button. The price for this one time payment should be calculated based on the number of individuals in a team, that are part of this project.
My issue is that I am not 100% sure how to achieve this for one time payments in stripe. Should I set this up alike that if I were to sell an individual item? Product (with name, description and price) and an Order to affix to the user?
I've built subscriptions plans in Stripe before, but have never really used one time payments. Any guidance on setup here would be really great.
Small Edit:
When a project is created, a team is selected. That team size is known to the project.
If I have 3 tiers for pricing:
1-5 people in a team is $x
6-20 people in a team is $y
21+ people in a team is $z
How would I go about invoking the correct tier based on the team size for the project?
If you want to keep users on your application while paying, following the web payment example is what you'll want to do. You would provide the amount when creating the PaymentIntent.
You should calculate the amount you want to charge in your own business logic. Once you've got that number, there are several ways you can collect one-time payments with Stripe.
If you want to offer the most flexibility for supported payment methods with the lowest amount of integration effort, Checkout would be a great option. You would supply the amount and a description with the line items while creating the checkout session.
If you want to keep users on your application while paying, following the web payment example is what you'll want to do. You would provide the amount when creating the PaymentIntent.
Looking for best practice and/or improvements on logic.
I’m building an app where a member accepts a bid from a guide on a trip and pays for it. Depending on the situation, the member may pay a deposit at bid acceptance or pay for the whole trip (depends specifically on guide's settings and trip cost). I’m trying to determine the best way to determine what charges have occurred and what charges need to occur in the future.
My thought is to create two tables: charges and payments. Charges will track the successful payments. If the first payment is a deposit then a record will be created in the Payments table with the remaining amount to be paid and due date. This can then be charged in the future.
Is there a better way to handle this? Thanks in advance.
I have an app I'm working on that is a credits system for a store. A customer brings in items and receives a credit and then can turn around and use that credit towards certain goods in the store. I've set it up so every time a credit holder or credit is created,updated, or destroyed the event is logged. I'm wondering if there is an easy way to use the event data from the logs to create a dashboard displaying things such as X number of credits created and Y number of credits used today. This may not be the right way to go about doing this at all and if so feel free to guide me in another direction. Thanks in advance!
You should save the information into a database (in addition) to the log and operate on it in this fashion.
So for example, maybe you have a User it should be a Model and have credits which should be an integer. You can modify this value every time a transaction happens.
You can also create an associated model 'transactions' which belong_to the user and to find out transactions that happened on a certain day, you would be able to pull up all of the transactions of that user in a certain time range.
If your credits work similar to dollars and money. And your transactions are like orders, you may want to look into using the Spree gem. https://github.com/spree/spree
You definitely do not want to be reading from the logs to do very usual actions like you're describing.
I am building a rails application for place booking. The app should be able to facilitate bank transfer (not VISA/Mastercard direct payment) for payment. Basically we let users know our bank account number. User can then pay via iBanking / go to ATM or Bank. Nah, when we received the payment, we should know whom this payment comes from and from which booking.
How are we supposed to know whom send it and for which booking it is, while there is no additional data in the transfer information other than amount of money. I heard we can apply a unique cents identifier, like when the payment is $8, we make it $8 2 cents to link it to the user who sends it and the booking data.
Is that the best practice in linking the actual payment data and the booking data? If it is, is there any ruby gem capable for generating the unique cents identifier? Or if not, is there any better approach?
Thank you for your assistance.
Bit vague, but a lot of companies that bill people, and allow the user to pay by bank transfer, require the user to put a specific reference number on the transaction, which ties the transaction back to that user's account.
It needs to be made obvious to the user (and it usually is) that if they fail to put in the right reference number then the payment won't be linked with them, and therefore won't show up as a credit on their account.
This doesn't feel like a particularly satisfactory system, as it puts the onus on the user to get it right or risk being charged extra for late payment, or have a hassle sorting it out. But, lots of successful companies seem to operate like this.
My customer is wanting to consolidate all the of their retail sales in AX under one customer per country.
Currently a new customer is created for each sale unless the customer has previously made a purchase, in which case the customer is reused. One requirement of the functionality being implemented for this is to merge open AR associated with one customer record to another customer.
Could this be handled with a payment journal? If so, any suggestions on how the journal lines should be constructed?
The easiest would be to change the account number in CustTrans and CustTransOpen in a job.
Also consider if ledger dimensions need changes, if so much more is involved.