Search options (Page 79 of 245)

The latest version is attached herein and complies with changes in the 2017-12-19 core commit for VARLOG_PATH and VARLIB_PATH (the latter is exclusively used herein as per relevant core inclusions).

CHANGELOG

Look at overwritten Lines 109,110 in api24/sales.inc:

$info[$sale_index]['ov_discount'] = $trans['ov_discount'];
$info[$sale_index]['ov_discount'] = $trans['Total'];

The above has been corrected and committed in my repo.

Also the VARLIB commit in the core has not been updated as yet in this module but committed in my repo.

The URLs for sales (TRANS_TYPE = 10 for Sales Invoices) are like:

http://www.example.com/frontac24/modules/api24/sales/<TRANS_TYPE>
http:// www.example.com/frontac24/modules/api24/sales/<TRANS_NO>/<TRANS_TYPE>
http:// www.example.com/frontac24/modules/api24/sales/<TRANS_NO>/<TRANS_TYPE>?page=<PAGE_NO>

Note the order of the attributes in the last 2 URLs above.
The api24/config_api.inc has the constant RESULTS_PER_PAGE defined in it.

Both work okay in my version. For Transaction Number 2 in Transaction Type Sales Invoice (10) the output is:

{
 "ref":"002\/2017"
,"comments":""
,"order_date":"05\/07\/2017"
,"payment":"4"
,"payment_terms":{
    "0":"4"
   ,"terms_indicator":"4"
   ,"1":"Cash Only"
   ,"terms":"Cash Only"
   ,"2":"0"
   ,"days_before_due":"0"
   ,"3":"0"
   ,"day_in_following_month":"0"
   ,"4":"0"
   ,"inactive":"0"
   ,"5":"1"
   ,"cash_sale":"1"
 }
,"due_date":"05\/07\/2017"
,"phone":""
,"cust_ref":""
,"delivery_address":"N\/A"
,"ship_via":"1"
,"deliver_to":"Donald Easter LLC"
,"delivery_date":"05\/07\/2017"
,"location":"DEF"
,"freight_cost":"0"
,"email":""
,"customer_id":"1"
,"branch_id":"1"
,"sales_type":"1"
,"dimension_id":"0"
,"dimension2_id":"0"
,"line_items":
 [
  {
     "id":"6"
    ,"stock_id":"101"
    ,"qty":1
    ,"units":"each"
    ,"price":"300"
    ,"discount":"0"
    ,"description":"iPad Air 2 16GB"
  }
 ]
,"sub_total":300
,"display_total":300
}

@boxygen: The database integrity will be affected as 1 Sales Order is related to 1 or more Customer Deliveries but 1 Customer Delivery  pertains to just 1 Sales Order as the latter has the Cust_Branch defined in it.

@stefan: Sales Order Tracking will then have to be manual on the description / memo fields.

The best way is to make a new Sales Order for another cust_branch and edit / move over the subset of items that need to emanate from that other cust_branch to it and effect delivery from it.

Take a backup.
Enter one such depreciation record.
Take another backup and see what SQL INSERTs/ UPDATEs are needed.
Restore from first backup.
Make SQL statements for all depreciations and then import them into the DB.

A non alphabetical first char being omitted before sorting....
Thanks - hope this helps someone.

There was no difference in FA 2.3.26 - wonder what made this necessary now.

A sales order is specific to a Customer Branch in FA as of now.

Try to upgrade to the latest GitMaster version since there have been several bugfixes since the FA 2.4.3 release version. You can overwrite with the changed files and adjust for the new constants in the config files and small changes in the db data (sys_prefs table).

Check if the customers have any credit bills pending.

A brand new South African Chart of Accounts has been prepared on your request (upload the chart to the sql folder) and added to the FA24extensions repository. Kindly provide feedback.

ZAR Currency - Rand / Cents
VAT 14%
Fiscal Year from 1st March till last day of Feb of next year
1 user: admin
Initial admin password: password

The Chart from the Official repo has some field order and other DDL issues besides having no P&L Account - essentially broken. It is stated to be a 5 digit Chart but in actuality it is a 6 digit one. Hence, if you use it, then be prepared to customise it to work. Otherwise, use the one linked above.

This has now been inculcated in the default standard Chart of Accounts in a recent commit for FA 2.4.3+.

When a Direct Sales Invoice is raised on Cash Payment Terms, this is what is expected to happen - casual over the counter purchases. The correct way is to
1. raise a Quote (optional),
2. make a Sales Order,
3. effect a Delivery of items,
4. Invoice the Sales Delivered on Credit payment terms,
5. Receive a Payment from the customer and then
6. Allocate it to the appropriate Invoice(s).

All fiscal years must be in the order of the id field as well. Only then will deletion take place. You will need to take a full backup and restore it into another install and work on the MySQL tables carefully possibly in conjunction with a MySQL client such as phpMyAdmin or SQLyog. Also make a list of the plugins and their versions in use. This is not for the faint of heart - take professional assistance if unsure. Post a bounty in the Job offers board.

How many years do you have loaded on your system? Export out the fiscal_years table and see whether the id field is in the same order as the start date of the fiscal years order.

You may also contact the Support Consultants for assistance.

The next available Journal Entry # autofills the field but remains editable.