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.
Related
Does anyone have experience implementing multiple subscriptions model for an app? I wasn't able to find proper documentation about this topic. The most common way to create in-app subscription model is one-subscription per one-user. But I want to offer one-subscription per one-item(in my app). This means that users can create multiple subscriptions if they want to subscribe to multiple items. Each item is functionally the same.
For example, If the app is a pet location tracker and wants to track both pet A and B, the user has to subscribe to each A and B respectively. It means a total of 2 subscriptions.
Please explain it to me.
Thanks.
Never thought about such a use case, but for iOS you can create multiple subscriptions. So you could create a subscription PetA, PetB, PetC and so on. But, I think you asked for a more dynamic approach where you create a Pet subscription and the user can buy as much as he likes. As far as I know this isn't possible.
A different approach would be to create a subscription hierarchy: onePet, twoPets, threePets and so one. Your user can then up or down grade between those subs depending on how many pets he wants to track. Could get messy if you also want to offer different durations.
A third approach could be to use consumable IAPs. These can be purchased as often as the user likes, but have the disadvantage that you need to keep track of the validity period on your own and they can't be synced automatically between multiple devices.
For your pet example I would go for the second approach and offer a onePet, twoPet, threePet and a unlimitPet subscription. This is the most maintainable approach as long as you do not offer endless duration variations. Also this gets synced automatically with all devices of the user and if you like you can also support family sharing.
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.
This is a general question about good schema design. In my case I'm using Rails 4 and PostgreSQL.
Let's say I have a storefront, with many products. The store also has many orders, each with many products.
On Monday, a customer pays for an order. So now, we have a product that belongs to both a storefront and an order.
On Tuesday, the store decides to change the price of one of the products.
Clearly, I don't want to change the record of what the customer purchased on Monday, so this leads me to believe I should store two copies of the product - one copy of what the store is selling now (ie Tuesday), another copy for what the customer bought on Monday.
However, I know that duplicating data like this something generally to be avoided.
Is there a best-practice for handling a situation like this?
That only sounds like duplication because you're using the same name for them. One price is the price the customer paid. The other is the price a product is currently sold at. They're separate pieces of data, even though in a lot of the cases they have the same value. I'd just give them separate names (e.g. Order#paid v. Product#price), and store the Product#price in Order#paid at the time of the sale. That way the product price can be change however needed without affecting the order.
As an example, lets say I have 4 models: Product, Order, Customer, Store
When an order is placed by a customer in a store, the store's owner would get an email asking to confirm the UPC code on the product. Once confirmed, the customer would get an email with a code that when they enter it into their portal, it activates the product.
There is a lot of logic here, which spans several models. For example, when the order is completed, it creates a new inactive product with a confirmation key. The store owner accesses this product by its confirmation key and adds the upc information to it. Only then, once the product has upc information can the customer confirm it.
TL;DR - My question is, what is the best way to group a large process, which involves many models, into a central location? Instead of accessing several other models from within one model, it would make more sense to have it centralized. Is there a best-practice for this type of logic?
This case is typically going to result in a "Service Object" that would be placed in /lib.
This allows for testing the workflow in isolation and doesn't fatten up models unnecessarily.
You can find a good intro to Service Objects here:
https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services
http://multithreaded.stitchfix.com/blog/2015/06/02/anatomy-of-service-objects-in-rails/
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.