Re: [Web-erp-developers] Re: WebERP Customization Done

[Phil D. <ph...@du...>]

Danie,

> --Snip --
> > EANCOM EDI invoices - almost complete but really requires a test site to
get
> > up and running. I think I will have a go at receiving EDI orders too. I
will
> > include what I have and work with anyone who wants to use it.
> --Snip --
>
> Although I know what EDI is and more or less what it's
> suppose to do, I find that I am a minor here and that I have not yet
> had the opportunity to work with this type of interface. If you have
> some URL that will explain it, or some spec, I could learn it.

Introduction to EANCOM EDI

http://www.ean-int.org/data/introedi.pdf

Where I based the web-erp implementation of invoice messages from ...

http://www.leadtec.com.au/downloads/tradingpartners/HIWGINVOICImplementation
Guidev1.0.pdf


> > Foreign key db integrity - converted all tables to innodb - creation of
> > foreign keys throughout. An SQL script to upgrade users with data
already in.
> > Dick said to go slowly on this .. whoops !
> >
> --Snip --
> I believe this will safeguard the data, and I like your
> choice. I would like to see if I can somehow write a conversion script
> that can convert your MySql to Postgres, this would ease work in the
> future.

I dump the SQL from the current Mysql database and was kind of naively
hoping that with perhaps an afternoons tweaking it may be possible to run
this against postgres or other sql server and it would load up. Then changes
to ConnectDB.inc would be required to the equivalent PHP functions for
Postgres or whatever.

Does Postgres mind queires in the format:

SELECT field1, field2 FROM table1, table2 WHERE table1.field1=table2.field1;

This is perhaps the older school SQL syntax, if it does then this would mean
some re-writing of queries to put the INNER JOIN etc in there. Otherwise I
think it should run quite easily .... maybe ;-)


> --Snip --
> This is great, however, the reason I have done It the other way, is not
really for the benefit of being
> able to email, fax or save the pdf, although this is surely beneficial, it
is because it automates
> the process a little better, Click on print pdf, and up pops printer
interface (Please select, printer OR email,pdf or fax.)
> Although this sounds like much work, it really is not. simply change .pdf
extention to .prpdf under Linux system,
> add Mime-Type to browser to auto exec shell script with this file, then
convert pdf -> PS and pipe to kprinter.
> Under windows this might not be possible.
>
> However, we could integrate fax services directly into WebERP as well, and
maybe stream
> directly to specific printer, by analyzing file name. ex. (
lp1_CustomerInvoice.prpdf )
> which would allow the user to specify which printer he would like to use
and instead
> of using kprinter, it would simply stream directly to printer. ????
> Simple to do, however some terminal information will need to be stored in
a cookie.

This sounds pretty clever stuff - some way to stream directly to a remote
printer would be great too.

If it doesn't work for windows this cuts a lot of users out - sadly most!!
However, if we can make the experience better to linux users fantastic.

> Python is much like Java underneath, in that it is also byte code.
> It runs on more platforms than Java to my knowledge.
> Python as a language can be learned in a few hours and more importantly
> it is fairly easy to program, support classes and inheritance,
> but not some of the finer security restrictions. It can do everything Java
can
> and is a lot faster. To the point where it is possible to create OpenGL
simulations
> with it. It has access to a library called wxWindows which will allow
cross platform
> capability no changes necessary if programed right.
>
> For straight console type POS it is probably better to use Curses with
Python and
> only Linux OS as it should be a stand-alone system and cross platform is
probably
> not necessary.
>

Python sure sounds great. I think integration to an existing POS system
going to be the best thing - ideally Python or Perl? I would not be keen to
adopt a linux only solution though - much as I love this platform. Whatever
we think of the platform, windows represents the biggest bulk of users and
to put a lot of work into a linux only solution .... not sure about that
personally.


> --Snip --
> >
> > > 5. ) Figure out how to share/sync transactions accross
> > > multiple instalations. ( Requirement from a prospect )
> > >
> > Not quite sure what you mean here Danie. Obviously others can see the
> > transactions through the interface. A DB can be replicated accross
sites - or
> > just certain tables. This sounds like it may be a more specific request
> > perhaps than one of allround appeal.
> --Snip --
>
> One thing that people do not know about Africa as a whole is that it is
> incredibly expensive to run Wide Area Networks(WAN). Far more expensive
than
> running it in first world countries. So while the system has great appeal
> in its ability to run on a WAN, the reality is that in Africa it will be
> run on a local network, and the appeal is that we do not have to upgrade
work
> stations, as they will not be doing the work, only providing an interface
to
> the user. This leaves multiple branches that need to synchronize on a
daily
> basis. In terms of your system, Denver and Utha will have to synchronize.
> Utha can take orders for Denver and Denver can take orders for
> Utha, even though they do not have accurate stock movement tracking.
> This problem is resolved with good planning for reserve stock.
> This is standard practice in Africa (for now, until our telecoms companies
> sort things out.). The problem is that we need to synchronize databases
> properly so that each devision can see what happens in all the other
devisions.
> This is important because each director of the company generally
administers
> a location/branch but need full financial and stock information in order
to
> do his budgeting, especially in the retail market.
>
> Sounds funny, I know, but this is the reason none of the companies have
> been able to make a significant impact on the African markets. Even the
> German company I used to work for failed to pay heed to this problem,
> as a result they had to cancel all operations in Africa, and the investors
> backlash forced them to close most of their offices around the world,
> ( Nigeria, Spain, Romenia, America, all but one of their offices in
Britain
> and all but two of their offices in Germany) a lot of money.
>
> Companies that always had this type of synchronization have survived,
> AccPac, SAP, BAAN, Hogan. Although Hogan has gone through a rough patch
because of it's
> association with IBM and the AS400's, these days it runs on Linux.
>

This sounds like quite a knotty one!!

> --Snip --
> > Yes please!! If you could email me the amended scripts or better still
the
> > diffs I will include them.
> --Snip --
>
> I will as soon as I have figured out a way to safeguard for
interoperability.
> i.e. I need to make sure it does not break windows functionality. Once I
have
> done that I will email you a description of changes I made to
class.pdf.php
> and also to other changes to *.php files as required. I will also include
the
> shell-scripts with explanation on how to integrate it into Linux,
> possibly some setup script as well.
>
> I will also send the manuals once we complete them, firstly for comments
and revision,
> secondly for updates to get the manual compatible with 1.8.

I look forward to this.

> Further more, I would like to ask for system 1.8 for testing purposes.
> The CVS version as downloaded though the weekend does not work as it
> complains as soon as I try to create any PDF, through invoicing,
> however no problem with reprints. As we are currently concentrating
> on the manuals this will have to hold for a little while.
>
> I will then also send a chart of accounts for South Africa as soon as I
can
> convert it for 1.8.


I will hold any other work on the manuals in the interim - won't be hard -
its my least favourite part of this project. Amazed and chuffed that there
is another mug who believes in this enough to put the work in ... many
thanks.

>
> I have currently 5 clients that would like to use the WebERP system.
> One is a large retailer, by South African Standards, retailing
> and shipping furniture. (Looking at middle march.)


The POS problem .....


> Another is a supplier of scales to the farming community is
> South Africa and surrounding countries, they have a
> manufacturing requirement in addition. (Whenever I'm ready.)

Ideal - gives me a focus for the manufacturing functionality.

>
> Then there is a small manufacturing company, an Insurance company
> and a building company, specializing in fittings. (As soon as possible.)
> All have expressed and interest in WebERP.
> Then of cause we would like to run on WebERP ourselves.

>
> Any comments in this regard will be appreciated, even if you think we are
nuts and should
> trash the whole idea. That would not stop us from further assisting in the
development of WebERP.
>

No, I think you are wise!!

I use it in a subsidiary of my company with great success AUD 11 million.
Locations in Melbourne and Brisbane, plumbing products wholesaler. It is
solid, dependable and fast. Not that any reference from me would be
independent! But it really has been a raging success in our subsidiary. It
has been in use since July 2003 - there were a few bugs in pricing
initially - very demanding requirements here, but really no problems at all
since then. A failed mirrored disk had to be replaced - but zero down time.
I spent a Saturday there!!


Phil