I'm building a simple eCommerce application.
I currently have a customer model and need to add a shipping address to this. Question is, should I create a new address model and associate this with my customer or put the address fields on my customer model? It seems like creating 2 models will be more effort as I will then need to update multiple models when my customers enter their details on the front end form.
If your customers will ever need to associate two addresses with their account then create two models. Odds are they will. Billing vs Shipping is the most common, but so is wanting to ship to home vs ship to work, etc.
Related
I am trying to learn domain modeling , now lets consider a shopping cart example.Lets user can browse catalog of products and add products to shopping cart, purchase those products.To purchase products he will place order.User can trace his order details.He can call up customer rep to know about status of his order.
Please validate my Domain model in full scope.
Below is Domain Model i have designed , i am having issues in representing order and order status what is the right way to do
How would i link product and order.
A (conceptual) domain model is a solution-independent description of a problem domain produced in the analysis phase of a software engineering project. It may consist of information models (typically in the form of UML class diagrams), process models (typically in the form of BPMN diagrams), and possibly other types of models.
A domain class model contains only conceptual elements, such as properties (possibly without datatypes) and associations. It does not specify the visibility of properties and methods, as visibility is a platform-specific concept.
Your model is incomplete in many respects (e.g. it does not describe order lines/details, which are taken from the cart), and it does not contain any association. Clearly, an order is associated to one customer and to many items/products (via its order lines).
OrderStatus should be modeled as an enumeration, which is a UML datatype that is stereotyped with <>, and Order should have a status attribute with this enumeration as its range.
The model below may be a bit more general than what you had in mind, because it allows for several warehouses from which an order item can be sourced, and it also distinguishes between private and corporate customers.
You can make "order details" an associative class for the relationship between order and product. See the example:
IBM example of an associative class
Note that yours is really a class diagram. A domain diagram shows the dependencies on different problem domains such as
Order fullfillment
Database
RemoteCommunications
SystemMaintenance
etc.
I am new to openerp I came across res.partner but I couldn't understand what it does and what all functionalities it provides,so if anyone could explain it to me I would be grateful.
To clarify.
res.partner is an ORM Model. An ORM model describes a class of objects in the database and provides a series of ORM methods to allow you to manage them in code (create, write, unlink etc).
To get the database table, unless there is a specific _table override, just convert the periods to underscores so the table in the database is res_partner. As with any "res." model, you get res.partner as part of the core of OpenERP rather than any additional model such as accounting or sales.
But to answer a wider question, what is res.partner for in OpenERP? Assuming OpenERP 7, res.partner contains information about any entities you have a relationship with.
This includes:
Customers - you have a res.partner entry for each customer plus a res.partner entry for each contact person or address (invoice to, deliver to) you set up for that customer.
Suppliers - same as customers. In fact, the only difference between the two is a boolean field on res.partner to say if they are a customer or supplier.
Users - each user allowed to log in to your OpenERP instance has a related res.partner to store address details.
Companies - each company you set up in OpenERP assuming you are using multi-company has a related res.parter to store address details.
res.partner is the technical name for the Model representing Partners:
Partners represent People and Organizations.
The most straightforward example are Customers and Suppliers.
Other examples of Partners are:
Contact persons within an organization
Customer or Supplier Adresses
Employees personal contact data
Users contact data
So it's a base concept used pretty much everywhere in the application.
We have an app which is exposing a RESTful API to a UI for purchasing an item. I have a question regarding API design. Lets say the following action should be taken in order
Item to be chosen for purchase
Next give the address to be delivered to
My question is: should we design a single API which gets both data perform both? Or should we design two API calls - one that creates a purchase record and second that update the address to be delivered to?
The recommended SOA approach is to choose coarse-grained services, which would seem to argue the minimum amount of API calls.
However, from a business point of view, item selection and purchase and item delivery are two very different concerns that should be separate components in your architecture. For item selection, you need to consider things like inventory and pricing. For delivery address, you need to consider user address lists, address validation, shipping, and taxation.
Those two components are not likely to interact much except maybe some external association between an item id and address id. For this reason, I'd recommend two API calls. Functionally, this would also allow your API users do things like update the delivery address without re-purchasing an item, send the bill to one address and the item to another address, etc.
As you state that you design a RESTful API you usually start by designing resources instead of the intended calls. Later on, resource representations can be chosen that include other resources for optimised HTTP request counts.
You might want to choose to proceed the following way:
Model the item list resource (GET - lists all items, POST - allows item creation) /items/
Model the address list resource /addresses/
Model the item instance resource /items/item/resourceId
Model the address instance resource /addresses/address/resourceId
Now all of your resources are available you can think about usage patterns. All your resources are generically available and can be mashed up.
Possible approaches to answer your questions would be:
Extend the item instance resource with the needed address details (coarse grained as lreeder stated)
Model a resource /deliverydetails/ as list and instance resource containing item(s) and address, make the deliverydetails to be queried by item id or whatever your use case fits best
Hope that helps!
Btw. you are automatically following SOA approaches with a Resource Oriented Design. Interfaces will be naturally fitting your business requirements and generic enough to support more advanced use cases.
Here is a good example
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 working on a store that has two types of products: perishable food and general merchandise. The food must always be shipped overnight via FedEx, and the other merchandise must always be shipped via USPS. If somebody orders products from both categories, they must be shipped separately.
Do you know of an existing module or configuration settings that would allow for this?
If not, it sounds like a custom module would be the other solution. In this case, what is the best approach? I'm thinking it would be splitting the order into a multi-address shipment, using the same address for both but with different shipping methods. Unfortunately I'm not sure how to do this programatically, so any tutorials/samples/resources would be greatly appreciated.
Probably the sanest way to handle this would be to create two orders per product type, each shipping with a different carrier to the same address. This also IMO makes more sense from a stores tracking perspective as you can handle each independently from each other.
To get you on the right track(since Magento is especially cryptic in this part of itself) you should read the Inchoo programmatically create order in Magento post and by the same author Programatically create customer and order in Magento with full blown one page checkout.
Basically as I see this going is:
Get the customer order
Itinerate through each product inside the order and split it up in two arrays for each product type
Create a separate order for each product type and use the different shipping methods for each.
You will probably have to extend a some controllers OR do it the non-standard way and use helper functions for this, the hard parts will be integrating the payment/shipping modules inside your order process. Going this way will have you creating the full checkout process as the one page checkout Magento provides won't really work and is too much pain to get to work because of the way it uses AJAX.
Also another alternative is to hook in to Magento's pre-create order events and create the orders there using already defined order data split it up in two orders, but this is something I never heard or saw implemented at the moment so you'd have to do it "blindfolded" so to speak.
An easier approach would be to use a custom field that defines your product's shipping method, this way you just add that and don't care about custom orders. You just react with that, however tracking will become mostly impossible IMO.
Over-ride the Free Shipping module.
You can setup a sales rule that applies to certain products and makes them 'Free Shipping', leaving the other products to your chosen main shipment provider.
You will need to see how this works, however, the point is that Magento does have something built in to split an order into two shipping categories, albeit only a sales rule on free shipping. But you have source code...