 |
gildot |
 |
| |
| | Gardénia - Software de Gestão p/ PMEs em PT | | |  | Contribuído por npf em 01-10-06 21:54
do departamento @pt | |  | |  | | |  appj escreve " O Gardénia é um software de gestão empresarial "entry-level", criado especificamente para PMEs portuguesas, com traduções para inglês e português, distribuído sob licença open-source LGPL." | | | | | | É uma aplicação WEB desenvolvida em tecnologia Java J2EE e permite gerir informação sobre clientes, fornecedores, contactos, produtos, categorias e stocks, e permite a emissão e recepção dos principais documentos de negócio (facturas, facturas pró-forma, notas de crédito e débito, guias de transporte, etc, e permite criar novos tipos de documentos).
Possui também relatórios integrados (JasperReports), um painel de controlo com uma visão geral do estado da empresa, e módulos "a la CRM" de issue-tracking e gestão de eventos (reuniões, emails enviados/recebidos, etc). Pode ser instalada em modo "servidor" (Enterprise Edition) ou em modo aplicação "desktop" (Desktop Edition), funciona em qualquer OS com java instalado, e inclui pacotes/wizards de instalação para win32 e java (.exe e .jar installer). A versão actual (0.9.04, beta quality) foi lançada há pouco e possui melhor suporte para um grande número de produtos e clientes/fornecedores, a hipótese de criar documentos baseados noutros (ex, uma factura baseada na ordem de compra), e melhorias e correcções diversas. Mais info em página . < Mozilla Corp. quer consolidar a imagem do Firefox | GetDeb - Click And Run para Ubuntu > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | E facturas electrónicas para EDI segundo a norma GS1 EANCOM e/ou GS1 XML, faz?
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | | | | Não, mas está na TODO List com o ID T0069 :-). (A TODO-List está em http://gardenia.cvs.sourceforge.net/gardenia/gardenia/docs/ ) Provavelmente para a implementação dos requisitos necessários para a Factura Electrónica iria manter a técnica KISS, significando que para já apostava mais numa "aposição de assinatura digital a documento electrónico", em vez de algo mais "overkill" como o EDI. Afinal o Gardenia é suposto ser "entry-level"... (Ex, um PDF assinado contendo não só a versão para impressão da factura como qualquer bom PDF, mas metadados com a informação sobre a factura num formato standard como algum subset do ebXML de forma a poder ser extraído programaticamente). Mas esta é a ideia geral, ainda temos muito para analisar... Se quiserem ajudar, ou tecer comentários sobre possíveis técnicas/arquitecturas de implementação... :-) Sobre a factura electrónica e as possibilidades de implementação, bem como a legislação aplicável, existe alguma informação em http://www.umic.pt/UMIC/Media/SaladeImprensa/guia_factura_electronica.htm Bests,
Aristides Preto
(alguém consegue descobrir o q diabos aconteceu com a minha antiga conta "appj" no gildot ? )
|
| | | | | A pergunta surge porque uma boa implementação da factura electrónica ao nível do armazenamento (que possa em termos fiscais substituir o papel) e do EDI é das situações em que a passagem da gestão de encomendas/clientes dos métodos tradicionais/manuais para os informáticos pode ter significativos ganhos de produção. Por outro lado é cada vez mais frequente em trocas comerciais com empresas estrangeiras que estas requiram EDI, e quando uma PME que usa o software Gardénia tiver de responder a estes requesitos seria uma chatice ter de implementar um novo software. Por isso, o que eu proponho em termos de implementação são duas coisas: Manter em aberto a possibilidade que este software no futuro substituir totalmente o uso do papel ao nível da facturação (armazenamento, EDI, emissão de documentos digitalmente assinados). Quer o ponto acima seja implementado ou não que pelo menos o software tenha a capacidade de exportar os seus dados num formato (tipo XML) facilmente convertível para que se possa eventualmente importar por outro software mais completo.
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | | Só gostava de salientar que não há nada mais fácil que exportar dados para XML (seja ebXML, ou não) e assiná-los digitalmente, mas concordo que "factura electrónica" soa muito melhor ;-) Basta apenas que as partes envolvidas aceitem esse método para troca de documentos. Ou seja, tecnicamente é muito simples. Na prática, acontece frequentemente o ERP de uma das Empresas envolvidas não suportar essa funcionalidade ou existir desconfiança em relação à segurança do método por parte de uma das entidades envolvidas. Sendo muito simples de implementar, ter essa funcionalidade out-of-the-box ou não, é irrelevante... em menos de um mês se pode produzir e testar (completamente) um módulo desses ;-)
--
"Beware of whores who say they don't want money. The hell they don't. What they mean is they want more money. Much more." -- William S. Burroughs |
| | | | Nota: o comentário acima (fácil e rápido de implementar), refere-se ao universo em questão (J2EE), noutros ambinentes poderá ser mais complicado!
--
"Beware of whores who say they don't want money. The hell they don't. What they mean is they want more money. Much more." -- William S. Burroughs |
| | | | | Não me parece que a questão de como 'soa' seja apropriada. A Factura Electrónica é uma coisa concreta, tecnicamente especificada (consultar documentação relevante antes de comentar), e com enquadramento legal definido.
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | | Sim, é concreto: é um documento com um formato acordado entre as partes e assinado digitalmente. O resto são apenas recomendações que têm a haver com o formato do documento. E sim, já consultei "alguma" documentação sobre o assunto ;-)
--
"Beware of whores who say they don't want money. The hell they don't. What they mean is they want more money. Much more." -- William S. Burroughs |
| | | | | Boas. Concordo que a Factura Electrónica não esteja lá muito bem especificada... Mas acho bem assim. Afinal, a factura electrónica corresponde a um conjunto de alterações na legislação, de forma a prever que as trocas comerciais possam ser efectuadas de forma electrónica e maioritariamente sem a necessidade do suporte em papel (o que antes da "Factura Electrónica" não era possível). Basicamente o que diz é que uma factura tem de possuir todos os requisitos das facturas em papel (art. 35 do código do IVA) e tb deve implementar (DL256/2003) mecanismos que garantam a integridade, autenticidade e não repúdio, por exemplo através das seguintes técnicas: - EDI
- "Aposição" de Assinatura Digital ao documento.
Ora, isso não diz lá muito sobre a implementação técnica, realmente... Mas deixa a liberdade para escolher a implementaçãotécnica mais conveniente, permitindo aproveitar implementações já existentes. A parte gira disto tudo é que o decreto-lei que fez as alterações necessárias para a factura electrónica é já de 2003... Mas só se começou a falar mais nisso agora pq a partir de 2007 o estado vai começar a fazer o "forcing" da coisa, "obrigando" os seus fornecedores a implementarem a facturação electrónica. :-) Bests,
appj
|
| | | | | Boas. Relativamente ao EDI, este tem a grande vantagem (conforme disse no seu post) de automatizar boa parte dos processos administrativos/legais relacionados com as trocas comerciais entre um cliente e o fornecedor. (ex, já não é preciso re-introduzir os dados de uma nota de encomenda em papel, custos e tempo de pessoal administrativo para a impressão, dobragem, envio de notas de encomenda e facturas via CTT e o tempo gasto, custos de armazenamento do arquivo de docs, erros relativos à re-introdução de dados, etc). Mas creio que a própria implementação de EDI não é exactamente algo standard e reproduzível out-of-the-box de forma simples. A implementação da comunicação EDI entre duas empresas necessita da definição dos standards (UN/EDIFACT? OASIS? RosettaNet?), formatos e mensagens a utilizar (o EDI possui diversos tipos diferentes de "mensagens" para além das facturas, tais como lista-de-precos, ordem-de-compra, notas-de-envio, aviso-de-recepção, etc), do ambiente de comunicação (internet? VAN's?), e a integração com os sistemas de informação de cada empresa. Ou seja, acho que não é tão simples como implementar isso no Gardénia, instalar o software e já estamos a comunicar com boa parte do mundo via EDI... (comments ?) E de qq maneira, como a maior parte do software de gestão de gama entry-level não vem com EDI implementado de raiz, implementar EDI com o Gardénia será tão fácil ou difícil quanto implementar EDI com outro software qualquer... Provavelmente mais fácil na parte da integração, visto ser OSS e ter o código fonte disponível... :-) Por outro lado e para substituir a possibilidade de eliminar o uso de papel no processo de facturação, gosto da simplicidade e facilidade de implementação da técnica de assinar digitalmente os documentos. A parte interessante seria fazer isso de uma forma +- standard e que outros produtores de software tb usassem/implementassem, de forma a ser realmente útil... (começando pelos produtores OSS... pessoal do Evaristo, alinham?? :-)) Exemplo de implementação através de assinatura digital: o tal PDF assinado, contendo metadados/XML lá dentro com a factura e m formato estruturado e passível de ser extraído programaticamente... O PDF tem a vantagem de já constituir um formato de visualização do documento (necessário para eventuais auditorias da administração fiscal), e de ter o suporte para a assinatura digital (envelope). Quanto à capacidade de exportar os dados, concordo que seja útil a exportação de todos os dados através de um qq formato XML (BTW, vou ver se adiciono à TODO List), mas neste momento já é possível se aceder directamente (SQL) à base de dados relacional da aplicação... O modelo de dados é relativamente simples e perceptível, e possui alguns comentários... (Ver em : http://gardenia.cvs.sourceforge.net/gardenia/gardenia/src/database/datamodel/ ). Bests,
appj
|
| | | | Olá Artistides! Contacta-me em g..gomes@@netcabo..pt, que perdi o teu contacto desde a formação na PTSI. Parabéns pelo sistema de Facturação! Tinha ficado com a ideia que era apenas para uso interno da Gotham, estou a ver que tens continuado em grande! :-)
P.S: Desculpem a intrusão que nada tem a ver com este tópico.
P.S2: Seria útil um "canal privado" entre utilizadores, tipo "Private Message" dos foruns - sugestão :-)
|
| | | | A minha questão prende-se com o facto do programa servir para emitir facturas. Para ser utilizado em portugal não é necessário que seja aprovado por algum organismo oficial?
|
| | | | | | | Tanto quanto sabemos, não existem existem entidades oficiais em Portugal que emital tal certificação. O software deve é obedecer a um conjunto de regras de acordo com a legislação, e o uso de programa informático para emissão de facturas deve ser comunicado às finanças pela entidade que o usa. Esta questão já foi feita no forum de discussão do projecto, onde pode encontrar uma resposta mais detalhada: http://sourceforge.net/forum/forum.php?thread_id=1572901&forum_id=501981 Bests,
appj
|
| | | | Já alguem tentou tirar contas em aberto? é uma parte importante de um software de facturação!? Totais?
|
| | | | | | | Cada documento (ex, Factura) possui diversos estados: "Em Edição", onde podemos adicionar linhas com produtos, "Aberto" onde p.ex. pode ser enviado ao cliente (é gerada a versão para impressão em PDF), e "Fechado", qdo p.ex. foi pago. Ou seja, para "fazer" alguma coisa, deve mudar o estado do doc. de "Em Edição" para "Aberto". Depois disso pode consultar esse tipo de informação de diversas maneiras: - Na página inicial (dashboard) aparece uma listagem de todos os docs. vencidos em aberto, e também dos clientes com plafond excedido.
- Na ficha de cada cliente (no final da página) aparece diversa informação para esse cliente, nomeadamente a informação que referiu, os créditos, débitos e totais em aberto.
- Na página de documentos-emissão, é possível aplicar filtros de forma a visualizar todos os documentos do cliente em aberto ("a-la" extracto).
Embora a informação esteja toda lá, realmente ainda não temos um relatório integrado onde se vejam os saldos de contas de todos os clientes (genero balancete).
Na próxima versão vamos ver se adicionamos um relatório desse gênero, bem como um novo tipo de documento para inserir saldos iniciais. Bests,
appj P.S. Tb podem consultar mais informação/respostas e por questões nos fórums do projecto, em http://sourceforge.net/forum/forum.php?forum_id=501981.
Possui a vantagem de ficar documentado, e os developers não mordem... ;-).
|
| | | | Sim, já verifiquei. Mas para ser funcional, quando é efectuado um recibo, ele deve fechar facturas em aberto automaticamente, por exemplo, o cliente nao pode fazer pagamentos parciais, tal como de uma factura de 500 euros pagar apenas 200 euros.!"
|
| | | | | Boas. Neste momento um recibo de pagamento é como um documento normal (tal como a factura, orçamento, etc), mas com movimentos de conta corrente de diferentes classes. Em cada documento é também possível selecionar documentos relacionados, com a opção de fechar o referido documento. Assim, para criar um recibo, deve-se criar um "produto/serviço" dummy, com o nome p.ex. "Descrição" que irá servir apenas para adicionar linhas descritivas e valores (ex, do pagamento efectuado) ao documento "recibo". Isso dá liberdade para adicionar linhas que correspondem a pagamentos parciais, ou a um pagamento total, bem como permite "fechar" o documento relacionado com este recibo (factura). Por outro lado, o controlo de se a factura foi paga ou não na totalidade bem como a responsabilidade de fechar (ou não) o documento fica do lado do utilizador, e não do software. Concordo que não seja a maneira mais funcional e simples de utilizar, mas torna possível a emissão de recibos para já. Algures no futuro teremos de rever esse suporte aos pagamentos. Bests,
appj
|
| | | | | Alguém tem experiência de usar o Evaristo (da Memória Persistente) e o Gardénia? São comparáveis? Quais são as vantagens e desvantagens de cada um?
|
| |
|
