11-30-2015, 12:14 PM
Hey Joe,
Thanks, I'll study you answers when I get to this point in development. In the meantime I've some more questions/remarks:
To be able to connect to Exact you must provide Exact with your Accounts and Products. I've written classes that take care of this and the 'Items' class can even send ALL you products to Exact in one go. Before you can send an invoice to Exact you need the get the GUID (the primary ID for every entity within Exact) for the Account you're sending. I made sure account numbers from coreBOS get synchonised so that the module will always find the correct account based on the coreBOS account number.
Apart from that, there are two dependancies that will trouble any spreading of this module when it's finished. Namely, Exact requires you to specify a 'Journal' when you send an invoice. This is an accounting term, but it won't accept a non-existing one. coreBOS doesn't provide this out of the box, so my install manifest will have to update the 'vtiger_invoice' table to add a dropdown, where you can choose (including a default) Journal. Otherwise you can't send invoices to Exact, which was the whole point.
Secondly, every invoice Line (so every product you list on an invoice) needs to have a General Ledger number. Basically this is the code for a group of items. You could, in Exact for instance create a General Ledger that says 'Office Supplies'. This Ledger will receive a number, and with that a GUID. When you send an invoice, every product line MUST specify this general Ledger GUID. This will require an extra field in the vtiger_products table, also a dropdown. Before sending the invoice the module will then check the description or human-readable code of this product and get the GUID from Exact, then send it.
For this module to work the module must create the two extra columns in the table (of the fields tables for these modules?), and a user must setup the Journals and General Ledgers in both Exact and coreBOS to correspond. I could probably build a method that connects one to the other, so maybe we can suffice with just setting it all up on one side.
Thanks, I'll study you answers when I get to this point in development. In the meantime I've some more questions/remarks:
To be able to connect to Exact you must provide Exact with your Accounts and Products. I've written classes that take care of this and the 'Items' class can even send ALL you products to Exact in one go. Before you can send an invoice to Exact you need the get the GUID (the primary ID for every entity within Exact) for the Account you're sending. I made sure account numbers from coreBOS get synchonised so that the module will always find the correct account based on the coreBOS account number.
Apart from that, there are two dependancies that will trouble any spreading of this module when it's finished. Namely, Exact requires you to specify a 'Journal' when you send an invoice. This is an accounting term, but it won't accept a non-existing one. coreBOS doesn't provide this out of the box, so my install manifest will have to update the 'vtiger_invoice' table to add a dropdown, where you can choose (including a default) Journal. Otherwise you can't send invoices to Exact, which was the whole point.
Secondly, every invoice Line (so every product you list on an invoice) needs to have a General Ledger number. Basically this is the code for a group of items. You could, in Exact for instance create a General Ledger that says 'Office Supplies'. This Ledger will receive a number, and with that a GUID. When you send an invoice, every product line MUST specify this general Ledger GUID. This will require an extra field in the vtiger_products table, also a dropdown. Before sending the invoice the module will then check the description or human-readable code of this product and get the GUID from Exact, then send it.
For this module to work the module must create the two extra columns in the table (of the fields tables for these modules?), and a user must setup the Journals and General Ledgers in both Exact and coreBOS to correspond. I could probably build a method that connects one to the other, so maybe we can suffice with just setting it all up on one side.