On Thu, Dec 26, 2019 at 10:12 AM fmiser <fmiser(a)gmail.com> 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
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
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
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
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
* 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:
- "company" or "person" (entity_class doesn't really matter; you
select any -- it's not used in the system)
- "entity_credit_account", with a role "customer" in the
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,
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?
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.