Jump to content

codym

Members
  • Content Count

    21
  • Joined

  • Last visited

  1. I don't see a custom edit to the Blesta installation happening. Too much of a headache... especially when we upgrade in the future. You're totally right. The easiest way on dev side would be to fix the encoding on ServiceChanges::getPresenter(), since that should return everything needed so that I can manually create an invoice for a service upgrade/downgrade. The easiest thing for the customer (me) would be for Services::edit() to automatically create a prorated invoice for the change. However, you said previously that is a purposeful design consideration. Possibly for admin functions? I'm not sure. If that's the case, then having an endpoint we can hit that returns the prorated differences according to line item (in JSON encoding) would be the most helpful. In that case, I could easily create a manual invoice from that using the Invoices::add() endpoint. However, (as I haven't gotten this far in testing yet) I'm not sure if the subsequent recurring invoice (1 month after the edit) would include the service update (assuming the Services::edit() function is used to change the service). Again, that would all require testing and I'm not quite as experienced with this system as you.
  2. I see why ServiceChanges::getItems() endpoint was deprecated... it sucks. I can't really use it at all to calculate the prorated charges for a service change and create an invoice unless I write a bunch of regex to match descriptions for each possible configurable option. I'm not sure why this endpoint doesn't return actual line items with corresponding config options, must have been in use to have service changes in a pretty format for Blesta invoices huh?
  3. @Jono Thanks for looking into it. Is there any way we can get a hotfix pushed that allows that endpoint to be JSON encoded? Otherwise we can't interface with that endpoint as it will return a PHP serialized object.
  4. @Jono I've upgraded to the newest release and am still receiving the same behavior with the getPresenter endpoint
  5. @Jono any response regarding this?
  6. Here is a 'GET SERVICE' for the service ID I used in the getPresenter function: and here is the response from getPresenter using that ID:
  7. So I think I found what you're talking about, which is app/controllers/admin_clients.php::editService. This function, when editing a service, uses the service_changes::getPresenter function to retrieve the prorated invoice details to generate an invoice for the service. So, the entire question circles back around to my reply right before your first reply where I am attempting to use the service_changes::getPresenter function to get prorated line items for an upgrade/downgrade to a service to manually create the invoice. I am receiving a 200 OK but empty response from that function, just as in that reply.
  8. What is the name of the function I should look at? I'm on 4.4.1
  9. Jono, So, there is weird behavior with the Services::edit endpoint. When editing a service, all configurable option data and field data that is not included in the edit is deleted. Is this intended? As well, a prorated invoice is not generated for the service.
  10. Thanks for the reply Jono! I think Services::edit would do what I want.... I'll play around with it and see what happens. I did some initial testing with it but it wasn't generating the prorated invoice for me. I'll get back to you on that.
  11. I have made some progress by reading through the app/controllers/client_services.php file. I see that Blesta is using various private functions to pull together the data it needs to GET the endpoint service_changes/getPresenter. This endpoint is what is providing the array of 'difference' data to create the invoice needed for the service change endpoint. However, once again documentation is sparse regarding this endpoint. I can successfully post to it and get a 200 OK, but the response is just an empty object. Assuming the service has no custom fields, this is what the post should look like and which gives me a 200 OK: The following values were pulled from the services/get endpoint with the service_id of '9', which is referred to as 'service': vars[pricing_id] = service.package_pricing.id vars[qty] = service.qty vars[configoptions][5] = service.options[option_id].qty vars[configoptions][6] = service.options[option_id].qty vars[configoptions][7] = service.options[option_id].qty vars[configoptions][9] = service.options[option_id].qty These are the only 4 configoptions which are available to this package and are all the correct IDs and within their defined ranges. This is confirmed by using the package_options/getAllByPackageId endpoint, just as Blesta has done under the Review() function of the app/controllers/client_services.php file. Finally, vars[use_module] = true in the screenshot below as that is set in the Review() function of the blesta code, however is not mentioned in the documentation. With or without this variable still gives me a 200 OK empty response.
  12. Since this post I've also tried: supplying the next available invoice_id without an invoice attached supplying the last invoice issued for the target service Both of which also gave an 'Invalid invoice ID.' error. I assume that I somehow need to manually create an invoice with the prorated data and the new options prorated as well?
  13. Hello everyone, I have a service with multiple configurable options. These configurable options are range-bound quantities. The client should be able to edit the quantities of these configurable options per-service. I am able to complete this task in the portal just fine and everything works as it should on both admin and client-side. I am trying to reproduce this behavior programmatically via the API but am running into some issues. Specifically, there are three variables which must be defined on the service_changes/add endpoint: service_id invoice_id vars I'm having trouble specifically with the invoice_id. (One would think the service_change endpoint would automatically create an invoice for the difference, but I digress!) I attempted to provide the endpoint with an invoice generated from the service I was attempting to modify, invoices/createFromServices, however I receive error 400: 'Invalid invoice ID.' What should I be doing here? Should this be a blank invoice? If so, how do I create a blank one? Additionally, I should be able to include my configurable option ID and the new quantity under vars once I have the invoice ID working properly, correct? Like so: vars[configoptions][config_option_id]=10 Here is a screenshot of my postman attempt: Thank you for your time!
×
×
  • Create New...