This import process is only used when the client cannot or does not send zero or credit balance accounts.
For example, the client sends a file with only positive balances.
When account 1234 with $100 balance is received, it's added to the database.
In 2 days, that account is paid in full (doesn't matter how this payment is done). Then the next day the client WILL NOT send account 1234.
In the "Zero Balance" process, at the very end of the import, the process looks at all existing records in the IVR that were NOT imported today. Any of these existing records that were not imported today are understood to be $0 balance records.
In the example above account 1234 is not received in the data file, but it is in the IVR database because it was received previously, so it's set to $0 balance.
To begin the import process, almost all of our IVR importers look at the
Key index ===
"Provider + Patient_Code" . These are set during the planning and IVR build, according to the client specifications: in the case of insurance premium payments, "Provider" generally looks at the insurance product type/name and "Patient_Code" would generally be the insurance subscriber or member ID.
A typical daily e-mail for a successful import via this process would contain the following information:
Expected filename mask: ^PROD.*
File: PROD_CLIENT_IVR_DataFeed_MMDDYYYY_hhmm.txt
_________________________________________________________________
OID: [11111111-11111-11111] (the client's ORG/database ID)
Plugin: plugin.plugins2.client_ivr_plugin
File name: PROD_CLIENT_IVR_DataFeed_MMDDYYYY_hhmm.txt
Constraint: None
Duplicate entries: n
Records from file: (e.g.) 97846 = Number of records sent in today's daily SFTP file.
Records before import: (e.g.) 162284 = Number of records in the IVR. All are compared to the records in today's import.
Records after import: (e.g.) 161566 = Total number of records in the IVR after today's import.
Inserts: (e.g) 97846 =Same number as records from file.
Warnings: Warnings and errors: are addressed on case- by-case basis if they do arise
Errors:
Even where the custom "zero" process can sometimes be useful for allowing daily imports of a full data file, there may be file size constraints or, in some cases, requirement for multiple daily imports to accommodate multiple providers/payment outlets or other needs. In these cases, an accumulate process can be implemented.
Comments