I'm new to Shopify and I'm looking for some guidance.
I have a customer who has a warehouse in the US and a warehouse in Europe. They have a Shopify store for US customers, with a shipping from address set to the warehouse in the US.
They do not have a store for European customers.
What they would like to do, which I'm not sure is possible... Is keep the current US store, and add the ability to ship to Europe. This would require adding prices in Euros, for each product, and adding a second Shipping from address, which does not seem to be an option.
Does anyone have any experience with this, and can provide some guidance on any of these points?
I'd agree with what David said. It is easier and less-tax-hassle free two maintain the store on two domains.
But I can see why you require a multi-currency store. Fortunately, Shopify does have provision to at least display the product prices and offer a toggle switch for the users.
Refer to the following Shopify docs:
Show multiple currencies in a drop-down list on your storefront
Add a button to your online store to enable toggling between two currencies
To do that, you would have to show prices in Euros, but all money would be collected as USD. Not ideal. Plus EU usually has taxes in, US, not. Shipping is easy in that you can control where things get dropshipped from.
It is simpler to just open two shops. One for Euroland, and one for the US Shops are cheap compared to the sweat you'll put in trying to make one store do it all.
We process orders for multiple sellers (a typical "marketplace" scenario). Are there APIs or services that correctly compute sales tax for our use case?
I simply want to provide the sellers' (1 or more) locations and the buyer's location, and receive the correct tax rate to assess on the corresponding line item.
Most offerings I've evaluated (TaxCloud is one) seem to fall down in this use case.
I'm implementing a TaxCloud solution for a single-seller and multiple-buyer situation. You can utilize TaxCloud to determine tax cost by creating an account for each seller in the marketplace, configuring nexus for each, then using the appropriate API key/ID pair to lookup tax on items based on the seller.
Unfortunately, this means that you'll have to make multiple calls if the shopping cart has items from multiple sellers.
I'm having a hard time figuring out if Recurly supports a "products as a service" kind of business.
"Products as a service" has following characteristics:
No monthly fee
No charge upfront
Just charge the products itself
A subscription can have different products and different amounts
per product for each customer
The products or (amount of them) can change montly
For example:
A costumer can choose out of products A, B, C and D. He chooses to subscribe to our service and wants a montly delivery of a pack containing product A and 2 of product B.
After three months receiving this subscriptiopn he wants to change his pack. He deletes product A out of his pack and adds product C. The next delivery contains those products.
As far as I understand the API I have the following options:
Create a different subscription per user per "pack"
Seems too
complicated for managing all subscriptions. There will be many
subscriptions created and deleted (set on inactive, as deleting is
not possible). And it certainly isn't intended to be used this way.
Subscription plan of €0,00 with add-ons per product
Add-ons seem to be defined rather fixed when creating the subscription plan. I want my products to be flexible, taking them in and out of the subscription as I please. Doesn't seem to support that.
Metered billing
Also defined as usage-based billing. The proposed use cases in the docs all have a fixed subscription fee (which I don't want). They also add a defined and linear 'product' (eg. 0,1 / minute). Doesn't seem to fit my needs either.
How can I handle this kind of business best with Recurly?
A €0,00 with add-ons per product will be your best path forward. Add-ons are flexible and can be added/removed from a subscription plan as needed.
I've been researching eCommerce payment gateways and service offerings, but I'm an eCommerce novice, so please excuse my ignorance.
I wish to set up an eCommerce solution with the following requirements:
User "subscribes" to the service on a yearly basis. This service includes a single product subscription for a set amount (let's say $50/yr).
User can "subscribe" to additional product services for a lesser rate per year (let's say $25/yr).
I will need to store a product service unique Id of some sort for each product subscription the user subscribes to in order to show them product unique information. I also need to prevent duplicates...for example, user can subscribe to product ABC and XYZ, but not 2 of ABC.
Is PayPal the best solution for something like this? Is there a better solution? Any assistance is greatly appreciated, even if just links to specific tutorials or examples.
Update: It looks like Chargify could be the perfect solution.
You can also use Authorize.Net's CIM solution which, based on what I read at the chargify website, does most of what chargify does except your customers never need to leave your website. The Customer Information Manager allows you to create profiles for your members. These profiles store sensitive information like credit card numbers and billing information so you don't have to worry about PCI compliance or hackers stealing your information. You then can schedule a cron job to charge them monthly for whatever amount they owe based on their current subscription. Since you control when the payments happen it also allows you to charge them pro-rated amounts for subscription changes mid-month.
[link text][1] seems to be the best solution for me. I still need a merchant account, but this takes a lot of the headache out of handling the subscriptions.
[1]: http://chargify.com Chargify
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm building a simple accounting app to be used for personal finance.
A user might keep track of purchases, upcoming bills, recurring deposits, etc. It will be verrrrry simple.
Two questions:
1) Any advice I should keep in mind? Obviously, I'll use transactions where appropriate, but proper datatypes and other considerations would be nice to know about.
2) Are there any APIs you know of I could use to periodically get a user's balance from their bank? i.e., an API that would make it simple to query their account, regardless of whether they're at Chase, BofA or other?
Thanks very much,
Michael
Having just completed version 1.0 of some custom written online accounting software for school related non-profits I have some advice :)
Use standard double entry accounting/bookkeeping (debits and credits) as the basis for your financial engine. You will find this will serve you well when it comes to not only storing data on transactions but also generating reports. Assets = Liabilies + Equity is a tried and true approach for tracking who owns what.
Use decimal types for money.
Use transactions.
Keep the interface as simple as
possible.
You will need to have a method to
allow the user to reconcile the bank
records with their own records.
Pulling in bank data would help this
process but you will need to provide
the user with a method to compare.
You can use bank statements for this
process.
The bank is always considered to be right.
If there is a discrepancy between
the bank and the user records... the
fault almost always is with the user
records.
Make sure you provide some sort of
backup facility for the user
Secure the users data
Make sure you fully understand the process you are automating. Do not make assumptions. Run your ideas by an accountant who specializes in personal finance. Having this vetting will help quite a bit.
Be prepared to write ALOT of code. Accounting software has been around for years, the list of "standard features" for a typical accounting package has grown, and there are quite a few players in the market. If you are planning on selling this product you will need to provide those standard features and then find some way of differentiating it from what is already available with additional features.
TEST TEST TEST and TEST again. You
are keeping records of peoples
personal financial transactions
(their money). Errors are not taken
lightly.
I will add a few tips as I am finishing a POS system that focuses on ACCOUNTING - meaning the purchases, expenses, invoicing, accounts, credit cards, cash, vehicles, etc all need to be tracked. The concepts will eventually be applied to a personal system.
The best advice is to look at your paperwork and try to form your database around what you need to do to translate your physical documents to the computer. Combine this with the first couple of chapters of an accounting textbook which talks about accounts, chart of accounts, and journals.
The books I used :
Accounting at your fingertips by George Murray
Finance and Accounting for Entrepenuers by Suzanne Caplan
Introduction To Accounting by Ainsworth
Accounting, Information technology, and Business Solutions By Hollander
Once you have your source documents entered into the system you can then run queries to get to your answers. Doing this eliminated the concept of the "General Ledger" and "trial balance" because you simply correct or add to your source documents. So the "General Ledger" becomes a calculation. That was super confusing to me. Again, all the source documents will be put into 'Journals', which can be your database tables. I use a general journal, a purchases journal, a payments or cash disbursements journal, a sales journal, and a cash receipts journal. Keep in mind the term "CASH" refers to cash, credit, check, debit.
For example I have a "general journal" which is basically what you need. In this journal I keep track of 'source receipts'. A receipt might be an invoice, like time warner cable, which has an account number. In that case I create an 'account' for time warner. The time warner account will link to a 'chart of accounts' which will specify the type of expense as "internet". The invoice then gets entered with the date, the amount, etc. The invoice links to the account for time warner. Once the invoice is entered it is unpaid. You then need to add payment. Of course you could pay the bill in full as you should, but you might need to do two payments, or split payments, or not pay in full. This will lead you to a 'Payments Journal" in combination with a 'invoice to payments lookup table' which will need to have an applied amount to apply to an invoice. This applied amount is important because you might have 4 unpaid time warner bills and you just send over $200 in a panic to get your account back on. This payment then needs to split across the invoices with amounts to apply to each. And of course the payment account will link back to your accounts.
For the case of entering a receipt, the account is not used. Say you pick up some lingerie at embrasse-moi, and pay cash. Your system will take the supplier, embrasse-moi, the date, the cost, I added a 'use tax' in case you purchase over the internet and did not pay tax but you still owe it, the amount, and the 'Chart of accounts' which is essentially what category is your expense. That all goes to the general journal. On the same form you will have the payment method. I made a simplified form for an expense + exact payment as that is very common. If the payment is split then you will need to enter the receipt using one form, then create multiple payments linking to that receipt with other forms.
So in the end your database for this simple accounting app will have the following tables:
Accounts (the account information including an account type like cc/debit card, checking, cash, inventory account for business purchases, expense account like utilities, the default chart of account)
Chart of accounts (basically a list describing how to classify expenses and accounts which will flow to your operating statement, i put mine here for you to check out:
http://embrasse-moi.com/exampleData/pos_chart_of_accounts.csv)
I have a table for opening balances for accounts, because you have to start somewhere
Account type - meaning credit card, debit card, etc. Keep in mind the accounting equation basicaly switches based on the account. Checking accounts debits are "bad" because you gave away your money and credits are "good" because you took in money while credit cards debits are "good" because you reduced your debt and credits are "bad" becasue you added to your debt
Chart of account types, which is an 'asset, liability, long term asset, etc. This could be included in the cart of accounts as an Enum type
Then there is the general journal, which as described contains enough information to describe your document. Is it on account? Date, amount, the type (receipt or invoice) due date, i keep a 'paid' flag to ease the querying.
Then you have a lookup between the 'general journal' table and the payment table
Then you have the payment table.
Once you have all this information in, you will almost never use your bank as sources, as they are not always correct, at least my bank makes mistakes. So this type of structure will keep you on top of your information, and at the end of the month this system will produce a statement that looks identical to your account statements. And that is the goal.
About APIs for getting info from your bank: not simple, if at all possible. You can imagine the lengths your bank will go through to make sure everything is secured. I don't think it'll be possible to automatically connect.
Usually there's a way to download data through manual downloading of a file, after you logged into your online banking (if you have that available). Hopefully it'll be in CSV format or something similar ;-)
[edit]
Apparently I was wrong here, major banks DO allow direct connection. I guess you'll have to consult your bank techsupport on that then.
[/edit]
As for datatypes to use, I'd at least recommend decimals for money values, instead of doubles/floats. see this SO question thread about that too.