@QMcKay I understand the reason of it. We have a single exchange rate for account transactions and this is what we use to display the transaction amounts.
However you’re crediting a hnl account but debiting a usd account in a single account transaction. Normally such transactions should be made in two separate transactions but you merged both as a single transaction. In a single transaction you both obligate to supplier and also make a payment. The side effect of it your supplier accounts never reaches zero balance. However they should work like customer accounts so like you can see how much we need to receive from customers you also need to know how much we need to pay to suppliers. Seems like you’re paying supplier bills like utility bills so it makes more sense for your business but if you want to create a HNL invoice for a HNL account but Pay it in USD they need to be 2 separate transactions.
In future updates I can implement assigning AccountTransactionDocumentTypes to InventoryTransactionDocumentTypes. Currently you can only assign a single account transaction type so it can only credit supplier accounts. When we’ll be able to assign AccountTransactionDocumentTypes you can include both account transaction types (both payable and payment transactions) in DocumentType so instead of making a separate payment transaction you’ll be able to pay as soon as you create the invoice.
LOL, I figured that was the case. At first glance, it is difficult to understand if the ExchangeRate applies to the Source or to the Target. Maybe that Table should have both Source and Target ExchangeRate columns. Then in the Transactions screen, you would know which value to display based on the (Target?) Account Currency. Anyway, I digress. It is not that important so long as TransactionValues has proper Exchange and the Account Debit/Credit/Exchange values are correct, which they are.
Right, I understand that. I understand the value of re-configuring Supplier Transactions to use an intermediary Account such as “Payables”. It makes sense.
However, the same holds true with Expenses. Even though we pay them on the spot, the Expense Accounts will never be zero either.
But I actually like that behavior in both Suppliers and Expenses, because it allows me to see at-a-glance what my biggest expenditures are to-date. For example, the Balance of an often used or expensive Supplier will show a large Balance, the same as an expensive Expense (such as Power where I live) will also show a large Balance.
Anyway, I really believe this is a non-issue and we can probably put it to rest. It does not have the effect of breaking anything. Account Balances are correct, and that is really what matter most.
LOL, I figured that was the case. At first glance, it is difficult to understand if the ExchangeRate applies to the Source or to the Target. Maybe that Table should have both Source and Target ExchangeRate columns. Then in the Transactions screen, you would know which value to display based on the (Target?) Account Currency. Anyway, I digress. It is not that important so long as TransactionValues has proper Exchange and the Account Debit/Credit/Exchange values are correct, which they are.
Right, I understand that. I understand the value of re-configuring Supplier Transactions to use an intermediary Account such as “Payables”. It makes sense.
However, the same holds true with Expenses. Even though we pay them on the spot, the Expense Accounts will never be zero either.
But I actually like that behavior in both Suppliers and Expenses, because it allows me to see at-a-glance what my biggest expenditures are to-date. For example, the Balance of an often used or expensive Supplier will show a large Balance, the same as an expensive Expense (such as Power where I live) will also show a large Balance.
Anyway, I really believe this is a non-issue and we can probably put it to rest. It does not have the effect of breaking anything. Account Balances are correct, and that is really what matter most.
Expenses integrated into PHP Inventory System. I thought I would make this it’s own page/site, but all the base code was already in place in the Inventory System so it was much quicker to just add a section for it.
I thought it was beginning to look ridiculous with all those Payment Type Buttons (6) on every Account line, so I reduced it to a single “Submit Payment” button that produces a dialog containing the Payment Types.
Also added Date Filters to be able to see Expense Payments from/to any date/time (previously it was limited to last WP Dates).
Also added the option to change the Payment Date in case we should back-date something to land in the proper month for Reporting purposes.
Being able to Back-date Tx Docs brings to light that the Transactions Screen is obviously sorted by [Id]. While this is probably Ok for most people and scenarios, it really should be sorted by [Date] instead.
In fact, the whole screen could use improvement, like having a Header with Sort/Filter selections like we have with many other screens in SambaPOS.
The Doc Names contain very little detail as to when they were created, or which Account(s) are involved. Here are 2 improvements that I made using PHP Inventory:
This really should be in a different Topic, but since I have been updating PHP Inventory System to allow for multi-currency support and added Date Filters, I found that I need to find some way to:
Link an Account Transaction to an Inventory Purchase Doc
I am not aware of a way to do this. Maybe I missed something in the DB Tables that provide this type of link?
I mean, how do I know which Account Transaction(s) was/were used during a Payment for an Inventory Purchase Doc?
EDIT: never mind, I found it …
SELECT
iDoc.[Id]
,iDoc.[Date]
,iDoc.[Name]
,aDoc.*
,tv.*
,[InventoryDocumentTransactionTypeId]
,[TransactionAccountTransactionTypeId]
,tv.[AccountTypeId]
,tv.[AccountId]
,[Description]
,[AccountTransactionDocument_Id] -- <---- the link
,[ForeignCurrencyId]
FROM [InventoryTransactionDocuments] iDoc
LEFT JOIN [AccountTransactionDocuments] aDoc on aDoc.[Id] = iDoc.[AccountTransactionDocument_Id]
LEFT JOIN [AccountTransactionValues] tv on tv.[AccountTransactionDocumentId] = aDoc.[Id]
I successfully ran my full conversion process in Production at one of my venues last Monday, and I am very happy with the result.
Most of the process uses SQL scripts and DB Tools files, while some things require manual edits, such as Inventory Item Default Cost (because there is no DB Tools support for Inventory), and editing of some Product Prices and Order Tag Prices because I want them to be whole numbers without any decimals.
Needed some very small tweaks to very minor things along the way, but operations from Tuesday through Friday have been very good without any issues, and we have been quite busy this past week.
At this point I call it a great success and I will now be running tests on the DB for my other venue. It should take much less time to do since all the ground work has already been done.
