Difference between revisions of "Information Systems:Customizations to STM (Statements extension)"
m |
m |
||
| Line 26: | Line 26: | ||
[[Category: Extensions]] |
[[Category: Extensions]] |
||
[[Category: Finance Problems (I.T.)]] |
[[Category: Finance Problems (I.T.)]] |
||
| − | [[Category: Statements]] |
||
Latest revision as of 16:18, 3 October 2016
Overview
In 2008 Sheila further developed the STM - Statements extension to be able to edit EFT data prior to generation of the bank file, and also to post EFT transactions to ASW. Prior to this, transactions had to be manually entered by Accounting. This functionality is found in the STM menu/program View Statement Control Periods (ARRIQ400). The additional commands are :
- EG - Calculate EFT amounts
- EP - Print report of EFT amounts
- EE - Edit EFT amounts
- EC - Export credit EFT transactions to bank file
- ED - Export debit EFT transactions to bank file
- E1 - Build cash book entry for EFT credits
- E2 - Build cash book entry for EFT debits
As this was a customization to the extension, these commands are not documented in the technical reference manuals that were originally produced when the extensions were written. Explore the program source for more info as Sheila comments her code well.
Known issues
EFT transactions not posted to ASW
Symptom: Accounting reports that during the Statement Control process, the EFT file for the statement was generated correctly, but the corresponding transactions do not appear in the store accounts (A/R sub-ledgers) in ASW.
Explanation: The commands in this program that post the transactions to ASW first write records into ASW interface files and then call ASW programs to process these records (i.e. officially post these transactions) to the "master" transaction files. This step of calling ASW programs has led to issues in the past. Other jobs make calls to the same program (i.e. when posting data from inbound bank EDI data), so there is a theory that the 2 jobs interfere with each other. When this happens, the transactions are left orphaned in SROKBP - the A/R payment batch input file (an ASW interface file).
Solution: Query the interface file (UP1480BFVA/SROKBP). This file houses records temporarily and most of the time should be empty, so if there are records here, confirm that they all correlate to the problem at hand. Column PTIDEN will likely have a value of PY for all these records, indicating a partially posted transaction. At this point, have Accounting perform a manual Update A/R batch payments in ASW. Provide them with PTDOTY (Document type), PTJONO (Journal number), and PTIDNO (Reference number) so that they can specify the batch to be updated/posted. If Accounting has already performed manual entries to workaround the problem prior to bringing it to the attention of the IS department, these records will then have to be deleted. They will otherwise be posted when STM functions are run again, and will lead to duplicate entries in the G/L.