I hope below question is very generic but seeking some expert advice to work on RMA process.
Generation of new sales order for replacements & refunding the customer the specified amount, generating item receipt to track items being returned prior to refunding customer.
eg:
Looking for sample suite script reference to refund back to customer's credit card $XXX (product amount paid + original shipping) for a given sales order.
-Bhasker
You will want to look into SuiteScript 1.0's nlapiTransformRecord or SuiteScript 2.0's N/record/transform. You should be able to transform a Sales Order into a Return Authorization with this API.
If you can give quite a bit more detail about what type of script you're looking for, what triggers you'd like to be able to use to set off this script, I can give a more detailed answer.
Related
I'm using Stripe Checkout to create a subscription in Stripe Billing. Checkout also auto creates the Stripe customer object.
How can I add right right VAT rate based on where the customer is based? The customer should be able to see the price both including and excluding VAT/GST both in the checkout session itself and on the invoice.
The "create subscription" API call allows you to set the field "default_tax_rates" which sounds like what I need, but the problem is that with Stripe Checkout the subscription (and the customer object) are created automatically by Stripe Checkout so I cannot explicitly pass parameters to these creation calls.
I know how to calculate the VAT rate and I don't want to integrate with another third party vendor just for tax, so I'm not looking for something like Quaderno or Taxamo.
How do people solve this problem? I'm starting to think that maybe I should have integrated with Chargebee instead of Stripe :-(
I'm having that same issue.
Stripe support informed me that Checkout does not support the legacy tax percentage or the new Tax Rates object.
Checkout charges only the exact amount.
On recommendation from stripe I will calculate the tax and charge that as a separate line item.
That way the correct amount is charged and the VAT is clearly visible to the customer.
I'm also creating subscriptions and there I will show the amount incl. VAT. and post fix the plan name with 'incl. VAT' to make it clear to the customer.
After the checkout flow completes I will try to add the Tax Rate to the invoice and subscription as 'Inclusive' using the API. I'm not sure that will work as I think, but we will see.
Check this out https://stripe.com/docs/payments/checkout/taxes
Seems like you're right about the Stripe checkout. Can't be added there.
Adding VAT as Inclusive won't help you, because Inclusive means it's already calculated into the price. Although this can be used to add the VAT to the price (in most cases it's 20%) and set the VAT as Inclusive. But this hack won't work for everybody, though.
I found this to be helpful and it works with Checkout.
https://dominik.sumer.dev/blog/stripe-checkout-eu-vat
You collect the Country and VAT number before creating the customer and checkout, and you add dynamic tax rates prepared via the API in advance.
I am trying to refactor a legacy order handling and stock system with into a cleaner service oriented event-driven architecture. However, I am having some difficulty deciding what service should be responsible for the reservation/allocation of stock.
A brief overview of the current system
Sales orders are placed with us via third party system but we do not necessarily have all order lines in stock.
If an order item is in stock then we allocate/reserve the stock for that order straight away.
However, if we do not have enough stock then we procure the stock from our suppliers via a purchasing system.
When the item arrives from the supplier, the system will search through all open sales orders for the item and reserve/allocate the available stock to them, prioritising by sales order date. ***
I have already identified two services that I think need to be developed
Sales - Responsible for receiving the sales order and inserting into the database. Has domain entities such as Order, OrderLine etc.
Inventory - Responsible for keeping track of how much stock is available in our warehouse. Has domain entities such as StockItem.
However, as the allocation/reservation of stock concerns both inventory and sales I am not sure where the behaviour in point 2 above should be put.
I welcome any help or thoughts on this.
I think you have 2 BCs (bounded contexts): Inventory and Sales. For the integration between them I would probably go for domain events approach.
When a new item arrives at the warehouse, the Inventory BC increments the stock for the item, and publish an event.
Sales BC subscribes to the event, and it updates the opened sales that are waiting for the stock item.
So, behaviour of "point 2" are shared by both BC:
Sales BC search for opened orders waiting for that item. And then it asks Inventory BC to get the number of items it needs (this request is synchronous) and close the order.
Inventory BC receives the request and decrements the stock for the item.
However, as the allocation/reservation of stock concerns both inventory and sales I am not sure where the behaviour in point 2 above should be put.
I've been thinking about this problem (purely academically), and my current conclusion is that reservation management belongs with the inventory system. That keeps the stock source (the loading of items procured from your suppliers) and the stock sink (fulfillment of orders) together.
So the inventory system caches its own copy of the data required to fill the order (allowing it to work autonomously). It should be able to make progress as soon as it is informed that the suppliers have provided new inventory, even if the sales system happens to be down for maintenance.
You mentioned SOA and NServiceBus, so my initial thought was that you've attended Udi Dahan his ADSD training? I'll assume you have. With that, I'll try to answer your question.
So far I don't have a lot of information. But with what we have, I figured we need these properties to store all that you mentioned.
ProductId, one for each available product
InventoryTotal, attached to a ProductId. This number goes up and down
OrderId, to create an order
OrderDate, to make sure we can find the order that should receive incoming stock first.
If you have an OrderId, you can attach one or more ProductId to create an actual order. Different ways of storing this technically. Maybe in a relational database with Order and OrderLine tables, or possibly in a DocumentDb where everything is stored in a single document. That's totally irrelevant at this point.
Assuming we need 4 attributes, I'm not sure why we would create more than 1 service to split this up? This might change when we have more information, but at this moment I don't see the need.
If you want to discuss this, contact us at support#particular.net, mention my name and we can continue the conversation.
You are talking about loosely coupled domain apps, managing your sales orders, managing your inventory and managing your purchase orders.
Inventory must always be up to date, in order to not sell what you can't deliver. So PO en SO app should both talk to inventory via synchronous (inventory) services. To keep everything consistent, events on purchasing side, like receiving less than you expected for a PO, will have an impact on any SO already assigning quantity of that PO, as persisted in inventory. So the same PO pcs for example, in which the event of receiving less as expected, is registered, should synchronously update inventory, to update the quantity available for SOs to assign from, and publish an event, to be picked up, asynchronously, in the So app, so that the user can be notified and talk relevant action. Etc.
We want to map a customer's response to one of our actionable tasks.
Example 1 -
Customer: When will my vehicle be picked up?
System: Customer is asking for pickup date, so provide one.
Example 2 -
Customer: I don’t have title.
System: Customer has title issue. Create a task for support team to help him.
You can take a look at some APIs that will translate statements like that into intents. A great one I've worked with before is Nuance's mix.nlu which can be found here:
https://developer.nuance.com/public/index.php?task=mix
how to get available item quantity in picking ticket form in netsuite?
Thanks,
Shachi
You may want to try using item.onhand as well if you are talking about total inventory available or location.onhand if you are talking about shipping from a certain location.
You would probably be best off using the item.locationquantityavailable.
The difference in available vs. on hand is:
On hand is inventory that has yet to be shipped, but includes inventory in a picked fulfillment status, which may be allocated to other orders.
Available is inventory that is not allocated to other orders and not currently in a stage of fulfillment.
If you're using the advanced form, view source code and add element item.locationquantityavailable#label
Do I have to do this server side with a custom payment button instead of their (beautiful) default one? Or can I just do some logic with the javascript (price*amount) or will it not work with their custom token thingy they generate? I'm using their Java api with Google Appengine, if that makes a difference.
To add to the other posts, here's a concrete example of how I'm doing it.
On the 'pay now' page with the default button, pass in the amount. One way I'm doing this is from a form on a previous page.
Parse this amount, e.g.
<?php
...
$data_amount = $_POST['data_amount'];
...
?>
And then use this amount as a value in the JS script which actually process the charge
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
...
data-amount="<?php echo $data_amount; ?>"
...
</script>
Good luck!
The quantity and any other information about the items being purchased are irrelevant to the payment gateway, in this case, stripe. All that matters is the payment method (e.g. "visa card ending in 1234"), the amount, the currency and the customer.
You don't have to use the stripe provided checkout methods, you can write your own. The stripe examples are extensive and include Java code, though really the concepts are harder than the code itself (and the concepts aren't that hard). The token represents the payment method/customer and has nothing to do with the amount being charged.
You can do whatever you like to implement the product / quantity / price calculations. The Stripe API simply expects your server-side to make a "charge" passing the card (or customer) token, and supplying an amount and a currency. (There are a bunch of optional parameters too ...)
The "token thingy" does not contain an information about the payment itself.
I've not attempted to use Stripe myself. The above is based on a cursory (10 minute) reading of the documentation. But there are copious examples that you can find via the Stripe "Documentation" menu, including (Java) examples of what you need to do on the server side.
As the other folks have mentioned, the token doesn't contain quantity/charge amount info. The charge amount goes into the charge object.
Now, as far as additional info, particularly if you're coming from the classic PayPal world where you have quantities and so forth, or even if not but your purpose requires the back-end to know the extra detail, most (but not all) Stripe objects allow you to store key-value pairs in the optional 'metadata'.
If you're rolling up a cost (particularly if you're doing tax or other computations to get the total) you'll probably want to stuff the essentials (quantity, unit price, tax, itemized list, etc) into that block to be able to sanity-check and/or extract the details later on in the processing flow.
The Stripe docs are quite well done; click 'Java' at the top of the example column and you'll get cut-and-paste examples (for the most part).