Search options (Page 94 of 245)

1. random barcodes - security - so that it is not easily guessable as serial ones are. It appears to be a common way to do it in some local applications I have seen where an internal serial id is there to keep track by the application and the random one in another field is used for human / external automated interface. This technique is used in some hall ticket in examination systems to thwart "paper chasing" where auto dummy number allocation is resorted to.

2. A company specific config option to suppress the auto random barcode generation will help avoid confusion among those not using barcodes.

3. Which barcode type and how many digits in the barcode (if not specific to the chosen barcode) and the appropriate format for it, possibly without check digits (which should be auto generated) or when given, to be used for verification would make for a slightly more complex interaction best left to custom modules..... Making the function generic in the ammer you sufggested would be welcome even if not implemented fully for now. The barcode.php has anyway been fully "upgraded" manually from the original TCPDF sources of later versions to support a much wider range than was available earlier.

4. Yes, a note on the Show pictures options would be nice and it may double up for the config option or is it to be differentiated in some way by being a new one?

Why was the index:

UNIQUE KEY `name` (`name`,`rate`)

removed from the 0_tax_types table in FA 2.4 while it was there in FA 2.3?

Do we allow the same named tax with the same rate to appear more than once?

If so, how would we distinguish them in the select drop-down boxes?

@joe: what say you?

None of the others have any externally sourced references like a sales order did.

@joe: should the concurrent edit issue have a more generic solution to cover all auto generated references?

Better still - which was the original Chart of Accounts you used to start with?
Did you install any extensions that caused these differences?

You can upload anywhere (delete all insert statements especially for the users table) - just your schema and the differences with en_US-new.sql and paste the link here.

You have merged what should have been 2 separate vouchers. One for the invoice of 995/- and another for expenses of 5/-. Since you issued only 1 cheque for payment of 1000/- you should have got a Pay Instrument (Draft, TT, etc) for 995 and the bank would have debited you 5/- for bank charges. Hence the vouchers should have been:

Purchase Invoice:
=============
Credit AP (Supplier) - 995
Debit COGS: 995

Payment Voucher:
=============
Credit Bank - 1000/-
Debit AP (Supplier) - 995/- (Payment Allocation)
Debit Bank Charges - 5/- (Payment Allocation)

Now the Supplier Payments Report should show 995/- only.

Create a Sales Invoice and use the Slim API to GET that invoice - you will get the json value. Form your new Invoice in json accordingly and use the PUT endpoint to inject your invoice. Putting in such an invoice will not have the Sales Order, Sales Delivery and Customer Payment that would need to have their own PUT requests in place (or does it?).

I'm sure you can now parse the code and determine what you need. The community has put in sufficient effort in double quick time to assist you among others. Hopefully you too will contribute tested code to it once you get familiar.

This is what makes Open Source tick.

@itronics: The official release of FA 2.4.3 in SourceForge in it's tar.gz and .zip formats have CRLF DOS Style line endings. Kindly re-package the release.

Packages stand re-packaged with proper LF line endings as of 2017-12-11.

Those on the debian linux platform can do the following (alter path as required) if you have already installed it:

apt-get install dos2unix

find /var/www/frontac -type f \
     -name "*.php" \
     -o -name "*.css" \
     -o -name "*.js" \
     -o -name "*.txt" \
     -o -name "*.inc" \
     -o -name "*.sql" \
    | xargs dos2unix

In the meanwhile, users can get the official release from the GitHub commit here or from the SourceForge commit here..

For the record, even the latest master branch of the PunBB code as on date does not officially sport the del tag. Attached is the patch for the PunBB v1.4.4 release version to enable the said tag which has been implemented here like so: del

Since the FA Forum relies on this script, a separate repo on GitHub has been created to track the changes.

I took the easier way out by renaming the class and file to WLog and WSet instead as the original method gets used everywhere. I use Slim 2.64 and have it fully updated in my repo to manage without composer. Expect that Slim 2.x is not going to get updated very much in future, having been last updated on 2017-01-07 and FA dependant coding here will not need to rely on these low level methods at all.

All my Fixes to Slim 2.6.4 are in this commit.

The output of a json_decode to array using the API24 can be obtained after setting the test credentials in util.php and browsing to:

http://www.yourdomain.comt/FA24PATH/modules/api24/sales/5/13

This should retrieve Sales Invoice (type=13) #5.

Attached is the text output.