Orders are a little more complicated. One point of clarity is that a cart and an order are the same thing; the only difference is the value of IsPlaced as well as the order status (StatusCode and StatusName). While you can create an order through inserts and updates to the Order object (and its supporting objects), it's best to use the "Process New Order" workflow to handle converting the cart to an order as well as everything that goes along with processing a new order (e.g. payment processing and sending order confirmation emails).

Before you run the workflow you will want to make sure that all of your data has been saved to the database (i.e. user, order, line item, and payment data). Note that you do not need to calculate the order subtotal, tax, grand total, etc; this should be handled automatically when you call Orders_Order_FindByBvin. So, once you're done saving all of your data you'll want to get a fresh copy of the Order object from the API which will then have everything calculated.

You can run the "Process New Order" workflow by either calling BusinessRules_Workflow_RunByName and passing the workflow name or by calling BusinessRules_Workflow_RunByBvin and passing the workflow bvin (eac003c6-a354-489f-ba2c-029f4311851a). This function takes an OrderTaskContext object which you can instantiate and then set the UserId and Order properties.

Additional related question: What is the best way to get a list of the available shipping rates/methods?

I called Orders_Order_FindAvailableShippingRates and it returned the same rate $ amount I saw on the website (with the same item added to cart) but all other parameters of the shipping rate were null. No shipping method names were available.

That is the correct API call. I just tested this and saw the shipping method name in the DisplayName property. Some of the other properties are null, though.

The itemId parameter that these functions take should be the bvin of the LineItem, not the product.

Hi Arron,

I'm still getting bad results from Orders_Order_FindAvailableShippingRates sometimes. The rates will be provided but everything else will be null (including the display name).

Any suggestions?

It doesn't fail every time but I can't detect a pattern. It fails more often than it works.

This is how I'm creating the order and pulling the shipping methods:

//Create the order
WebServices3.Order order = new WebServices3.Order();
order.Bvin = orderGuid.ToString();
order.User = userAcct;
order.UserID = userAcct.Bvin;
order.UserEmail = userAcct.Email;
order.ShippingAddress = userAcct.ShippingAddress;
order.TimeOfOrder = DateTime.Now;
order.FraudScore = -1;
order.PaymentStatus = WebServices3.OrderPaymentStatus.Unpaid;
order.ShippingStatus = WebServices3.OrderShippingStatus.Unshipped;

//Insert the order
Orders_Order_Insert()

//Refresh the local order
Orders_Order_FindByBvin()

//Add product(s)
Orders_Order_AddItem_ByBvin()

//Refresh the local order
Orders_Order_FindByBvin()

//Get shipping methods
Orders_Order_FindAvailableShippingRates()

I just tried to pull the shipping methods for the orders created when I was testing this a few days ago and it worked correctly.

I haven't altered the orders in any way and I haven't made any changes in how I'm requesting the shipping methods.

I also tested it with a completely new order and it worked correctly.

So the issue isn't consistent. I find it very odd that when it fails, I still get the correct rates but everything else is null.

Is there anything else you can look into?

For credit cards, you'll probably need the following fields:

AmountAuthorized
AmountCharged
AmountRefunded (if it's not 0, which it usually is)

In BV, you can have it set to authorize payments when the user first places the order and capture them later. The only case where AmountAuthorized and AmountCharged will be different is when an order was placed, but not fully processed in BV.

You'll also need all of the CreditCard fields that you mentioned above. The CreditCardType field keeps track of what type of credit card was used (Visa, MasterCard, etc.) It uses a one-character code as follows (M=MasterCard, V=Visa, D=Discover, A=American Express). There are also some other options like JCB, Diner's Club, etc., but I don't remember those ones off the top of my head. Let me know if you need codes for anything other than the 4 major credit cards mentioned above. CreditCardExpMonth is simply an integer between 1 and 12, while creditCardExpYear is the entire year (i.e. 2014, not just 14). Credit card numbers that are stored in BV are automatically encrypted.

OrderID is necessary to connect the payment to a specific order. The PaymentMethodId field also must be filled in--this determines the payment type. There are a number of payment types built into BV, though it is also possible to add custom ones. You can retrieve all of the ID's for available payment methods by calling either Payment_AvailablePayments_EnabledMethods or Payment_AvailablePayments_CollectibleMethods. The difference is that the latter only returns payment methods that are collectible via BV (so, for instance, not purchase orders or phone payments).

AuditDate is automatically initialized to the current date, so you don't need to fill that in.

Here are some of the built in ID's for reference:

7FCC4B3F-6E67-4f58-86B0-25BCCC035A0E Cash
494A61C8-D7E7-457f-B293-4838EF010C32 Check
4A807645-4B9D-43f1-BC07-9F233B4E713C Credit Card
4B0A1BD7-1EE1-4BE0-87B4-E635F96442BF Offline
33eeba60-e5b7-4864-9b57-3f8d614f8301 Paypal Express
26C948F3-22EF-4bcb-9AE9-DEB9839BF4A7 Purchase Order
9FD35C50-CDCB-42ac-9549-14119BECBD0C Telephone
91a205f1-8c1c-4267-bed0-c8e410e7e680 Gift Certificate

For purchase orders, you'll also need to fill in purchaseOrderNumber
For gift certificates, you'll also need to fill in giftCertificateNumber

Edited by user Friday, January 16, 2015 10:55:37 AM(UTC)  | Reason: Not specified

In addition to the questions I posted above a few hours ago, I have another order issue.

I'm trying to add a shipping method to the order. The result comes back true when I add it but when I look at the order it has no shipping method associated with it.

This is how I'm adding the shipping method to the order:
WebServices3.ShippingRate[] shippingRates = ws.Orders_Order_FindAvailableShippingRates(ref token, order);
WebServices3.ShippingRate selectedShippingRate = shippingRates[0]; //Not really 0
bool shippingMethodAdded = ws.Orders_Order_ApplyShippingRate(ref token, order, selectedShippingRate);

Actually, you are correct. These fields will be populated automatically when you call the workflow.



I believe the order will still go through without PaymentMethodName as the code always uses the PaymentMethodId for lookup. However, not specifying the PaymentMethodName may affect what is displayed at certain places in the BV admin, so I'd say it's probably best to include it. The name you should specify

I'll respond to your other posts tomorrow as I have to go now.