When using the JDE XML API, dates must be formatted as yyyy/mm/dd
If you try to use yyyy-mm-dd, you may get an error, or, insidiously, the date will be completely ignored!
Here is the template for a function to get the fiscal century, year, and period, given a company and a date:
<?xml version='1.0' encoding='utf-8' ?>
<jdeRequest pwd='' type='callmethod' user='' session='' environment='' sessionidle=''>
<callMethod app='XMLTest' name='ReturnFYPN'>
You feed in szCompany and jdTransactionDate and the other values are filled in using the specific company calendar set up in JDE.
Here is what it returns for a given value of szCompany, but varying values of the transaction date:
Valid Century, Fiscal Year and Period
This case is pretty benign, because it tells you indirectly that your date is bad.
But suppose you are creating a batch using BatchOpenOnInitialization. Here you can feed in a batch date into jdBatchDate:
<callMethod name='BatchOpenOnInitialization' runOnError='no' returnNullData='no'>
<param id='batchType' name='szBatchType'>G</param>
<param id='batchNumber' name='mnBatchNumber'>2220601</param>
<param name='cPreviousBatchStatus'> </param>
<param id='batchDate' name='jdBatchDate'>2007/11/01</param>
Created batch with icDICJ = 107303 // correct value
Created batch with icDICJ = 107305 // today's date, a good default
Created batch with icDICJ = 107305 // today's date, but not what was intended!
So while you don't get what you expect here, the result is not too terrible.
If you feed in 2007-11-01 to the function F0911FSBeginDoc, paramter jdGLDate, then the value you send in is ignored, and the subsequent journal entry has a geneal ledger date of zero! You might think that the API would catch this, but it lets it slide. Subsequently, you'll have a hard time finding this in the Journal Entry review application.
So this is a precautionary tale to make sure that you feed in dates in the correct format. The API may give a warning if it tries to use that date, as in the ReturnFYPN case above. Or it may use a "good" default value, as in FSCloseBatch, but it could also just use a "bad" default value as in F0911FSBeginDoc, in which case your data is basically polluted and you'll need an expert to come in and clean it up.