Getting a warning message while confirming production order using transaction code CO15 in SAP ERP which is not letting us confirm the order.Msg:
According to factory calendar (2015-03-14) posting date is not a working day (check entry)
Tried changing factory calendar still its not working.
Can anyone help?
Normally this message is only a warning and if I understand above you say its a warning so you can just press enter to continue. You can also change the posting date on the lower part of the screen to a date that could be in your factory calendar
Later...
Related
I have an XBOX only app in the Microsoft Store that has been up for a while. The app has an add-on.
I use a very simple code to get the list of licenses in order to check if the user has add-on.
See below.
StoreAppLicense appLicense = await StoreContext.GetAppLicenseAsync();
var licenses = appLicense.AddOnLicenses.Select(item=> item.Value).ToList();
//Here I just save this in my log to see what is in the list
LogInfo("licenses: " + string.Join(',', licenses.Select(l => l.SkuStoreId).ToArray()));
Ok, so most of the time this code works fine. But there can be instances where the StoreAppLicense returns an empty list, even when the user HAS the license.
This has been a problem that has happened sometimes since I published the add-on, but was always fixed by reinstalling the app. Lately, even after a reinstall; the issue reappears.
What is worst, this even happened to me two days ago. I reinstalled the app and it worked fine; but after restarting the app it happened again. Then after some hours when I came back home it "solved itself".
I also have the suspicion that sometimes the StoreContext.GetAppLicenseAsync() method never returns and that causes the app to "hang".
Needless to say, customers get upset at me and give me bad reviews for something that is beyond my control.
What should I do in this situation? Can you even trust the StoreContext library?
Has someone seen this happening before?
Our portal has been running on Liferay 6.2 for several years. We have many services that use HTML forms (usually written with Alloy UI in Freemarker) to allow users to submit requests. The server code is written in Java and uses the liferay portletrequest objects to return the submit form data.
However, recently these forms suddenly stopped working.
Specifically: if the form includes a file for uploading, then the ActionRequest object does not return any of the form fields as parameters the way it usually does (request.getparameter(paramtername) returns null instead of the string value that the user entered into the form). If the user does not include any files then it works normally.
This doesn't seem to be an issue with the forms or the java code as many forms who's code has not been touched in years suddenly stopped working. What's more this stopped working partway through a day in which we didn't make any changes to the application.
I'm struggling to understand what I'm seeing in the logs. The error messages that feel most promising look like:
Caused by: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)
at org.apache.commons.fileupload.portlet.PortletFileUpload.parseRequest(PortletFileUpload.java:109)
at org.springframework.web.portlet.multipart.CommonsPortletMultipartResolver.parseRequest(CommonsPortletMultipartResolver.java:151)
... 208 more
But I haven't been able to find anything that seems relevant. Another type of error that might be related looks like:
10:00:09,095 WARN [http-bio-8080-exec-272][FileImpl:422] Unable to extract text from Scan4.JPG
org.apache.tika.exception.TikaException: Unexpected RuntimeException from org.apache.tika.parser.jpeg.JpegParser#3e34efc2
We've been trying to track down the issue for days now, I'm desperate and out of ideas. Can anyone think of any possible reasons why files would not upload?
I couldnt figure out how to get the status of the transactions i.e "Fail with error "001010".
The ability to show error message, or the revert reason. depends on the EVM client (GoEthereum, Erigon, Ganache, Ethereum Tester, etc.) There is no bulletproof "standard".
The clients store only the receipt field status that is 0 or 1 (=success)
The clients do not store the revert reason (I might be wrong on this one and this has changed lately)
To get the actual error message you need to replay the transaction and a certain block height using a special eth_call JSON-RPC.
Here is a Javascript library for doing it and a related blog post about the topic.
On a script which has been working fine for some time and unchanged, today I get
'Execution failed: Data storage error'
on a line which consists simply of:
PropertiesService.getScriptProperties().setProperty('runMode', 'LIVE');
What can I do to fix this?
Is this some kind of server error?
It's an error from Google. An issue as already been submitted, you can upvote it (click the star in the title) : https://code.google.com/p/google-apps-script-issues/issues/detail?id=6856
[EDIT] Seems to be up and running now.
Yes, the google-apps-scripts-issues 6856 describes the problem exactly, as experienced today by dozens of users. Appears to have been fixed at approx 14:00 GMT 24-Mar-17.
Would like to know whether we need to code around the possibility of a repeat of this error.
with fullcalendar v3.0.1 I try to set initial date range with this setting:
startParam: '2017-01-01 00:00:00',
but, if I go back into the past with arrows button, I can back to 2016 and previous years...
What makes you think that startParam restricts when the calendar can go back to? It's a parameter passed to the server when new events are fetched which tells the server the start date from which events should be returned in the current request - generally it will correspond to the start date of the current view in the calendar. And if you look at the docs for this property: https://fullcalendar.io/docs/event_data/startParam/, it mentions nothing about what you describe. I don't understand why you thought this would work.
If, for some reason, you want to stop users going back in time before a certain date, there is no currently official supported way to do this. This issue log: https://github.com/fullcalendar/fullcalendar/issues/429 suggests that support may arrive in a future version, but at present you will need to work around it.
To be honest though I'm not sure why you really would need to do this. If you want to prevent users seeing any events before a particular date, the simplest way would be not to provide any event data to the calendar which is before that date - then if the user moves to those earlier dates, the calendar would simply be blank.
If you really feel you need to do this though, the only way I can think of would be to handle the viewRender event, and if the first day displayed in the view is on or before your minimum date, disable the "previous" button, or something.