I have a partner A with different branches (A, branch1) , (A, branch2) in OpenERP 6.1
Do I need to create a separate partner for all branches and then point their parent partner field accordingly or am I missing something ?
Thanks.
The question is, do you deal directly with each of the branches (sales orders, invoices, etc.) ?
If you do , you should open a Partner for each branch, so you can relate
each document with the corresponding Partner's Branch.
If not, the
you are dealing with a partner having with several branches, and it
will suffice to have a Partner with several Contact addresses.
I would suggest ask the branches if they have separate bank accounts. If so then you should create a separate partner account otherwise make one partner account and find a way to put different branch accounts into that.
Related
In my Sylius shop, I would like to make some products available only for my website premium users.
I managed to set up a promotion rule for premium users, according to the documentation : How to add a custom promotion rule?
My problem is that I can't figure out how to create a promotion action, making selected products available only to premium users. And these products need also to be seen by standard customers.
Is a promotion action a good way to achieve this purpose ?
I don't know if promotions are the best you can use in this feature. There is no discount/profit for the customer, it's just a limitation of product for specific customer group. I would solve this with two simple steps:
Add $premium flag on Product entity.
Implement a listener (or even better - a validator) that would check the currently logged in customer groups and if there is no premium, then break adding product to cart and display proper message.
Of course, you could create a promotion action that would remove products from cart that customer can't buy, but let's be honest, it'd be ridiculous ;)
Let me know if it's clear or you need any more help with that!
I'm updating my code to use balanced api 1.1 and I'm interested in the new Orders construct. Everything looks pretty good about it, since our orders are only associated with one merchant customer. We charge an inclusive fee on the order and don't want to make 2 charges to the customer, which leads to my question:
If I create a single order, with one buyer, one seller, and one debit, can I credit both the seller's account, and my business account?
In other words, after debiting the buyer the full amount (let's say $100) and crediting the seller with their portion (let's say $95) will the remaining $5 be 'stuck' or will I be able to transfer that into the business's account (my business)?
Yes, an Order can technically have two merchants associated to it. The one specified when you create it and the owner_customer from your marketplace.
The documentation appears to be lacking anything referring to this so I've created a Github issue to track documenting how to collect fees with Orders!
A client of mine has a service-oriented ecommerce site on Shopify and he's asked me to assist in making a few changes. I've never utilized the service so I'm not really familiar with it.
The price list was static at first since the client used the same vendor however now that they're growing - and therefore using multiple vendors - the costs are fluctuating and therefore the prices on Shopify need to reflect that.
I need to set it up so that when a customer logs on a vendor is programmatically chosen based on their geographic location and the prices (shown to the customer) adjust accordingly.
Is this possible? And if so, what objects/API docs should I be looking at. I seems as if I can easily hard code this with IF statements but I'd like this to scale cleanly so I'm looking for a more efficient solution.
I think this should be possible. Based on your comment:
Will I not have a zip code for the customer? – RyanMac
The easiest way would be to create a Product Variant for each region. Based on the customer.default_address you could find the customers ZIP code. Next step would be to use this within the product.liquid template to select the correct variant.
The biggest problem you have is determining their location. When a customer logs in, you know who they are, so you could dish out only products of interest to them. Problem is, how do you lump people into those regions? You have your work cut out there. When you create a customer you can assign them any code you want, so perhaps you could just match customers to vendors using a match on that. Lump any customers into GroupA and you show only products with Vendor GroupA, any customers assigned to GroupB render products from vendor GroupB....etc
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