Search options (Page 5 of 6)

It seems the synchronisation is triggered by the "save" action. Unfortunately, it also seems the import bypasses this completely.

I guess Cartbooks simply ignores products already in the database, until it detects an update (identified by a click on the "save" button). That means you would have had the same problem if your products had already been in the database.

I can see the following possible solutions:
1. Cartbooks could implement a "forced" sync option to upload all items currently in the database.
2. Excelport could import the items through the web interface, or at least generate a "save" click/event for each item to allow OpenCart and/or its plugins to respond to the change.

Both are features which would not be unreasonable to expect.

But if you have any programming background you could probably explicitly invoke the sync function of Cartbooks from a script of your own. Or at least script the clicking of the save button.

It is certainly not a bad idea.

There have been a couple of efforts, which you might want to look into before you go about reinventing the wheel.

https://frontaccounting.com/wbt/pages/posts/frontaccounting-mobile-edition174.php
https://frontaccounting.com/punbb/viewtopic.php?pid=17065#p17065

Another idea you might consider is creating/adapting a theme for mobile devices. That would eliminate the need for an API and should be platform independent. (At least for reasonably similar screen sizes.)

The first thing to note is that the system is web based, so any number of users can use the same install. The user's browser is the client, after all.

But if you need to separate the web and database servers, the database settings are specified in the config_db.php file. FA doesn't care where the database is, as long as it can connect to it.

You just need to make sure the database is listening on its network address (and not only the loopback address) and that the database user is allowed to connect remotely.

Personally, I would dump this XAMPP/LAMPP/whatever package and go with the apache, php and mysql packages from the official repo.

The browser has nothing to do with it. But the backup script's execution time does depend on the database size, so I suspect it's a timeout issue. In your case, you've probably happened to use IE at times when the server load has been lower.

I don't know why it was implemented this way, but yes... I would say it qualifies as a bug. The workaround is to do a database dump using mysqldump from the command line or from phpmyadmin.

Thank you. I'm looking at the new code now (C Estrella's commit), and it's getting better. Not quite there yet, but... At least I'm getting data into sales_add.

Line 282 is still passing a string to input_num() which can't be right.

And the .htaccess file causes the following entry in the error log
[Fri Sep 13 00:29:15 2013] [alert] [client 192.168.22.50] /var/www/frontaccounting/modules/api/.htaccess: Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration

Now I'm sure that is a problem with my local configuration, so I've just renamed it for now. I do however get another, more interesting entry:
[Fri Sep 13 00:49:26 2013] [error] [client 192.168.22.50] 0::connect_db.inc:51: mysql_query() expects parameter 2 to be resource, null given

Parameter 2 is $db, a global variable. It is not passed to the function (db_query) which calls mysql_query. It should just be there. How can it not be there? Does it get overwritten by the API code somewhere? Because everything is fine when accessing the system through a web browser.

Edit: No. More likely, it is never set to begin with.

Don't bother with the repo version at all. What happens if someone ever packages a more recent version, and your package manager attempts an "upgrade"? After all, it won't know that you've replaced the files with newer versions.

There is a module to integrate OSC and FA, but I don't know if it's any good. For one thing, I believe it does this by working directly against the databases. Which is fine if both systems are installed on the same server. Otherwise, one of the databases must be accessible over the network. Anyway, it might be something to work from.

I would, however, suggest that you start by defining what you really need and what you can do without.

I use Prestashop and what I do is write each sale to a file on the PS server, to be imported into my local FA by a daily cron job. That only gets me journal entries, which is fine as I have no inventory to worry about. The goods are shipped from the manufacturer and the web server creates the invoices during checkout. I only have to book the payments when they arrive, which is fairly painless using quick entries.

At some point I expect to have to implement some form of accounts receivable support, but... At the time I couldn't make sense of the web service implementations I found, so I settled for a cURL-driven import using a plugin from the FA repo. If you take payment online in OSC you shouldn't need the AR bit, but if you plan on using FA to keep track of your inventory you will probably need to create a sales order/invoice.

FA seems to do "its own thing" when it comes to backups, but cpanel (I presume) and phpmyadmin should just dump the database as it is. I'm guessing (as in "I haven't a clue, but I'm trying to think of something helpful") that you have some database setting activated which slows the process down significantly. Logging? Statistics? Accounting?

If I understand you correctly you have (at least) one company which you can backup, and one which you cannot. In that case I would open the working and non-working databases in phpmyadmin in separate windows, and see if any settings differ.

I really hope we have some Windows users here who can assist you. Because once you get PHP running, you'll need to install and configure a database. I understand the Linux VM suggestion was probably a bit much for an accountant, but... Wouldn't it have been easier to just install something like XAMPP?

Anyway... The error suggests that IIS did call PHP, but the latter returned an error (or didn't return anything). What happens if you open a command prompt, change directory to that of the phpinfo.php file and type the command "C:\php\php-cgi.exe phpinfo.php"?

If the translations can be executed as code, that is indeed a problem. I suggest you report it as a bug.

However, it is a different problem. It has nothing to do with this particular button. In fact, the malicious translator could add anything he wanted - including buttons.

As for this problem... Fair enough. Moving the string to a span certainly does no harm. But it doesn't solve your problem with an apache module trying to "protect" your FA instance by filtering posted data either. The "vulnerability" just isn't there as long as the posted value is ignored. And this "protection" applies to all fields, which means that local rules may block anything the provider considers suspicious. Including user supplied data. There is no way that FA can prevent that.