Customizations of BIF (Bill Invoice Formatter) have always posed a great challenge
for Kenan installations that require specific customizations in bill formats to
meet business needs. Designed by Daemon, the Smart Bill Invoice Formatter (SBIF),
provides an easy and flexible means where customization of BIF for specific business
needs become instantly achievable. SBIF, which is compatible with Kenan/BP v8.x
to v12.x, has been designed from a bottom-up approach to cater for the generic needs
of bill formatting. Whilst keeping the product open to customizations to incorporate
unique business requirements and operational needs, the core product supports all
the existing functionalities of BIF.
Benefits
•
The Smart BIF works with Bills generated by the BIP process. Although the
customization of BIP at specific sites may result in data that is not consistent
with Standard BIP output, the initial delivery of BIF would take care of such scenarios.
•
Comprehensive documentation would be provided.
•
Smart BIF caters to the issues/problems related to the changes of BIF for all major/minor
fixes/enhancements.
•
Smart BIF takes into consideration the scalability and platform independence. (It
is written in C++ (ANSI), which allows compiling and running in different platforms
including Linux. Smart BIF written in Java would allow more native integration with
Kenan Installations using Oracle since Oracle has full support for Java from version
8.x). Features specific to Oracle and its tuning can be fully exploited, which again
would depend on the customer′s choice.
•
Smart BIF processes Extractor and Formatter could be made to run parallel based
on configuration settings. The synchronization between the two would be taken care
internally and hence achieving maximum performance and stability. Dispatcher is
invoked after both Extractor and Formatter have finished their jobs.
•
Smart BIF processes are multi-threaded by design to maximize the performance. It
automatically splits a whole batch into "n" (configurable) batches to run the processes
in Parallel. It can automatically reduce the number of threads based on availability
of system resources, hence avoiding Server/Process crashes.
•
Separating the Extractor and Formatter will be an advantage especially when there
are newer requirements to be fulfilled and the customization may need to be done
at the process level itself. For instance, the output of the extractor will always
be the same. In the event that extra fields need to be extracted, configuration
of the new data fields can be completed instantly.
•
Storing the output files, the feed file, in AFP and PDF will provide the formatted
bills readily to requesting customers. This will certainly reduce the amount of
manual work that is required to generate a duplicate bill(s). The Dispatcher can
be configured to transfer the feed files to an existing conversion routine or if
the AFP conversion is enabled, the AFP files generated can be transferred to the
print shop directly. This will reduce the amount of manual effort tremendously and
improve the turn-around time of such request.
•
The Dispatcher can be configured to use one of the popular transfer mechanisms,
i.e. FTP/TELNET/SSH2. CDs could also be burnt if required
•
Manually processing the jobs has a higher risk factor. By automating most of these jobs each and every error can be trapped and this would ensure that all the bills
delivered to the print shop are consistent and correct.
•
Generating an intermediate XML file as output of the extraction process takes advantage
of this popular format, which can be considered as a database on its own. This gives
the flexibility to convert this XML file to any required format. AFP and PDF are
the current popular formats that are supported by default. Should the need arise
to generate it to a different format; Formatter can be modified to reflect the new
format.
