Is it a bad practice to use Commerce API instead o...
# suitecommerce
v
Is it a bad practice to use Commerce API instead of the BackendCartComponent from Extensibility API? (for SC 2019.2.4 extensions)
s
Not necessarily.
v
Thanks for the response @Steve Goldberg I'm struggling to implement a solution where we do not want to show the Invoice payment option to our users in the regular web store checkout flow, but want to enable it when they checkout via our extension (by setting paymentterms as 'Invoice' - through Commerce API). When I set Invoice payments to be enabled via Web Site setup (checkout preferences), it enables it for the entire web store. And I understand it is tied to Commerce API as well. Do you think it is a bad idea to simply process Sales Orders using SuiteScript 1.0 via an extension instead of using Commerce API/extensibility API? I don't want to follow bad practices in my extension code hence I was sticking to Commerce API (and trying to explore a bit about Backend Extensibility API)
Also, does that impact performance?
s
Sorry, I'm not really in a position to give advice on that
v
No problem Steve, I will figure it out. 🙂 Thanks.
p
Submitting orders via suitescript as a replacement of via commerce api is definitely slower, doesn't run your scriptable carts (so that might also mean consistency errors/need to duplicate logic, depending on your setup) and also has problem with calculation of shipping rates. In my opinion it works great but for a small and isolated set of use cases, orrrr if you get creative and set everything in commerce api and clone it at last second, but never tested this route. Hiding invoice payment via extensions (or something 'not 100% extensibility layer but almost') looks simpler IMHO. This thinking of SCA, if you're thinking self-updating SC well that might be sliiiighlty more risky.
v
That's quite insightful @PabloZ I never thought about the scriptable carts (that is definitely important in our case). We are using SC and not SCA, so we do have some restrictions when it comes to customizations (and yes, also an increased amount of risk). I will discuss with my colleagues about this. Your information definitely helps. Thank you. :)
a
@Viraj Shinde I think the better approach here might be to leave pay by invoice as on and use that native functionality and selectively hide it based on customer?
v
@Anthony OConnor you're right, that would be the ideal way. Hiding it selectively per customer would mean setting the 'Terms' on the Customer record to blank right?
a
If that works in your account then that's a very simple fix so for sure I would use that. 🙂