I am currently doing some research regarding the Contracts module of Maximo. My question is as follows.
How do you change a contract status to expired in Maximo?
We are currently using versions 7.508 and 7.602.
From what I have found so far it is possible that this may only be done via an escalation, but it would be nice if anyone could enlighten me as to another method. I was hoping that a contract would automatically change to expired status once the current date has surpassed the expiration date, but had no such luck.
Related
Im looking for some advice in relation to a solution that allows a payment to be triggered on a specific event, automatically.
Step 1: User signs up to make a charity donation (provides banking information)
Step 2: On triggering a certain event, a $1 donation is automatically made to the charity from the user
Step 3: A receipt generated back to the user, and also to the charity.
Step 2 would need to trigger each time the event happens, so although it could be $1, the event might happen 3 times, and therefore 3 payments would be made.
I'm looking at something like Stripe as the payment gateway provider, just not sure if I'm looking for the right kind of solution, and whether there is something else Ive not come across already.
Alternatively I would look at collating all occurrences of the event, and send a monthly payment link (which appears to be much simpler approach).
Any help would be appreciated, as Im looking to automate donations for a particular charity in the UK.
Very grateful for any advice anyone is willing to share. Thanks everyone.
Focusing on your overall goal, I believe you could use this [1] flow from Stripe which allows you to collect payment method information from your users and charge them later (whenever you want) by calling the API.
The idea here would be that whenever your "event" is triggered, you code calls the API and charges the saved payment method.
I can't provide a more thorough/specific suggestion since "event" term here is quite vague. Is this "event" time driven (like a subscription) OR something else?
[1] https://stripe.com/docs/payments/save-and-reuse
I have created a project that allows users to subscribe to our service monthly or yearly.
Now, I want to test our Stripe integration by attaching a working credit card, then changing that credit card into a "decline card" which I found here (4000000000000341).
Now, I wanted to test that flow. I can see that the user's upcoming invoice is still next month, but obviously, I cannot wait for next month since I want to test it right away.
I was Googling and I see that they mentioned that I should put a trial date, I tried that by modifying the user's subscription in the Stripe dashboard, but seems not to work. Maybe I'm missing something or did something wrong? The current flow of our subscription basis is we don't have a trial period, so I am not sure if putting a trial date is applicable to us.
Any help/tips is greatly appreciated! Thank you!
You should use test clocks.
You can simply advance the clock's time to one month later so that the upcoming invoice will be ready for you.
I believe the upcoming invoice won't be paid successfully as you are using a decline test card. You can read this doc to learn more about invoice payment handling.
I use the NVP integration on Paypal and I'm facing a situation that I need to create a method to update some info on an already placed Paypal order. The only field that I need to update (edit) is PAYMENTREQUEST_0_CUSTOM, but looking on the docs I couldn't find any put/patch methods that would help me here.
Anyone has any inputs on this case? Have anyone ever update info on placed orders on Paypal?
Thanks in advance!
There is no method to patch the information of an already completed PayPal sale transaction. Once such a transaction has completed, it is final.
If using paymentaction=order or paymentaction=authorization, you can update information when doing the DoCapture which is the final step to create a transaction. This final step can fail, so do not change your integration to paymentaction=order or paymentaction=authorization unless you have very specific business needs for those features.
The Stripe API has a source object that has a status field that tells you whether the payment instrument is chargeable or not.
However, in Stripe.net, all of the Source-related properties on the Customer object are of type StripeCard, which does not have any Status property. In fact, I can't see any way to retrieve a Source object in Stripe.net.
I'd like to be able to know whether a customer has a chargeable (not expired, etc) payment instrument hooked up to their account. How can I do this?
Also, does Stripe.net not allow manipulation of non-card payment instruments?
Stripe.net is a third-party library which means it wasn't built by Stripe. They haven't added support for Sources just yet which is why you're not seeing this. You can either make your own pull-request for this or report the issue on their github repo
Separately, though, you don't need to implement any of this at the moment. Cards and Bank Accounts are always chargeable by default. This status field is new and has been added for other sources such as Bitcoin Receivers but this isn't fully supported by Stripe officially just yet.
I do an application which deletes comments on Instagram since Saturday 31st of October, I get this response when I use API to delete comments:
{"error_type":"OAuthRateLimitException","code":429,"error_message":"The maximum number of requests per hour has been exceeded...."}}.
I see that they did a modification one year ago for the limits of the number of requests, but I don't have this error during this execution since before the update.
How to avoid it?
Is it necessary to retrieve a new token or is there an another way to avoid it?
Use a secure API request to get a higher limit. I think you missed this email from Instagram:
When we announced our publishing guidelines for likes/relationship
actions, we also introduced a new technique to sign API requests. As
part of this announcement we set a deprecation date for the previous
signed-headers functionality to Sept 1, 2015.
This email is to let you know that support for signed-headers has now
been deprecated. We know that a number of developers (including your
company) are still relying on this option, and have whitelisted your
client_id for an extended period. Please plan the migration to
securing your application with signed-requests as soon as possible.
You can learn more about this feature here:
https://instagram.com/developer/secure-api-requests/.
The extended support will end on Nov 1 2015. You will see your
rate-limits for publishing likes/follows/comments reduced if you
haven’t migrated after this date.