On Thu, Dec 26, 2019 at 10:12 AM fmiser <
..hidden..> wrote:
> I'm totally seeing where you're coming from and I think I can
> quite quickly develop an extention to the import script to allow
> you to import parts(goods), services and labor/overhead.
That could be really handy!
> Do you need to import assemblies too?
I don't need assemblies. The old SQL-Ledger had troubles with
assemblies so I don't have them anymore.
Ok. That simplifies matters. I'll see what I can do in the coming days.
I did additional digging and found how I can populate a postgres
table from a .csv file. I have not tried that - but I'm concerned
that if I were to do that there would be problems caused by how
much the pieces of LedgeSMB link together. For example, what
would happen with "cost of goods sold" if all the goods show up
without purchase.
COGS would fail, even though the On-Hand number might be non-zero.
So does the import script currently do more than just fill in the
"parts" table? Maybe I could use psql to fill in the table with
everything but "qty on hand" and "purchase price". Then use the
existing inventory update process.
Well, the current import script imports "inventory" for existing "parts". Importing inventory means that it sets up the quantities and balance in the inventory account (for the parts specified) and sets up the desired COGS values.
Then what about customers and vendors (contacts)? Is there a way
to get 200 customers and 120 vendors in - again without adding
them one at a time? In import_csv.pm it looks like I can import
invoices - but not the contacts. And in looking at the SQL
tables, it appears the info is not all on one table. That doesn't
look hopeful for a simple and quick import via psql.
The existing import system doesn't have imports defined for customers and vendors. I can see why you would say that a straight CSV import into the tables might not be easy. I think it's actually not too much work with the following information:
* LedgerSMB differentiates between entities (legal entities and natural persons) and the roles they can have
* Customers are entities with a customer role (vendors too)
* To set up a customer, you need to set up a record in the following tables:
- "entity"
- "company" or "person" (entity_class doesn't really matter; you can select any -- it's not used in the system)
- "entity_credit_account", with a role "customer" in the entity_class
That's all there is to setting up a customer (or vendor).
Assuming you want to mark some vendors/customers applicable to some taxes, you need to import records into the "eca_tax" table; the content of that table contains all taxes that are applicable for all vendors & customers. So, if vendor with
entity_credit_account.id = 37 is eligible for tax posted on
account.id = 42, then the row to be added to the eca_tax table is "37, 42".
I can explain about the contact, localion and bank account tables, but basically, those can be set up in a second round.
Because a lot of this info is relational, it's a bit hard to import it in a CSV, is what I'm thinking. Formats like YAML, XML or JSON allow more hierarchical data to be specified. For customer import, I'm thinking that might work better. What would be your view on that?
