Search options (Page 6 of 11)

Because you are running FA 2.4.7, I'm guessing the issue is a bug that was unmasked by the introduction of STRICT_ALL_TABLES.  In my installation, I am keeping this off until it has been tested for a few years.

+++ b/core/includes/db/connect_db_mysqli.inc
@@ -10,7 +10,7 @@
     See the License here <http://www.gnu.org/licenses/gpl-3.0.html>.
 ***********************************************************************/
 define('DB_DUPLICATE_ERROR', 1062);
-define('SQL_MODE', 'STRICT_ALL_TABLES'); // prevents SQL injection with silent field content truncation
+define('SQL_MODE', ''); // well tested

Just to expand on what @apmuthu said, use Advanced Manufacturing.  Either use a BOM with the minimum amounts and add issues (ie. raw materials) to cover for the additional amounts or do not use a BOM and just add the issues you actually used.

If you are trying to track the waste separately, that is another question.

How rather odd and I wonder why?  I suppose you could also effect the same "fix" without changing the code and changing "go_debug = 1" in config.php?

You found at least one bug: Line 36-38 in items_adjust_db.inc

if ($SysPrefs->loc_notification() == 1 && $line_item->qty < 0)
        {
            $chg = $line; $chg->qty = -$chg->qty;   // calculate_reorder_level expect positive qty

The error message is correct.  qty is indeed not a member of class line_item.   (I think the coder meant to say $line_item->quantity.)

But even if the coder did mean quantity, $line isn't defined either.  So I doubt that this code was ever tested and would take some investigation to figure out what really is supposed to happen.

So why is the problem only plaguing you?  Well, maybe you are the only one with $SysPrefs->loc_notification() turned on?  Or maybe you just have an "advanced" version of php that doesn't just blithely ignore obvious language semantic problems?  Or maybe it just isn't your lucky day.

What happens if you add

global $bank_account_types;

or

include_once($path_to_root . "/includes/ui/ui_lists.inc");

before your code?

No.

But you can use dimensions.   Make a single company and name the dimensions Company A and Company B.  Then both companies can use the same bank account.

The Bank Account Inquiry displays the parent memo line.  To get the g/l memo, you have to display the G/L entries.  I wrote an extension Bank Account G/L Inquiry that displays both at the same time.

If this is not your issue, please elaborate.

The import transactions extension allows split transactions on general journal.  I suppose it would be a good idea to allow them on bank payments/deposits.    Can you use GJ instead of payments/deposits in your CSV file?

An imported transaction in FA should be no different that one created by FA.  It can be edited and splits can be added/removed/edited.   If you are unable to split an imported transaction, elaborate by stating your FA version and extension.

Yes, that is my vote.   I've never understood the FA design why a user is limited to a single POS, or why a POS is tied to a single payment type (bank account).

Because there are a lot more Florida tax jurisdictions than 22.   If you have less than 100 customers or so around the state, then 22 could be the right number.    Florida DOR has a tool that you could plug in some customer addresses and see if you get the same rate as FA/OSC.

Yes, SB1112 died in Appropriations.

But examine the states that have implemented the change.   In many states (e.g. Utah, South Dakota), simply operating a business within the state with sales over $100k or 200 separate transactions is sufficient to create the nexus.     For example, if you have a taco stand and if you make any deliveries, you are subject to the new tax scheme.

In Colorado, this could be 10 different districts within 10 miles.  Prior to 2019, this was a uniform 2.9%.   Instate retailers paid sales tax and out-of-state purchases were subject to use tax, which almost no one ever paid.   This was unfair to the brick-and-mortar businesses that paid much more.   So now Colorado wants all deliveries (in-state and out-of-state) to pay the same as brick-and-mortar, which means there are 733 tax districts to worry about when making any delivery.

Some other states just upped the uniform tax rate instead of imposing the same brick and mortar tax requirements.  Florida wanted to just define the nexus as deliveries only.     I am no legal expert, but brick-and-mortar business will still be unhappy if they have to pay sales tax of 9% on any sale regardless of volume and everyone else who delivers into their tax zone pays a lower rate.

Yes, unfortunately the db hooks for debtor_master transactions are missing.

FA doesn't support two customers with the same customer short name so it is unclear to me how you were able to handle duplicate OSC names unless you put some unique identifier in the customer short name.

The second method can work just like the first method in using the OSC name for the customer.    The separate feature of mapping all the OSC names into a single customer name is useful if one does not care about the names in FA.   Originally, because each customer could have a separate tax rate, customer branches had to be defined for each tax rate.  That scheme breaks down if there are a zillion different tax rates which is really a problem with FA.  Thus, in my FA core, I no longer use pre-assigned tax rates but instead grab them from an off-site provider, just like the way currency rates work.     I modified OSC for the same reason, and the tax algorithm and rates have to match in order for the order to successfully imported into FA.