Developing Add-Ons for Pastel Partner Accounting System
Johan van Zyl - JVZ Systems CC
The e-mail from Kevin Howell prompted this response, please note that
it is
fairly detailed, you may wish to print it for later perusal.
I have been writing add-ons now for two years, before that I was on
the
Pastel development team for over 6 years. I have been through several
different approaches to Pastel add-on development during this time and
have
the following to offer ...
If you are writing in-house software, or customisations for specific
clients, you may want to take note of the following.
1. Pastel does not have any "hooks" in their software for 3rd-party
developers, that means that there is no DDE enabled in their screens.
If
your customer wants to put an extra Kilometre reading field on his
invoice,
this means that you need to write an entire invoicing screen just to
accommodate the new field.
2. The addition of a new field could be accommodated at the file
level by
using a spare field in Pastel, e.g. the message lines of the invoice.
Pastel's own forms designer could then be used to display the chosen
field
against a more appropriate label; and in a more appropriate place.
3. 32 bit development poses a bit of a problem for the Pastel
3rd-party
developer, Pastel has provided a toolkit that gives some access to
their
files, albeit very controlled access in order to maintain data
integrity in
their system. This is not a bad thing. If you wish to do anything else
outside of the scope of their toolkit you have a few options.
a) Btrieve ODBC driver
This uses the DDF files supplied by Pastel in order to define the
Pastel
file layouts. ODBC is the accepted standard for interfacing to any
databases
not automatically supported by your development platform. In 16bit
Visual
Basic, Btrieve was supported by ISAM drivers that shipped with the
various
Microsoft products - it was therefore very easy to bind a control to a
Btrieve file. In 32bit, however, there are no ISAM drivers for
Btrieve, and
possibly never will be, so ODBC becomes one of your main routes into
Btrieve
. ODBC has some drawbacks though, it tends to be a little slow because
it
has to convert the Btrieve information into the same format that say,
an
Access file, would end up in. ODBC has to be registered on your
machine, it
gets registered to a specific directory where the DDF files are, the
DDF
files point to their local directory for the actual Pastel Btrieve
files.
This is OK if you never need to change the data path, but if you want
a
system that allows the user to swap between different Pastel data you
need
to register the ODBC entry for each directory you are going to use.
This may
be a limitation in certain development platforms only.
b) The Smithware controls from Pervasive
This is not a bad option for most tasks - the problem (as far as I
last used
them) comes in when you want to bind a grid to a Btrieve file. As far
as I
know there is no data bound grid available for Btrieve in 32bit.
Grids are
the essence of the user front-end in most systems today. The Smithware
controls offer various other controls that do bind to the Btrieve
files,
it's worth checking them out. Look up Pervasive's site on the web.
c) Partner Systems' Toolkit
This offers direct access to Partner's files without the need for ODBC
or
DDF files. It has been specially written to cope with the job, and is
used
every day in real life applications, so it gets updated all the time.
This
is the fastest access to Pastel's files as it uses native Btrieve API
calls
directly to the Btrieve Microkernal. There are also other DLL's
offered for
lookup screens and text box controls. Although access to Pastel
Partner's
files are possibly easier via this toolkit, it still does not allow
for data
bound controls other than the DGText textbox which binds like any
other
text box but with about 20 more properties and automated Pastel
lookup.The
problem of the data bound grid is still unresolved, and still one of
the
largest parts of our development.
d) There are some other offerings of Btrieve Data Controls available
from
the web. These claim to act just like a normal data control, therefore
allowing a TrueDB Grid to be bound directly to a Btrieve file. It is
worth
looking for these controls on the web, I have had some success with
one of
them, alas, I cannot remember the name.
e)Or, you could use 16bit development platforms such as VB4 or Access
2 -
they have ISAM drivers for Btrieve
SPEEDY DEVELOPMENT
--------------------------------------
When you are quoting a Pastel client on a customisation you often need
to
take into account what he has paid for the core accounting product.
There is
often resistance to a quote like R30,000 for a complicated add-on.
Although
the job requires you to reproduce the Customer Invoice, Supplier
Invoice,
Sales Order, Purchase Order, Cash Book, Journal, Customer Master and
Supplier Master screens, as well as get ODBC to work and write a few
reports, all of which may take 5 months, the client bought Pastel for
under
R2000.00 and can't understand why you can't just "add a kilometre
field to
the screen". If you are dealing with a larger client, the R30,000 is
part of
a solution and they are not so price sensitive.
In any case, the quicker you can develop, the more profitable you will
be.
This means doing things the easy way, bound controls, existing tools
and
Microsoft Access files for anything that the user has anything to do
with.
Pastel is written in VB3 (16 bit), all their developers are VB
programmers,
it follows that any tools they release will be supported more for VB
than
for Delphi or any other language. You may wish to consider the VB5/6
language as the development platform.
USER INTERFACE (LEVEL 1)
------------------------------------------
Your user input should use whatever file manager comes naturally to
your
development language, e.g. Access (Jet) for VB. Don't waste time
trying to
bend things into shape that don't actually fit, what I mean by this
is;
don't attempt to write an inventory screen which runs from Pastel's
Btrieve
files directly and hooks in a few extra fields, you'll only become
frustrated and take too long - only Pastel can afford to do things
like that
:-). Rather open an Access database for all your extra fields, grab the
inventory code out of Pastel and have everything bound on your screen.
Your files should allow for a description field on all codes such that
when
you bind them to a grid, the description is displayed in a column.
There is
no easy way to tell a grid to look up the description from Pastel as
it
binds to your Access file, so the only way to display the Debtor name
(for
example) is to load it into your table before hand.
For the grid (table) user interface, use a data aware grid such as
TDBGrid
(True Grid) . Again, don't fight with the 3rd party controls, let your
application evolve around them. This is acceptable if you are not
planning
to sell your product off-the-shelf, and even if you are in most cases.
BUSINESS RULE (LEVEL 2)
-----------------------------------------
Your business rule level should be held within reusable code modules.
If you
are going to do another customisation in the future you may find that
it has
similar rules. Don't place package specific functions and subs into
one
large GLOBAL library - this will only frustrate you later when you
have to
keep copying and chopping to get an older project to compile again.
Once you
have separated your functions into reusable modules you may wish to
turn
them into DLL's, this gives the advantage that a more junior
programmer
could be contracted to put your solution together without running the
risk
of changing the tried and tested formulae.
DATABASE LEVEL (LEVEL 3)
--------------------------------------------
As far as back-end processing goes, I recommend a combination of the
Pastel
Toolkit and the Partner Systems toolkit. The use of the Pastel Toolkit
is
not an option, it's essential if you wish to post invoices and other
documents and maintain data integrity. If you access at a lower level,
or
use files not catered for by Pastel's toolkit, or wish to generate a
type of
transaction that does not yet exist in Pastel, then use the Partner
Systems
toolkit - but the onus is on you to know what you are updating.
A neat trick with Btrieve back-end processing is to have more than one
instance of the same file open. In this way you can query the same
file
without affecting the record pointer of the file you are stepping
through.
If you are going to write into Pastel's files without their toolkit
you
should spend some time understanding Btrieve. There's a lot you can do
that
you don't know about.
REPORTING
------------------
If you keep all your additional data in your own files (e.g. Access)
then
the Crystal Report writer is probably the best tool. Remember, you
design
your files such that Crystal will work for you, if you find that
Crystal
can't do something it's probably because your file design could be
better.
You have to fall in line with what the language/tool can offer to save
time.
For example, let's say that you wanted to report on inventory in a key
not
provided for by Pastel, or across several different companies even,
the way
to do it would be to extract the data you need with the Partner
Systems
toolkit into an Access file and then use Crystal to write the report.
What?
you say, but this takes too long to run and is a kludge - well, the
results
still get delivered and the end-user generally doesn't care.
DEVELOPER'S FORUM
-----------------------------------
If you have bothered to read through this unusually lengthy document
you
will probably consider yourself to be a serious add-on developer. I'm
sure
that you will agree that there are things that Pastel could do in
order to
make our lives easier and make the process of Pastel 3rd-party
development
more feasible.
In a recent telephone conversation I had with another serious
developer, the
topic of a developer forum came about. I would like to know if there
are
enough serious developers out there. Should we perhaps meet and
discuss
issues face to face, share code examples, air our frustrations, that
sort of
thing? It may be advantageous to have a body that can pose problems to
Pastel and ask for solutions, rather than all yapping away
individually and
being an irritation to the already overburdened Development Manager.
The fact that we are dispersed around the world is not a problem, if
we have
a representative locally here in SA that can go to Pastel with the
concerns
and requests of the group we may all stand a much better chance of
getting
the things we need.
The developer_list as it stands is not really a developer group,
merely a
vehicle for it.
If you would like to start a developer group please send your
suggestions to
par...@pixie.co.za Once I have received these I will forward all
responses
to each and every participant. From there we can make a decision on a
meeting schedule for local developers (or virtual meeting place for
international developers), local representative, issues to put to
Pastel and
anything else you may think of.
Thank you for your ineterest.
Sean Gordon
Director: Research & Development
Partner Systems (Pty) LTD
South Africa
par...@pixie.co.za
www.partner.co.za
+27 11 475 1747
082 659 3120
-----Original Message-----
From: Kevin Howell <ke...@record.co.za>
To: develop...@pastel.com <develop...@pastel.com>
Date: 25 August 1998 08:02
Subject: 3rd Party Reporting software...
>Our company uses Pastel Ver.4 and we would like to write software to get
>more detailed reporting on sales figures. Items like Debtors per
>Inventory Group,Salesman per Inventory Group etc.Has anyone already done
>something like this or can someone help us in this reagrd. I use Delphi
>Ver4 and haven installed the dll file . A few pointer would help
>regarding how to use the DLL to write 3rd Party software.
>
>Regards
>Kevin Howell
>
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~
>This list is a discussion forum for Pastel Third Party Developers. To
unsubscribe from this list send a mail to li...@pastel.com, do not
enter a
subject and the body of your mail should contain the words:
>
>unsubscribe developer_list
>
>The body of the e-mail should contain nothing else.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This list is a discussion forum for Pastel Third Party Developers. To
unsubscribe from this list send a mail to li...@pastel.com, do not
enter a subject and the body of your mail should contain the words:
unsubscribe developer_list
The body of the e-mail should contain nothing else.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Johan van Zyl
Somerset West
South Africa
j...@intekom.co.za
CPD 2.110, CW Standard 2002, CW5EE
File Manager 2, Wise Installation
MS Office, Zoltrix Speaker/Fax/Modem
Don Redd
I've seen several postings on Pastel. Can and where can I get an eval copy
of Pastel???
Thanks,
Don
Don Redd
Paul MacFarlane
There is no distributor in the US. You can download the demo, but you can't
sell it<g>
--
Paul MacFarlane
American Riviera Software
mail: pa...@business-plaza.com
http://www.business-plaza.com
remove *SPAMLESS* from reply address
Don Redd wrote in message <35eb0...@tsnews.clarion.com>...