Micr Class
Namespace: Microsoft.PointOfService
Assembly: Microsoft.PointOfService (in microsoft.pointofservice.dll)
Usage
'Usage
Dim micr1 As New Micr()
Syntax
'Declaration
MustInherit Public Class Micr
Inherits PosCommon
public abstract class Micr : PosCommon
public abstract ref class Micr : public PosCommon
public abstract class Micr extends PosCommon
public abstract class Micr extends PosCommon
Remarks
Capabilities
The MICR service object has the following minimal set of capabilities:
Reads magnetic ink characters from a check.
Has programmatic control of check insertion, reading, and removal. For some MICR devices, this requires no processing in the service object because the device may automate many of these functions.
Parses the MICR data into the output properties provided by this service object. This release of POS for .NET specifies parsing of fields indicated in the ANSI MICR standard used in North America. For other countries, the application may need to parse the MICR data from the data in RawData.
The MICR may have the following additional capability:
- The MICR device may be physically attached to or incorporated into a check validation print device. If this is the case, after a check is inserted via MICR service object methods, the check can still be used by the Printer service object before check removal.
Some MICR devices support exception tables, which cause non-standard parsing of the serial number for specific check routing numbers. Exception tables are not directly supported by this POS for .NET release. However, a service object can support them, and can assign registry entries under its device name key to define the exception entries.
This release of POS for .NET does not define any parsing of partial MICR check data if an error occurs while reading a check, because any service object that implements such functionality cannot guarantee that fields parsed from partial data are correct. For example, it is possible to get MICR data that contains no ‘?’ characters, but fails its checksum. This indicates that one or more characters in the data are incorrect, but there is no way to determine which characters they are. If an application wants to parse the partial data, the RawData property is filled in with whatever was successfully read, even in error cases.
Model
The MICR service object follows the general “Input Model”. One point of difference is that the MICR service object requires the execution of methods to insert and remove the check for processing. Therefore, this service object requires more than simply setting the DataEventEnabled property to TRUE to receive data. The basic model is as follows:
The MICR service object is opened, claimed, and enabled.
When an application wants to perform a MICR read, the application calls the BeginInsertion method, specifying a timeout value. This results in the device being made ready to have a check inserted. The method returns either a success status if the check is inserted before the timeout limit was expired, or a timeout status.
In the event of a timeout, the MICR device remains in a state that allows a check to be inserted while the application provides any additional prompting required, and then reissues the BeginInsertion method.
After a check is inserted, the method returns successfully and the application calls the EndInsertion method, which results in the MICR device being taken out of check insertion mode and the check, if present, actually being read.
If the check is successfully read by the MICR service object, it queues a DataEvent.
If the AutoDisable property is TRUE, then the MICR service object automatically disables itself when a DataEvent is queued.
A queued DataEvent can be delivered to the application when the DataEventEnabled property is TRUE. Just before delivering this event, the service object copies the data into properties, and disables further data events by setting the DataEventEnabled property to FALSE. This causes subsequent input data to be queued by the service object while the application processes the current input and associated properties. When the application finishes the current input and is ready for more data, it reenables events by setting DataEventEnabled to TRUE.
ErrorEvent(s) are queued if the service object encounters an error while reading the check, and are delivered to the application when the DataEventEnabled property is TRUE.
The DataCount property can be read to obtain the number of DataEvents queued by the service object.
All input queued by the service object can be deleted with the ClearInput method.
After processing a DataEvent, the application should query the CapValidationDevice property to determine if validation printing can be performed on the check before check removal. If CapValidationDevice is TRUE, the application can call the Printer service object’s BeginInsertion and EndInsertion methods. This positions the check for validation printing. You can then use the Printer service object validation printing methods to perform validation printing. When validation printing is complete, the application should call the Printer service object’s removal methods to remove the check.
After the check is no longer needed in the device, the application must call the BeginRemoval method, also specifying a timeout value. This method returns either a Success status if the check is removed, or a Timeout status if the check is not removed. If a Timeout is returned, the application can perform any additional prompting before calling the method again. After the check is removed, the application should call the EndRemoval method to take the MICR device out of removal mode.
Many models of MICR devices do not require any check-handling processing from the application. Such devices may always be capable of receiving a check and require no commands to actually read and eject the check. For these types of MICR devices, the BeginInsertion, EndInsertion, BeginRemoval and EndRemoval methods simply return a Success status, and the service object queues the data until the DataEventEnabled property is set to TRUE. However, applications should still use these methods to ensure application portability across different MICR devices.
Device Sharing
The MICR is an exclusive-use device, as follows:
The application must claim the device before enabling it.
The application must claim and enable the device before the device begins reading input, or before calling methods that manipulate the device.
See the “Summary” table for precise usage prerequisites.
MICR Character Substitution
The E13B MICR format used by the ANSI MICR standard contains fifteen possible characters. Ten of these are the numbers 0 through 9. A space character may also be returned. The other four characters are special to MICR data and are known as the Transit, Amount, On-Us, and Dash characters. These characters are used to mark the boundaries of certain special fields in MICR data. Because these four characters are not in the ASCII character set, the following lowercase characters are used to represent them in properties and parameters to methods:
Inheritance Hierarchy
System.Object
Microsoft.PointOfService.PosDevice
Microsoft.PointOfService.PosCommon
Microsoft.PointOfService.Micr
Microsoft.PointOfService.BasicServiceObjects.MicrBasic
Thread Safety
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
Platforms
Development Platforms
Windows XP Home Edition, Windows XP Professional, Windows Server 2003, Windows Longhorn, and Windows 2000